Ok, I'll work on the patch and keep you in touch.
Should be done tomorrow is everthiny goes well.
But now time to go to bed.
Cheers,
Henri
- Original Message -
From: "Brett Porter" <[EMAIL PROTECTED]>
To: "'Maven Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2003 11
I agree.
Memory leaks are fixed, but the resulting Jelly problems need to be cleared
up. I got a better handle on it last night, and should have another stab at
it soon. The hardest thing is continuing to do the wrong thing correctly so
that existing stuff doesn't break :)
I implemented propertie
Hi,
From: "Brett Porter" <[EMAIL PROTECTED]>
> But where we stand is that there's either this reasonable amount of work
> waiting for 1.0, or there's nothing. We either release 1.0 now (After a
> quick review of JIRA), or commit to getting the fixed up plugin context
code
> into that release and h
The following comment has been added to this issue:
Author: Vincent Massol
Created: Wed, 12 Nov 2003 4:37 PM
Body:
Hi Sean. I've rolled back the patch. What I'd like to understand is why you wish to
gather all cactus tests from all subprojects and run them at once. It seems to me
Hi Henri,
Can you please post this to JIRA. It would be strongly preferable if you
could prepare the patch against the current version in CVS. Note that the
plugin has moved to the "maven-plugins" CVS repository, and you should be
able to build it and run it on beta-10 or rc1 independantly (using
Hello,
I would like to contribute to the maven project. I
have an updated version of the maven checkstyle plugin. It presents a report
containing severity columns which I found really useful (and more compliant
with checkstyle 3.x). It is based on the Maven Beta 10 version (which we are
u
On Wed, 2003-11-12 at 16:34, Brett Porter wrote:
> > I say we entirely separate out the plugins into their
> > own JIRA projects and then take a look at what's really in
> > the core.
>
> Not much left! :)
>
> > I can live with releasing what we have now as 1.0.
> >
>
> Well, I disagree for
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 12 November 2003 22:34
> To: 'Maven Developers List'
> Subject: RE: maven-new
>
> > I say we entirely separate out the plugins into their
> > own JIRA projects and then take a look at what's really in
> > the cor
The following comment has been added to this issue:
Author: Brett Porter
Created: Wed, 12 Nov 2003 3:50 PM
Body:
If you are going to do any work on these plugins, I have some stuff to contribute
(such as JSP precompilation into the WAR for Tomcat). I already have all this stuff
r
If anyone is looking for something to do, moving anything not related to the
core out of touchstone and into the plugins as a plugin test project would
be great.
All I see is:
- sea
- deploy
Cheers,
Brett
--
Brett Porter
Team Leader, Core Systems
f2 network ~ everything essential
> I say we entirely separate out the plugins into their
> own JIRA projects and then take a look at what's really in
> the core.
Not much left! :)
> I can live with releasing what we have now as 1.0.
>
Well, I disagree for a few reasons. These are just my opinion though, of
course.
- 1.0 wil
Done. I noticed you already did the plugins in CVS - I thought this was only
on your copy. Cool. Much cleaner now. Will also make any merging later a
helluva lot easier.
Current status: the pluginVar tag is not working properly in a reactor,
because project.context != context.project in some cases
> Is there any word on the JIRA tomfoolery that [EMAIL PROTECTED]
> embarked upon last month?
I believe that Jeff Turner has embarked upon providing a way to merge two
JIRA instances which would allow Apache at large to move now, and Apache
projects at codehaus to go later.
However, I'm not sure
vmassol 2003/11/12 11:09:07
Modified:checkstyle/xdocs changes.xml
checkstyle plugin.jelly
Log:
Prevent projects who do not use the head check from failing if they don't provide a
license file.
Revision ChangesPath
1.14 +4 -0 maven-plugins/checkst
The following comment has been added to this issue:
Author: Sean Timm
Created: Wed, 12 Nov 2003 11:58 AM
Body:
I would add that its also possible that some code may not be in a compilable state
(for whatever reason), but you'd like to be able to run all of the other tests. This
The following comment has been added to this issue:
Author: Sean Timm
Created: Wed, 12 Nov 2003 11:56 AM
Body:
In our setup, each project has its own cactus tests in a subfolder. We also wanted to
be able to make an aggregated cactus build that included all of the tests from each
On Wed, 2003-11-12 at 11:35, Kurt Schrader wrote:
> On Nov 12, 2003, at 10:29 AM, Jason van Zyl wrote:
>
> > I honestly do not like a because it distinctly clashes
> > with a central notion of one artifact per project. Yes, in reality more
> > are produced but maybe this is an indication that pro
On Wed, 2003-11-12 at 11:26, Vincent Massol wrote:
> At least we have an agreement on adding a element. That's a good
> first step! :-)
>
> Hmm... If I understand correctly what you are saying about deliverables,
> there should be one project.xml for each deliverable. That means that
> all of the
On Nov 12, 2003, at 10:29 AM, Jason van Zyl wrote:
I honestly do not like a because it distinctly clashes
with a central notion of one artifact per project. Yes, in reality more
are produced but maybe this is an indication that projects need to be
separated further i.e. a small project for creati
At least we have an agreement on adding a element. That's a good
first step! :-)
Hmm... If I understand correctly what you are saying about deliverables,
there should be one project.xml for each deliverable. That means that
all of these project.xml (for each deliverable) could/should actually
liv
On Sat, 2003-11-08 at 17:09, [EMAIL PROTECTED] wrote:
> If Wagon has been continuously developed while we're struggling to get a
> 1.0 out the door, it's disappointing to me.
Listen I made an effort to clean up everything and I wasn't quite
finished but you insisted on me putting it in CVS so I
On Sun, 2003-11-09 at 10:56, Vincent Massol wrote:
> +1
>
> Alternatively we could use the new feature in JIRA 2.5 which allows some
> grouping. That would allows to put all maven-related projects in one
> jira project:
>
> Maven
> |_ core
> |_ (each individual core plugin as a component)
On Wed, 2003-11-12 at 09:14, Vincent Massol wrote:
> I would view deliverables as core information and hence put it in the
> POM/core driver properties.
In the past we have tried to align the top-level POM fields with
dependencies so that there was a mesh for example we have:
foo
bar
...
General comment:
The definition that I had in my head was that parameters that were
common to all plugins/projects were defined in the POM (project.xml) and
parameters that belonged to specific plugins were put in properties in
that plugin. Some would argue that what is in the POM is structural to
werken 2003/11/12 05:50:27
Modified:xdoc plugin.properties
xdoc/src/plugin-resources site.jsl
xdoc/xdocs properties.xml
Log:
Making the width of the left navcolumn adjustable via a property.
${maven.ui.navcol.width} now defaults to 20% and repl
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2003 12:28 PM
> To: 'Maven Developers List'
> Subject: RE: [Proposal] Project deliverables definition in POM
>
>
> I would be -1 to change the standard naming of
> -..
>
The problem is t
Vincent Massol wrote:
> I would be -1 to change the standard naming of
> -..
I think its a minor change if you look at it in the following way:
-
old extensions: .jar .zip .war ...
new extensions: .jar -debug.jar -source.zip ...
> Could you explain why you think it doesn't belong to the POM?
Peter Donald wrote:
On Tue, 11 Nov 2003 01:05 am, Nicola Ken Barozzi wrote:
My personal understanding, in extreme summary, is that Peter Donald
refused to actively collaborate with some other Avalon members. I had
seen the fracture in the community and proposed him to make Phoenix a
project on par
I would be -1 to change the standard naming of
-..
Could you explain why you think it doesn't belong to the POM?
If it's not put in the POM (i.e. if we use properties), who will be the
owner of them? driver.properties (i.e the core)? Or some other plugins
(a deliverable plugin, the release plugin
+1 (that's +3 total, make it so if you have the power, otherwise raise a
chore and I'll do it)
Is there any word on the JIRA tomfoolery that [EMAIL PROTECTED]
embarked upon last month?
Also, codehaus is waiting on jira 2.5.1 to be released before upgrading
(2.5 has bugs). And apparently I hea
Vincent Massol wrote:
> -.jar
> -src-.zip
> -javadoc-.zip
> etc
>
> We *could* standardize on artifact names of course. The
> could be optional and default to ${pom.artifactId}:
tweaking the above a bit:
-.jar
--src.zip
--javadoc.zip
or as recently advertised:
--debug.jar
--debug-src.jar
Su
brett 2003/11/12 02:28:01
Modified:src/plugins-build/jar Tag: MAVEN_RC2_UNSTABLE plugin.jelly
project.xml
src/plugins-build/jar/xdocs/current Tag: MAVEN_RC2_UNSTABLE
changes.xml
src/plugins-build/multiproject
Message:
The following issue has been reopened.
Reopener: Vincent Massol
Date: Wed, 12 Nov 2003 4:12 AM
I've reopened this bug as Peter Bright has brought a valid point. The
includes/excludes were voluntarily not applied during compilation as the goal of these
properties is to inc
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2003 20:39
> To: Maven Developers List
> Subject: RE: [Proposal] Project deliverables definition in POM
>
>
>
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > S
+1
-Message d'origine-
De: [EMAIL PROTECTED]
A: [EMAIL PROTECTED]
Date: 09/11/03
Objet: Jira - Create a maven-plugins project?
I'd like to create a new project in Jira, called maven-plugins, which
will
be used to house the Jira issues related to plugins that are non core.
Votes?
Here's
35 matches
Mail list logo
