mvn 2.0.9
Latest version from head 691563
on a Windows XP box.
All the testProject* in the ITs are failing with the same error:
Failed to execute build. POM:
D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\project-01\pom.xml
Goals: org.apache.maven.plugins:maven-eclipse-plu
Awesome. Thanks John!
Paul
On Wed, Sep 3, 2008 at 7:47 PM, John Casey <[EMAIL PROTECTED]> wrote:
> I updated the 2.0.10 issues today, so I *think* it's all up to date.
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Hi again everyone,
On the last go around, we had one issue pop up with maven plugin builds
(though it might also apply to build extensions in the reactor as well).
I've fixed it, and now here's the lucky 13th release candidate:
http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC1
I updated the 2.0.10 issues today, so I *think* it's all up to date.
Brett Porter wrote:
Is the +1 to Paul or to Wendy? :)
What I understand the current situation to be:
* things fixed in both 2.0.10 and 2.1.0 are marked in both
* these do not automatically apply to 3.0 since it's now to hard t
I think it's proper issue management to label all issues for their
respective fixes. Otherwise, what are you going to do when you have
issues just for one branch? Some issues are also just for trunk and
not backported.
I think we should have a rule: if you commit to multiple places, the
issue shou
Is the +1 to Paul or to Wendy? :)
What I understand the current situation to be:
* things fixed in both 2.0.10 and 2.1.0 are marked in both
* these do not automatically apply to 3.0 since it's now to hard to
merge a lot of them so it'll be brought to backwards compat via ITs
* in the event some
On 04/09/2008, at 1:34 AM, John Casey wrote:
So, I've started tracking the features I proposed for 2.1.0 GA here:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
I don't know if this is the final list; IMO we'll need to agree on
that once we have design documentation for eve
I added a reference to the prototype I did earlier in the year for the
attribute based POMs that did this using modello and stax.
I also added simplified POM syntax to the milestones for this as a
placeholder.
- Brett
On 04/09/2008, at 8:14 AM, John Casey wrote:
http://docs.codehaus.org/
http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan
Brian Fox wrote:
Sounds good to me
Sent from my iPhone
On Sep 3, 2008, at 5:35 PM, John Casey <[EMAIL PROTECTED]> wrote:
Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we hav
Sounds good to me
Sent from my iPhone
On Sep 3, 2008, at 5:35 PM, John Casey <[EMAIL PROTECTED]> wrote:
Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we have a concrete strategy for
implementation including a design doc, I don't feel co
np. The issue is: MNG-3740. I have a fix and test case here, but I need
to clean up some IT issues related to RC12's fixes before I spin a new RC.
Arnaud HERITIER wrote:
ok
thanks a lot for your work !!!
cheers
arnaud
On Wed, Sep 3, 2008 at 8:26 PM, John Casey <[EMAIL PROTECTED]> wrote:
Ok
Fair enough, I misunderstood. :)
Stephen Connolly wrote:
afaik, I did not vote for any option (just a time bounded vote) ;-)
Sent from my iPod
On 3 Sep 2008, at 19:22, John Casey <[EMAIL PROTECTED]> wrote:
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-
Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we have a concrete strategy for
implementation including a design doc, I don't feel comfortable putting
it on such a near time horizon.
WDYT?
Brian E. Fox wrote:
The only thing I feel we need
The only thing I feel we need to start looking at soon is an xml parser
that can deal with newer models and not freak. This is probably related
in some way to the refactoring happening in 3.0... but I know that 2.0.x
can't handle newer models and the sooner we start moving to a more
flexible parser
afaik, I did not vote for any option (just a time bounded vote) ;-)
Sent from my iPod
On 3 Sep 2008, at 19:22, John Casey <[EMAIL PROTECTED]> wrote:
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-binding: Ralph, Raphael
#2: 2 binding: Brian, Dennis
2
ok, so the end result is that if I want my plugin to work with 2.0.6+
I need to parse the pom by hand in order to determine what is in the
pluginManagement section and which bits are missing a version
specification?
Sent from my iPod
On 3 Sep 2008, at 19:18, John Casey <[EMAIL PROTECTED]>
ok
thanks a lot for your work !!!
cheers
arnaud
On Wed, Sep 3, 2008 at 8:26 PM, John Casey <[EMAIL PROTECTED]> wrote:
> Okay, I'm able to reproduce it here, and hopefully I'll have it debugged
> and fixed (with test case) tonight.
>
> -john
>
> Arnaud HERITIER wrote:
>
>> John,
>>
>> I tried t
That sounds fine to me.
John Casey wrote:
> I've included this as M2 to give us a clean base in M1:
>
> http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
>
> Let me know what you think.
>
>
>
> Dennis Lundberg wrote:
>> John Casey wrote:
>>> Hi everyone,
>>>
>>> So, it seems tha
I've included this as M2 to give us a clean base in M1:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
Let me know what you think.
Dennis Lundberg wrote:
John Casey wrote:
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I
Okay, I'm able to reproduce it here, and hopefully I'll have it debugged
and fixed (with test case) tonight.
-john
Arnaud HERITIER wrote:
John,
I tried to use RC12 to build all our plugins (on win XP).
E:\Dev\oss\maven-plugins-trunk>mvn -version
Maven version: 2.1.0-M1-RC12
Java version: 1
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-binding: Ralph, Raphael
#2: 2 binding: Brian, Dennis
2 non-binding: Mauro, Stephen
If you're following the other thread ("Maven 2.1.0 GA Plan") you'll see
that I've started to formalize the suggestions I
I wound up putting it in since the clone methods were a performance
problem, and the solution was to do direct object construction and avoid
all the tangled logic inside the inheritance assembler.
Now that we're [potentially] transitioning from concrete to dynamic and
back in the build section
John Casey wrote:
> Hi everyone,
>
> So, it seems that we're all in agreement about the rough outline for
> 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC
> to make this the first milestone toward some as-yet-undetermined feature
> list for 2.1.0.
>
> So, let's talk about
As others have said before, since you John are the one doing most of the
work on this I trust your judgement in choosing the best option.
John Casey wrote:
> IMO, the change in version scheme could be a very positive thing, as it
> emphasizes introducing a feature at a time instead of pushing them
I thought it needed a full deep copy to preserve the model and we
decided to back away from that in this release? I remember discussing
it, but not the exact outcome.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 1:20 PM
To: Maven Develo
That's in the stuff I've been putting out in RCs, to be clear...
John Casey wrote:
FWIW, the reimplemented cloneModel(..) method (which in part causes this
problem, because it clones too shallowly) should keep the originalModel
instance from being polluted with resolved plugin information.
I
FWIW, the reimplemented cloneModel(..) method (which in part causes this
problem, because it clones too shallowly) should keep the originalModel
instance from being polluted with resolved plugin information.
I *think* the integration test for MNG-3710 should cover this case, but
I can't rememb
Grrr argh!
Ok, hmm I'll have a closer look at your code as you did not seem to be
parsing the XML from my initial reading of the code
On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox <[EMAIL PROTECTED]>wrote:
> You can't, this is why in the enforcer rule, I have to walk and
> interpolate the entire
So, I've started tracking the features I proposed for 2.1.0 GA here:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
I don't know if this is the final list; IMO we'll need to agree on that
once we have design documentation for everything. I'm going to contact
Don Brown today an
IMO, the change in version scheme could be a very positive thing, as it
emphasizes introducing a feature at a time instead of pushing them all
in and claiming that everything is mostly working with some bugs. I
think this may help us manage the chaos that comes from introducing
these sorts of t
+1
Wendy Smoak wrote:
On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict <[EMAIL PROTECTED]> wrote:
Are there any objections to marking the 2.0.10 issues also for 2.1 and
3.0? I can do a batch update with no email notice. Let me know. I am
in no hurry to make the change. If I see no objections by th
I've read MNG-624, and quite a bit of the code, and I feel like I
understand the algorithm relatively well. What I'm having trouble
understanding is why it needs to be so complex and look for versions in
so many places (like resolving system properties in the parent section,
etc.). IMO we need
On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict <[EMAIL PROTECTED]> wrote:
> Are there any objections to marking the 2.0.10 issues also for 2.1 and
> 3.0? I can do a batch update with no email notice. Let me know. I am
> in no hurry to make the change. If I see no objections by the weekend,
> I'll do
You can't, this is why in the enforcer rule, I have to walk and
interpolate the entire tree. If I could get the model from maven
unmolested, I could cut out 99% of that code.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 6:31 AM
T
Are there any objections to marking the 2.0.10 issues also for 2.1 and
3.0? I can do a batch update with no email notice. Let me know. I am
in no hurry to make the change. If I see no objections by the weekend,
I'll do it to keep good issue tracking.
Paul
-
If I have the floowing pom.xml:
4.0.0
org.codehaus.mojo.versions-maven-plugin.it
parent
2.0
pom
maven-checkstyle-plugin
2.1
org.apache.maven.plugins
maven-javadoc-plugin
org.apache.maven.plugin
OK, that (other plugins using it as the default) is a valid case, I
have changed the default to false
On Wed, Sep 3, 2008 at 8:31 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> I also would prefer allowSnapshots to be set to false by default, to match
> the release plugin allowSnapshots paramete
I also would prefer allowSnapshots to be set to false by default, to match
the release plugin allowSnapshots parameter and the enforcer plugin default
rules
Nicolas
2008/9/3 Stephen Connolly <[EMAIL PROTECTED]>
> On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]>
> wrote:
> > St
38 matches
Mail list logo