You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2009/02/06 17:36:17 UTC
Maven 2.1.0 Plans (a proposal of sorts)
Hi everyone,
I wanted to step back from the current Maven 2.1.0-M* release plan for a
second and reassess our progress on the issues we were planning as the
centerpiece for each release.
I've been trying to match up the milestone issues found on
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan with the
actual progress in JIRA, and what I'm finding is quite interesting.
First and foremost, if you ignore the milestone headings and take a look
at the overall progress on issues listed on that page, we've actually
knocked out most of the major issues (that don't still have significant
design work left to be done). If you look at the remaining issues, they
are in a couple of different states:
1. Implemented but not adequately tested, or else in need of a soak
period (parallel downloads, doxia).
2. Implemented in a first pass, but without a clear consensus that the
design is complete (PGP and Auto-Parent versioning, though I can't find
this one at the moment). In the case of Auto-Parent versioning, I
thought I remembered that this one had some additional issues with
current use cases, but I may not be up to date on that conversation.
In light of the above, along with the good stability we've seen in the
first milestone release, I'd *much* prefer pushing toward a release of
2.1.0-final. We've seen several cases where people are prevented from
using the 2.1.0-M1 release simply because of the "M1" at the end of the
version...which ignores its reliability completely.
If we can take care of a few tasks like fixing/downgrading/whatever the
wagon version, and cleaning up some of the low-hanging fruit currently
in the 2.1.0-M3 bucket like improving logging...then I think we're clear
to release 2.1.0 final.
At that point, we can make plans for a relatively fast release of 2.1.1
for the higher-risk issues that are sitting in the 2.1.0-M* buckets
now...possibly parallel artifact downloads if we can ever get test
coverage for that.
Looking over the release plan and the progress on JIRA, I guess I'd
really prefer to go in this direction, unless anyone has serious
objections...
Thoughts?
-john
---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp
"What we have to learn to do, we learn by doing."
-Aristotle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Arnaud HERITIER <ah...@gmail.com>.
I agree to have a 2.1 ASAP with well tested features.
We'll move others like // downloads in a 2.2
Arnaud
On Fri, Feb 6, 2009 at 5:36 PM, John Casey <jd...@commonjava.org> wrote:
> Hi everyone,
>
> I wanted to step back from the current Maven 2.1.0-M* release plan for a
> second and reassess our progress on the issues we were planning as the
> centerpiece for each release.
>
> I've been trying to match up the milestone issues found on
> http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan with the
> actual progress in JIRA, and what I'm finding is quite interesting.
>
> First and foremost, if you ignore the milestone headings and take a look at
> the overall progress on issues listed on that page, we've actually knocked
> out most of the major issues (that don't still have significant design work
> left to be done). If you look at the remaining issues, they are in a couple
> of different states:
>
> 1. Implemented but not adequately tested, or else in need of a soak period
> (parallel downloads, doxia).
>
> 2. Implemented in a first pass, but without a clear consensus that the
> design is complete (PGP and Auto-Parent versioning, though I can't find this
> one at the moment). In the case of Auto-Parent versioning, I thought I
> remembered that this one had some additional issues with current use cases,
> but I may not be up to date on that conversation.
>
> In light of the above, along with the good stability we've seen in the
> first milestone release, I'd *much* prefer pushing toward a release of
> 2.1.0-final. We've seen several cases where people are prevented from using
> the 2.1.0-M1 release simply because of the "M1" at the end of the
> version...which ignores its reliability completely.
>
> If we can take care of a few tasks like fixing/downgrading/whatever the
> wagon version, and cleaning up some of the low-hanging fruit currently in
> the 2.1.0-M3 bucket like improving logging...then I think we're clear to
> release 2.1.0 final.
>
> At that point, we can make plans for a relatively fast release of 2.1.1 for
> the higher-risk issues that are sitting in the 2.1.0-M* buckets
> now...possibly parallel artifact downloads if we can ever get test coverage
> for that.
>
> Looking over the release plan and the progress on JIRA, I guess I'd really
> prefer to go in this direction, unless anyone has serious objections...
>
> Thoughts?
>
> -john
>
> ---
> John Casey
> Developer and PMC Member, Apache Maven (http://maven.apache.org)
> Member, Apache Software Foundation
> Blog: http://www.ejlife.net/blogs/buildchimp
>
> "What we have to learn to do, we learn by doing."
> -Aristotle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Arnaud
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Bouiaw <bo...@gmail.com>.
OK, Thanks for the explanation.
On Sun, Feb 8, 2009 at 6:24 PM, Brian E. Fox <br...@reply.infinity.nu>wrote:
> This is not the same 2.1 that was used for embedders last summer. That
> version is now called 3.x and the alphas are moving forward so hopefully
> you can have a common version soon.
>
> See here for more details:
> http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/
>
> -----Original Message-----
> From: Bouiaw [mailto:bouiaw@gmail.com]
> Sent: Sunday, February 08, 2009 11:53 AM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> From my point of view (and the point of view of many colleagues), the
> most
> important feature about 2.1 release is to be able to use the same stable
> Maven version in m2eclipse and command line.
> Actually, the only way to have good performances and control on Maven
> integration in Eclipse is to use embedded Maven with is an old snapshot
> of
> maven 2.1, which offers sometimes different behaviour from 2.0.9. Using
> external 2.0.9 is possible but slow and works as a black box for
> Eclipse.
>
> So I hope it will be released as soon as possible, even if some other
> functionalities may be delayed.
>
> Regards,
> Bouiaw
>
> On Sun, Feb 8, 2009 at 3:12 PM, Benjamin Bentmann
> <benjamin.bentmann@udo.edu
> > wrote:
>
> > Don Brown wrote:
> >
> > Do you have tests that pull down multiple dependencies?
> >>
> >
> > I just added a test that pulls down 16 dependencies, using 4 different
> > group ids and 4 dependencies per group id. The test uses the checksum
> policy
> > "fail" to check that the artifacts are intact. What remains to check
> is the
> > health of the local repo metadata. I am running out of time today, so
> that's
> > at least a start.
> >
> >
> > Benjamin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brian Fox <br...@reply.infinity.nu>.
Any thing fixed in 2.0.10/11 will be in 2.1+
--Brian (mobile)
On Feb 8, 2009, at 12:42 PM, Paul Benedict <pb...@apache.org> wrote:
> While I prefer 2.1 to be released soon, I am more interested in bug
> fixes from 2.0.10 and 2.0.11 than the new features.
>
> What do you guys think about moving all of the 2.0.11 tickets to
> 2.1-M4? I am pretty sure you guys said only "show stoppers" would go
> into 2.0.x once it's EOL.
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Paul Benedict <pb...@apache.org>.
While I prefer 2.1 to be released soon, I am more interested in bug
fixes from 2.0.10 and 2.0.11 than the new features.
What do you guys think about moving all of the 2.0.11 tickets to
2.1-M4? I am pretty sure you guys said only "show stoppers" would go
into 2.0.x once it's EOL.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
This is not the same 2.1 that was used for embedders last summer. That
version is now called 3.x and the alphas are moving forward so hopefully
you can have a common version soon.
See here for more details:
http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/
-----Original Message-----
From: Bouiaw [mailto:bouiaw@gmail.com]
Sent: Sunday, February 08, 2009 11:53 AM
To: Maven Developers List
Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>From my point of view (and the point of view of many colleagues), the
most
important feature about 2.1 release is to be able to use the same stable
Maven version in m2eclipse and command line.
Actually, the only way to have good performances and control on Maven
integration in Eclipse is to use embedded Maven with is an old snapshot
of
maven 2.1, which offers sometimes different behaviour from 2.0.9. Using
external 2.0.9 is possible but slow and works as a black box for
Eclipse.
So I hope it will be released as soon as possible, even if some other
functionalities may be delayed.
Regards,
Bouiaw
On Sun, Feb 8, 2009 at 3:12 PM, Benjamin Bentmann
<benjamin.bentmann@udo.edu
> wrote:
> Don Brown wrote:
>
> Do you have tests that pull down multiple dependencies?
>>
>
> I just added a test that pulls down 16 dependencies, using 4 different
> group ids and 4 dependencies per group id. The test uses the checksum
policy
> "fail" to check that the artifacts are intact. What remains to check
is the
> health of the local repo metadata. I am running out of time today, so
that's
> at least a start.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Nigel Magnay <ni...@gmail.com>.
Umm
m2eclipse is using the 3.x branch, not the 2.1 branch.
On Sun, Feb 8, 2009 at 4:52 PM, Bouiaw <bo...@gmail.com> wrote:
> From my point of view (and the point of view of many colleagues), the most
> important feature about 2.1 release is to be able to use the same stable
> Maven version in m2eclipse and command line.
> Actually, the only way to have good performances and control on Maven
> integration in Eclipse is to use embedded Maven with is an old snapshot of
> maven 2.1, which offers sometimes different behaviour from 2.0.9. Using
> external 2.0.9 is possible but slow and works as a black box for Eclipse.
>
> So I hope it will be released as soon as possible, even if some other
> functionalities may be delayed.
>
> Regards,
> Bouiaw
>
> On Sun, Feb 8, 2009 at 3:12 PM, Benjamin Bentmann <benjamin.bentmann@udo.edu
>> wrote:
>
>> Don Brown wrote:
>>
>> Do you have tests that pull down multiple dependencies?
>>>
>>
>> I just added a test that pulls down 16 dependencies, using 4 different
>> group ids and 4 dependencies per group id. The test uses the checksum policy
>> "fail" to check that the artifacts are intact. What remains to check is the
>> health of the local repo metadata. I am running out of time today, so that's
>> at least a start.
>>
>>
>> Benjamin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Bouiaw <bo...@gmail.com>.
>From my point of view (and the point of view of many colleagues), the most
important feature about 2.1 release is to be able to use the same stable
Maven version in m2eclipse and command line.
Actually, the only way to have good performances and control on Maven
integration in Eclipse is to use embedded Maven with is an old snapshot of
maven 2.1, which offers sometimes different behaviour from 2.0.9. Using
external 2.0.9 is possible but slow and works as a black box for Eclipse.
So I hope it will be released as soon as possible, even if some other
functionalities may be delayed.
Regards,
Bouiaw
On Sun, Feb 8, 2009 at 3:12 PM, Benjamin Bentmann <benjamin.bentmann@udo.edu
> wrote:
> Don Brown wrote:
>
> Do you have tests that pull down multiple dependencies?
>>
>
> I just added a test that pulls down 16 dependencies, using 4 different
> group ids and 4 dependencies per group id. The test uses the checksum policy
> "fail" to check that the artifacts are intact. What remains to check is the
> health of the local repo metadata. I am running out of time today, so that's
> at least a start.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
On 08/02/2009, at 10:12 PM, Benjamin Bentmann wrote:
> Don Brown wrote:
>
>> Do you have tests that pull down multiple dependencies?
>
> I just added a test that pulls down 16 dependencies, using 4
> different group ids and 4 dependencies per group id. The test uses
> the checksum policy "fail" to check that the artifacts are intact.
> What remains to check is the health of the local repo metadata. I am
> running out of time today, so that's at least a start.
Thanks Benjamin, that's exactly what I had in mind to test it.
So it sounds like from this thread that keeping doxia + parallel
downloads in and the rest out is the way to go. I'll update the wiki.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Benjamin Bentmann <be...@udo.edu>.
Don Brown wrote:
> Do you have tests that pull down multiple dependencies?
I just added a test that pulls down 16 dependencies, using 4 different
group ids and 4 dependencies per group id. The test uses the checksum
policy "fail" to check that the artifacts are intact. What remains to
check is the health of the local repo metadata. I am running out of time
today, so that's at least a start.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Stephen Connolly <st...@gmail.com>.
+1000 to having it on by default but can be disabled from a CLI option
+1 to having it off by default but can be turned on from a CLI option
-1000 to not having // downloading
just my €0.02
-Stephen
2009/2/8 Arnaud HERITIER <ah...@gmail.com>:
> And can't we have an option to deactivate it in 2.1 ?
> If it works like expected we'll remove it in 3.0
>
> (I continue to be in favor to have tests, but it's really difficult to have
> a good coverage it can be a cheap solution)
>
> Arnaud
>
> On Sun, Feb 8, 2009 at 2:14 PM, Benjamin Bentmann <benjamin.bentmann@udo.edu
>> wrote:
>
>> Don Brown wrote:
>>
>> Do you have tests that pull down multiple dependencies?
>>>
>>
>> Yes, but AFAICT only dependencies from the same group id.
>>
>> If yes, you do have test coverage. [...] I'm not
>>> saying more test coverage isn't a good thing, just that this
>>> functionality probably does have coverage.
>>>
>>
>> The issue with parallelism are things like race conditions,
>> deadlock-free synchronization etc. Unless one has full control over the
>> interleaved execution of the parallel threads, those aspects can usually
>> not be checked from a test.
>>
>>
>> Benjamin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> Arnaud
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Arnaud,
Arnaud HERITIER wrote at Sonntag, 8. Februar 2009 14:33:
> And can't we have an option to deactivate it in 2.1 ?
That would be a really good idea.
> If it works like expected we'll remove it in 3.0
>
> (I continue to be in favor to have tests, but it's really difficult to
> have a good coverage it can be a cheap solution)
This is unfortunately not only a question of test coverage. I wrote myself
some library based on concurrent code and I although I have ~99% coverage,
my initial tests where executed always on a single 32-bit x86 CPU. However,
things started to fail on multi-core CPUs, 64-bit CPUs, different JDKs
(32-/64-bit/Solaris) ... so it might be a good idea to keep such an option
in any case ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Arnaud HERITIER <ah...@gmail.com>.
And can't we have an option to deactivate it in 2.1 ?
If it works like expected we'll remove it in 3.0
(I continue to be in favor to have tests, but it's really difficult to have
a good coverage it can be a cheap solution)
Arnaud
On Sun, Feb 8, 2009 at 2:14 PM, Benjamin Bentmann <benjamin.bentmann@udo.edu
> wrote:
> Don Brown wrote:
>
> Do you have tests that pull down multiple dependencies?
>>
>
> Yes, but AFAICT only dependencies from the same group id.
>
> If yes, you do have test coverage. [...] I'm not
>> saying more test coverage isn't a good thing, just that this
>> functionality probably does have coverage.
>>
>
> The issue with parallelism are things like race conditions,
> deadlock-free synchronization etc. Unless one has full control over the
> interleaved execution of the parallel threads, those aspects can usually
> not be checked from a test.
>
>
> Benjamin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Arnaud
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Benjamin Bentmann <be...@udo.edu>.
Don Brown wrote:
> Do you have tests that pull down multiple dependencies?
Yes, but AFAICT only dependencies from the same group id.
> If yes, you do have test coverage. [...] I'm not
> saying more test coverage isn't a good thing, just that this
> functionality probably does have coverage.
The issue with parallelism are things like race conditions,
deadlock-free synchronization etc. Unless one has full control over the
interleaved execution of the parallel threads, those aspects can usually
not be checked from a test.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Don Brown <mr...@twdata.org>.
Do you have tests that pull down multiple dependencies? If yes, you
do have test coverage. Tests are a good way to define a set of
expectations, so that if you reimplement the functionality, you can
ensure the functionality continues to work as expected. I'm not
saying more test coverage isn't a good thing, just that this
functionality probably does have coverage.
Don
On Sun, Feb 8, 2009 at 3:28 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I don't believe the existing Its test parallel downloads specifically.
>
> -----Original Message-----
> From: Don Brown [mailto:mrdon@twdata.org]
> Sent: Saturday, February 07, 2009 10:48 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> It would be a shame to drop such a useful feature like parallel
> downloads when it is working perfectly and been used by developers for
> months with no reports of problems. While more integration tests are
> always good, the bits of code I modified are covered by existing
> tests, so to say it has no test coverage is a misnomer. I'd be happy
> to set aside some time and answer questions or look at writing an
> additional test or two, as it is probably one of the most useful, if
> not most useful for regular developers, features Maven 2.1 could
> offer.
>
> Don
>
> On Sat, Feb 7, 2009 at 4:15 AM, Brian E. Fox <br...@reply.infinity.nu>
> wrote:
>> I thought the parallel download was already in there? I reached out to
>> Don several times about tests and never heard back which is
> unfortunate.
>> In my testing it did seem to work fine and was faster even with a repo
>> manager in place. If it's not already in there and we have no tests,
>> then I guess we bump it unless someone wants to make some tests?
>>
>> We probably need to run through the security work a few times as well,
>> this has been on my plate I just haven't had time yet.
>>
>> -----Original Message-----
>> From: John Casey [mailto:jdcasey@commonjava.org]
>> Sent: Friday, February 06, 2009 12:12 PM
>> To: Maven Developers List
>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>
>> Benjamin Bentmann wrote:
>>> John Casey wrote:
>>>
>>>> At that point, we can make plans for a relatively fast release of
>>>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>>>> buckets now...possibly parallel artifact downloads if we can ever
> get
>>
>>>> test coverage for that.
>>>
>>> IMHO the introduction of the parallel artifact download is a
>> significant
>>> change that is beyond bugfixing maintenance but a new feature and as
>>> such warrants a minor version increment, i.e. 2.2. As a user, I
>> dislike
>>> mere micro version increments when there is presumably "higher-risk".
>>
>> Couldn't agree more. In the case of parallel artifact resolution, I'm
>> unwilling to move on it at all until we can get a really solid test
>> suite written for it, and TBH I'd much prefer involving Don in that
>> effort, since he wrote the code and will have thought about the
> problem
>> (including, perhaps, some failed initial attempts) much more than the
>> rest of us. IMO, this would inform his testing, and give us a better
>> chance of releasing without bugs.
>>
>> I'm +1 for moving parallel resolution to 2.2, definitely.
>>
>> -john
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I don't believe the existing Its test parallel downloads specifically.
-----Original Message-----
From: Don Brown [mailto:mrdon@twdata.org]
Sent: Saturday, February 07, 2009 10:48 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
It would be a shame to drop such a useful feature like parallel
downloads when it is working perfectly and been used by developers for
months with no reports of problems. While more integration tests are
always good, the bits of code I modified are covered by existing
tests, so to say it has no test coverage is a misnomer. I'd be happy
to set aside some time and answer questions or look at writing an
additional test or two, as it is probably one of the most useful, if
not most useful for regular developers, features Maven 2.1 could
offer.
Don
On Sat, Feb 7, 2009 at 4:15 AM, Brian E. Fox <br...@reply.infinity.nu>
wrote:
> I thought the parallel download was already in there? I reached out to
> Don several times about tests and never heard back which is
unfortunate.
> In my testing it did seem to work fine and was faster even with a repo
> manager in place. If it's not already in there and we have no tests,
> then I guess we bump it unless someone wants to make some tests?
>
> We probably need to run through the security work a few times as well,
> this has been on my plate I just haven't had time yet.
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> Sent: Friday, February 06, 2009 12:12 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> Benjamin Bentmann wrote:
>> John Casey wrote:
>>
>>> At that point, we can make plans for a relatively fast release of
>>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>>> buckets now...possibly parallel artifact downloads if we can ever
get
>
>>> test coverage for that.
>>
>> IMHO the introduction of the parallel artifact download is a
> significant
>> change that is beyond bugfixing maintenance but a new feature and as
>> such warrants a minor version increment, i.e. 2.2. As a user, I
> dislike
>> mere micro version increments when there is presumably "higher-risk".
>
> Couldn't agree more. In the case of parallel artifact resolution, I'm
> unwilling to move on it at all until we can get a really solid test
> suite written for it, and TBH I'd much prefer involving Don in that
> effort, since he wrote the code and will have thought about the
problem
> (including, perhaps, some failed initial attempts) much more than the
> rest of us. IMO, this would inform his testing, and give us a better
> chance of releasing without bugs.
>
> I'm +1 for moving parallel resolution to 2.2, definitely.
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Don Brown <mr...@twdata.org>.
It would be a shame to drop such a useful feature like parallel
downloads when it is working perfectly and been used by developers for
months with no reports of problems. While more integration tests are
always good, the bits of code I modified are covered by existing
tests, so to say it has no test coverage is a misnomer. I'd be happy
to set aside some time and answer questions or look at writing an
additional test or two, as it is probably one of the most useful, if
not most useful for regular developers, features Maven 2.1 could
offer.
Don
On Sat, Feb 7, 2009 at 4:15 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I thought the parallel download was already in there? I reached out to
> Don several times about tests and never heard back which is unfortunate.
> In my testing it did seem to work fine and was faster even with a repo
> manager in place. If it's not already in there and we have no tests,
> then I guess we bump it unless someone wants to make some tests?
>
> We probably need to run through the security work a few times as well,
> this has been on my plate I just haven't had time yet.
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> Sent: Friday, February 06, 2009 12:12 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> Benjamin Bentmann wrote:
>> John Casey wrote:
>>
>>> At that point, we can make plans for a relatively fast release of
>>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>>> buckets now...possibly parallel artifact downloads if we can ever get
>
>>> test coverage for that.
>>
>> IMHO the introduction of the parallel artifact download is a
> significant
>> change that is beyond bugfixing maintenance but a new feature and as
>> such warrants a minor version increment, i.e. 2.2. As a user, I
> dislike
>> mere micro version increments when there is presumably "higher-risk".
>
> Couldn't agree more. In the case of parallel artifact resolution, I'm
> unwilling to move on it at all until we can get a really solid test
> suite written for it, and TBH I'd much prefer involving Don in that
> effort, since he wrote the code and will have thought about the problem
> (including, perhaps, some failed initial attempts) much more than the
> rest of us. IMO, this would inform his testing, and give us a better
> chance of releasing without bugs.
>
> I'm +1 for moving parallel resolution to 2.2, definitely.
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I thought the parallel download was already in there? I reached out to
Don several times about tests and never heard back which is unfortunate.
In my testing it did seem to work fine and was faster even with a repo
manager in place. If it's not already in there and we have no tests,
then I guess we bump it unless someone wants to make some tests?
We probably need to run through the security work a few times as well,
this has been on my plate I just haven't had time yet.
-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org]
Sent: Friday, February 06, 2009 12:12 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
Benjamin Bentmann wrote:
> John Casey wrote:
>
>> At that point, we can make plans for a relatively fast release of
>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>> buckets now...possibly parallel artifact downloads if we can ever get
>> test coverage for that.
>
> IMHO the introduction of the parallel artifact download is a
significant
> change that is beyond bugfixing maintenance but a new feature and as
> such warrants a minor version increment, i.e. 2.2. As a user, I
dislike
> mere micro version increments when there is presumably "higher-risk".
Couldn't agree more. In the case of parallel artifact resolution, I'm
unwilling to move on it at all until we can get a really solid test
suite written for it, and TBH I'd much prefer involving Don in that
effort, since he wrote the code and will have thought about the problem
(including, perhaps, some failed initial attempts) much more than the
rest of us. IMO, this would inform his testing, and give us a better
chance of releasing without bugs.
I'm +1 for moving parallel resolution to 2.2, definitely.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Christian Edward Gruber <ch...@gmail.com>.
I don't really get a vote, but as a user, implementer, and
recommender, I heartily agree with this. parallel resolution in 2.2,
and tie off a 2.1 final as quickly as possible.
Cheers,
Christian.
On 6-Feb-09, at 12:12 , John Casey wrote:
> Benjamin Bentmann wrote:
>> John Casey wrote:
>>> At that point, we can make plans for a relatively fast release of
>>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>>> buckets now...possibly parallel artifact downloads if we can ever
>>> get test coverage for that.
>> IMHO the introduction of the parallel artifact download is a
>> significant change that is beyond bugfixing maintenance but a new
>> feature and as such warrants a minor version increment, i.e. 2.2.
>> As a user, I dislike mere micro version increments when there is
>> presumably "higher-risk".
>
> Couldn't agree more. In the case of parallel artifact resolution,
> I'm unwilling to move on it at all until we can get a really solid
> test suite written for it, and TBH I'd much prefer involving Don in
> that effort, since he wrote the code and will have thought about the
> problem (including, perhaps, some failed initial attempts) much more
> than the rest of us. IMO, this would inform his testing, and give us
> a better chance of releasing without bugs.
>
> I'm +1 for moving parallel resolution to 2.2, definitely.
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Christian Edward Gruber
christianedwardgruber@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
Benjamin Bentmann wrote:
> John Casey wrote:
>
>> At that point, we can make plans for a relatively fast release of
>> 2.1.1 for the higher-risk issues that are sitting in the 2.1.0-M*
>> buckets now...possibly parallel artifact downloads if we can ever get
>> test coverage for that.
>
> IMHO the introduction of the parallel artifact download is a significant
> change that is beyond bugfixing maintenance but a new feature and as
> such warrants a minor version increment, i.e. 2.2. As a user, I dislike
> mere micro version increments when there is presumably "higher-risk".
Couldn't agree more. In the case of parallel artifact resolution, I'm
unwilling to move on it at all until we can get a really solid test
suite written for it, and TBH I'd much prefer involving Don in that
effort, since he wrote the code and will have thought about the problem
(including, perhaps, some failed initial attempts) much more than the
rest of us. IMO, this would inform his testing, and give us a better
chance of releasing without bugs.
I'm +1 for moving parallel resolution to 2.2, definitely.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Benjamin Bentmann <be...@udo.edu>.
John Casey wrote:
> In light of the above, along with the good stability we've seen in the
> first milestone release, I'd *much* prefer pushing toward a release of
> 2.1.0-final.
+1.
> At that point, we can make plans for a relatively fast release of 2.1.1
> for the higher-risk issues that are sitting in the 2.1.0-M* buckets
> now...possibly parallel artifact downloads if we can ever get test
> coverage for that.
IMHO the introduction of the parallel artifact download is a significant
change that is beyond bugfixing maintenance but a new feature and as
such warrants a minor version increment, i.e. 2.2. As a user, I dislike
mere micro version increments when there is presumably "higher-risk".
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
If it has a decent test suite and is released, I have no problem putting
it in, at least early in the RC process (to give it a little soak time).
With a strong test suite, I would think this soak period would give us a
good enough chance to check site production...though I wonder, will this
require a corresponding upgrade in the site plugin's own dependencies?
i.e. is the API backward compatible?
If we move down the path of releasing Doxia ASAP then IMO we can push to
get it into 2.1.0. I understand the vicious cycle, but part of the
problem there is that Doxia is apparently unused except in Maven
itself...is that correct?
-john
Lukas Theussl wrote:
>
> Picking up the doxia thread:
>
> I have the feeling Doxia is never going to get out of it's vicious
> circle: we are hesitant to release 1.1 because without the site plugin
> using it, it doesn't get any hard-core testing, and for maven you guys
> don't want to use it because it hasn't been released for so long...
>
> First we were told that maven 2.0.9 will switch to doxia beta-1, then
> 2.0.10 then 2.0.11, then 2.1-SNAP, then 2.1-M3, now 2.2.... :)
>
> Just count the issues of the site plugin that depend on a doxia upgrade,
> at one point we'll have to switch to make any progress. I was really
> hoping to get this in for M3.
>
> -Lukas
>
>
> Brett Porter wrote:
>> (for some reason this got bounced as spam earlier, so I rewrote it and
>> chopped the quotation in the hope it gets through...)
>>
>> I thought this was already the direction we were going... (see
>> "releasing 2.0.10" thread).
>>
>> I already suggested we drop the auto parent version and PGP stuff from
>> the roadmap, and I'm all for getting to a final release ASAP.
>>
>> Personally, I would still like to give the Doxia change a trial - and
>> should it prove to have *any* problems we pull it back to 2.2. I think
>> this is causing the Doxia guys some grief - so I'd like to hear from
>> them. I'm probably 50/50 on parallel downloads - would prefer to see
>> it in, but not if it requires a lot of integration work or causes
>> problems.
>>
>> We do need the password security changes finished. Oleg, are you
>> working on the docs or should I put them together based on your blog?
>> Is there anything else left to do in the code? I think that dependency
>> needs to be out of alpha before we go final - I think we discussed
>> that sort of criteria for external dependencies a while back.
>>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brian Fox <br...@reply.infinity.nu>.
Is it released yet? The reason it didn't make the previous releases is
that it wasn't ready. I think it should be in 2.1 but not 2.0 at this
point
--Brian (mobile)
On Feb 8, 2009, at 1:03 PM, Lukas Theussl <lt...@apache.org> wrote:
>
> Picking up the doxia thread:
>
> I have the feeling Doxia is never going to get out of it's vicious
> circle: we are hesitant to release 1.1 because without the site
> plugin using it, it doesn't get any hard-core testing, and for maven
> you guys don't want to use it because it hasn't been released for so
> long...
>
> First we were told that maven 2.0.9 will switch to doxia beta-1,
> then 2.0.10 then 2.0.11, then 2.1-SNAP, then 2.1-M3, now 2.2.... :)
>
> Just count the issues of the site plugin that depend on a doxia
> upgrade, at one point we'll have to switch to make any progress. I
> was really hoping to get this in for M3.
>
> -Lukas
>
>
> Brett Porter wrote:
>> (for some reason this got bounced as spam earlier, so I rewrote it
>> and chopped the quotation in the hope it gets through...)
>> I thought this was already the direction we were going... (see
>> "releasing 2.0.10" thread).
>> I already suggested we drop the auto parent version and PGP stuff
>> from the roadmap, and I'm all for getting to a final release ASAP.
>> Personally, I would still like to give the Doxia change a trial -
>> and should it prove to have *any* problems we pull it back to 2.2.
>> I think this is causing the Doxia guys some grief - so I'd like to
>> hear from them. I'm probably 50/50 on parallel downloads - would
>> prefer to see it in, but not if it requires a lot of integration
>> work or causes problems.
>> We do need the password security changes finished. Oleg, are you
>> working on the docs or should I put them together based on your
>> blog? Is there anything else left to do in the code? I think that
>> dependency needs to be out of alpha before we go final - I think we
>> discussed that sort of criteria for external dependencies a while
>> back.
>> Thanks,
>> Brett
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Lukas Theussl <lt...@apache.org>.
Picking up the doxia thread:
I have the feeling Doxia is never going to get out of it's vicious circle: we are
hesitant to release 1.1 because without the site plugin using it, it doesn't get
any hard-core testing, and for maven you guys don't want to use it because it
hasn't been released for so long...
First we were told that maven 2.0.9 will switch to doxia beta-1, then 2.0.10 then
2.0.11, then 2.1-SNAP, then 2.1-M3, now 2.2.... :)
Just count the issues of the site plugin that depend on a doxia upgrade, at one
point we'll have to switch to make any progress. I was really hoping to get this
in for M3.
-Lukas
Brett Porter wrote:
> (for some reason this got bounced as spam earlier, so I rewrote it and
> chopped the quotation in the hope it gets through...)
>
> I thought this was already the direction we were going... (see
> "releasing 2.0.10" thread).
>
> I already suggested we drop the auto parent version and PGP stuff from
> the roadmap, and I'm all for getting to a final release ASAP.
>
> Personally, I would still like to give the Doxia change a trial - and
> should it prove to have *any* problems we pull it back to 2.2. I think
> this is causing the Doxia guys some grief - so I'd like to hear from
> them. I'm probably 50/50 on parallel downloads - would prefer to see it
> in, but not if it requires a lot of integration work or causes problems.
>
> We do need the password security changes finished. Oleg, are you working
> on the docs or should I put them together based on your blog? Is there
> anything else left to do in the code? I think that dependency needs to
> be out of alpha before we go final - I think we discussed that sort of
> criteria for external dependencies a while back.
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Paul Benedict <pb...@apache.org>.
+1 for all points described.
On Mon, Feb 9, 2009 at 7:43 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Yep good idea.
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Monday, February 09, 2009 7:44 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
>
>>
>> I'm +1 for including it and providing an opt-out switch to turn it
>> off. If we can make that switch stick permanently via the
>> settings.xml, so much the better.
>
> +1 (even better, configure number of parallel threads, just set it to
> 1 to turn it off).
>
> On 09/02/2009, at 11:18 PM, John Casey wrote:
>
>> I'll rearrange the JIRA versions today, then...it looks like we're
>> all in agreement about moving directly toward 2.1.0 generally.
>>
>
> Let's slow down a bit...
>
> We are totally in agreement to moving towards 2.1.0 generally, and the
> list in JIRA now reflects that.
>
> However, I don't see why we'd cancel a milestone release when there's
> already been good progress. I was all ready to roll that once the
> remaining snapshot was released (I've been working on it since
> December since you said you didn't have time), but now JIRA has been
> transformed and any release is 23 issues (I'm guessing probably 2
> weeks minimum) away. Then the RC cycle will be more brutal.
>
> Why couldn't we stick to the plan as it was yesterday? Same issues,
> more intermediate releases.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Lukas Theussl <lt...@apache.org>.
I am still available. However, somehow I can't help the feeling that with your
experience it might be quicker if you did it right away instead of walking me
through the process...
-Lukas
Dennis Lundberg wrote:
> I'm undecided about what version number to use, and leave that decision
> to others.
>
> One issue that I strongly feel needs to go into 2.1.0 final is MNG-3602,
> the inclusion of Doxia 1.1 into the core. According to the release plan
> for Doxia [1], Lukas had agreed to release Doxia 1.1. If he's not
> available to do it I can do it.
>
> [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
>
> John Casey wrote:
>> I fully agree with Brian about the version naming for the next release.
>> Given its track record over the last 6 months, using -M1 for the last
>> release crippled it unfairly in the public view; it's at least as stable
>> as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4.
>>
>> IMO, there is absolutely no reason to do another milestone release. We
>> should be moving toward 2.1.0 final, resolving the worst regressions and
>> the most watched/voted-for issues before doing so. Currently, we have
>> what looks like 4 major issues still unresolved in the 2.1.0 bucket,
>> judging from the votes. Three of these are in progress, I think. I know
>> I'm working on MNG-3057, for instance, and I thought Oleg was working on
>> MNG-553 still...Brett, are you still working on MNG-3379, and did you
>> plan to finish that before we release 2.1.0? The fourth top issue seems
>> on the face of it to be based on a common misunderstanding about how
>> profiles are triggered and applied...probably more of a
>> documentation/education task than anything else.
>>
>> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
>> that the wagon version we're using is stable. I seem to remember an
>> issue coming up shortly after the release of 2.1.0-M1 related to one of
>> the new Wagon implementations - WebDAV, maybe? I'm having some trouble
>> remembering/finding that issue in my gmail, but we need to make sure
>> that doesn't get left out of this release. If it means rolling back to
>> an older wagon version, then let's do that.
>>
>> I'm not in favor of releasing another milestone of 2.1.0 at this point.
>> Sure, we should have done more work to execute that release plan last
>> fall. I for one got very sidetracked putting together a build farm that
>> we can use to help verify future releases of Maven proactively. In any
>> case, I think the value of milestone releases is greatly diminished at
>> this point, and we need to get serious about 2.1.0 final. We can push
>> off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1
>> bucket, and get on with it once we have these four dealt with.
>>
>> -john
>>
>> Brett Porter wrote:
>>> So, there seems to be some agreement.
>>>
>>> However, I've come back from underground and now there are *two*
>>> snapshots on trunk. I'm already spending valentine's day alone, so I
>>> didn't really need another reason to curl up in the corner and cry :)
>>>
>>> I would really like to pull an M2 release in the next week with the
>>> stuff that is already there. John, what do you think?
>>>
>>> Thanks,
>>> Brett
>>>
>>> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>>>
>>>> Yep good idea.
>>>>
>>>> -----Original Message-----
>>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>>> Porter
>>>> Sent: Monday, February 09, 2009 7:44 PM
>>>> To: Maven Developers List
>>>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>>>
>>>>
>>>>> I'm +1 for including it and providing an opt-out switch to turn it
>>>>> off. If we can make that switch stick permanently via the
>>>>> settings.xml, so much the better.
>>>> +1 (even better, configure number of parallel threads, just set it to
>>>> 1 to turn it off).
>>>>
>>>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>>>
>>>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>>>> all in agreement about moving directly toward 2.1.0 generally.
>>>>>
>>>> Let's slow down a bit...
>>>>
>>>> We are totally in agreement to moving towards 2.1.0 generally, and the
>>>> list in JIRA now reflects that.
>>>>
>>>> However, I don't see why we'd cancel a milestone release when there's
>>>> already been good progress. I was all ready to roll that once the
>>>> remaining snapshot was released (I've been working on it since
>>>> December since you said you didn't have time), but now JIRA has been
>>>> transformed and any release is 23 issues (I'm guessing probably 2
>>>> weeks minimum) away. Then the RC cycle will be more brutal.
>>>>
>>>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>>>> more intermediate releases.
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
+1. The sooner the better.
Brian E. Fox wrote:
> Well lets get a release then so we have something to try. It's been a
> waiting game it seems so far. If there's a release we can integrate soon
> enough into the cycle, then we have a chance of detecting and fixing any
> issues. It always seems to come up far too late in the cycle to do
> anything about it. So I say if we want to get it included, then let's
> have a release right away
>
> -----Original Message-----
> From: Dennis Lundberg [mailto:dennisl@apache.org]
> Sent: Tuesday, February 17, 2009 6:50 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> I'm undecided about what version number to use, and leave that decision
> to others.
>
> One issue that I strongly feel needs to go into 2.1.0 final is MNG-3602,
> the inclusion of Doxia 1.1 into the core. According to the release plan
> for Doxia [1], Lukas had agreed to release Doxia 1.1. If he's not
> available to do it I can do it.
>
> [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
>
> John Casey wrote:
>> I fully agree with Brian about the version naming for the next
> release.
>> Given its track record over the last 6 months, using -M1 for the last
>> release crippled it unfairly in the public view; it's at least as
> stable
>> as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4.
>>
>> IMO, there is absolutely no reason to do another milestone release. We
>> should be moving toward 2.1.0 final, resolving the worst regressions
> and
>> the most watched/voted-for issues before doing so. Currently, we have
>> what looks like 4 major issues still unresolved in the 2.1.0 bucket,
>> judging from the votes. Three of these are in progress, I think. I
> know
>> I'm working on MNG-3057, for instance, and I thought Oleg was working
> on
>> MNG-553 still...Brett, are you still working on MNG-3379, and did you
>> plan to finish that before we release 2.1.0? The fourth top issue
> seems
>> on the face of it to be based on a common misunderstanding about how
>> profiles are triggered and applied...probably more of a
>> documentation/education task than anything else.
>>
>> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
>> that the wagon version we're using is stable. I seem to remember an
>> issue coming up shortly after the release of 2.1.0-M1 related to one
> of
>> the new Wagon implementations - WebDAV, maybe? I'm having some trouble
>> remembering/finding that issue in my gmail, but we need to make sure
>> that doesn't get left out of this release. If it means rolling back to
>> an older wagon version, then let's do that.
>>
>> I'm not in favor of releasing another milestone of 2.1.0 at this
> point.
>> Sure, we should have done more work to execute that release plan last
>> fall. I for one got very sidetracked putting together a build farm
> that
>> we can use to help verify future releases of Maven proactively. In any
>> case, I think the value of milestone releases is greatly diminished at
>> this point, and we need to get serious about 2.1.0 final. We can push
>> off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1
>> bucket, and get on with it once we have these four dealt with.
>>
>> -john
>>
>> Brett Porter wrote:
>>> So, there seems to be some agreement.
>>>
>>> However, I've come back from underground and now there are *two*
>>> snapshots on trunk. I'm already spending valentine's day alone, so I
>>> didn't really need another reason to curl up in the corner and cry :)
>>>
>>> I would really like to pull an M2 release in the next week with the
>>> stuff that is already there. John, what do you think?
>>>
>>> Thanks,
>>> Brett
>>>
>>> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>>>
>>>> Yep good idea.
>>>>
>>>> -----Original Message-----
>>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>>> Porter
>>>> Sent: Monday, February 09, 2009 7:44 PM
>>>> To: Maven Developers List
>>>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>>>
>>>>
>>>>> I'm +1 for including it and providing an opt-out switch to turn it
>>>>> off. If we can make that switch stick permanently via the
>>>>> settings.xml, so much the better.
>>>> +1 (even better, configure number of parallel threads, just set it
> to
>>>> 1 to turn it off).
>>>>
>>>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>>>
>>>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>>>> all in agreement about moving directly toward 2.1.0 generally.
>>>>>
>>>> Let's slow down a bit...
>>>>
>>>> We are totally in agreement to moving towards 2.1.0 generally, and
> the
>>>> list in JIRA now reflects that.
>>>>
>>>> However, I don't see why we'd cancel a milestone release when
> there's
>>>> already been good progress. I was all ready to roll that once the
>>>> remaining snapshot was released (I've been working on it since
>>>> December since you said you didn't have time), but now JIRA has been
>>>> transformed and any release is 23 issues (I'm guessing probably 2
>>>> weeks minimum) away. Then the RC cycle will be more brutal.
>>>>
>>>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>>>> more intermediate releases.
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Well lets get a release then so we have something to try. It's been a
waiting game it seems so far. If there's a release we can integrate soon
enough into the cycle, then we have a chance of detecting and fixing any
issues. It always seems to come up far too late in the cycle to do
anything about it. So I say if we want to get it included, then let's
have a release right away
-----Original Message-----
From: Dennis Lundberg [mailto:dennisl@apache.org]
Sent: Tuesday, February 17, 2009 6:50 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
I'm undecided about what version number to use, and leave that decision
to others.
One issue that I strongly feel needs to go into 2.1.0 final is MNG-3602,
the inclusion of Doxia 1.1 into the core. According to the release plan
for Doxia [1], Lukas had agreed to release Doxia 1.1. If he's not
available to do it I can do it.
[1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
John Casey wrote:
> I fully agree with Brian about the version naming for the next
release.
> Given its track record over the last 6 months, using -M1 for the last
> release crippled it unfairly in the public view; it's at least as
stable
> as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4.
>
> IMO, there is absolutely no reason to do another milestone release. We
> should be moving toward 2.1.0 final, resolving the worst regressions
and
> the most watched/voted-for issues before doing so. Currently, we have
> what looks like 4 major issues still unresolved in the 2.1.0 bucket,
> judging from the votes. Three of these are in progress, I think. I
know
> I'm working on MNG-3057, for instance, and I thought Oleg was working
on
> MNG-553 still...Brett, are you still working on MNG-3379, and did you
> plan to finish that before we release 2.1.0? The fourth top issue
seems
> on the face of it to be based on a common misunderstanding about how
> profiles are triggered and applied...probably more of a
> documentation/education task than anything else.
>
> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
> that the wagon version we're using is stable. I seem to remember an
> issue coming up shortly after the release of 2.1.0-M1 related to one
of
> the new Wagon implementations - WebDAV, maybe? I'm having some trouble
> remembering/finding that issue in my gmail, but we need to make sure
> that doesn't get left out of this release. If it means rolling back to
> an older wagon version, then let's do that.
>
> I'm not in favor of releasing another milestone of 2.1.0 at this
point.
> Sure, we should have done more work to execute that release plan last
> fall. I for one got very sidetracked putting together a build farm
that
> we can use to help verify future releases of Maven proactively. In any
> case, I think the value of milestone releases is greatly diminished at
> this point, and we need to get serious about 2.1.0 final. We can push
> off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1
> bucket, and get on with it once we have these four dealt with.
>
> -john
>
> Brett Porter wrote:
>> So, there seems to be some agreement.
>>
>> However, I've come back from underground and now there are *two*
>> snapshots on trunk. I'm already spending valentine's day alone, so I
>> didn't really need another reason to curl up in the corner and cry :)
>>
>> I would really like to pull an M2 release in the next week with the
>> stuff that is already there. John, what do you think?
>>
>> Thanks,
>> Brett
>>
>> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>>
>>> Yep good idea.
>>>
>>> -----Original Message-----
>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>> Porter
>>> Sent: Monday, February 09, 2009 7:44 PM
>>> To: Maven Developers List
>>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>>
>>>
>>>>
>>>> I'm +1 for including it and providing an opt-out switch to turn it
>>>> off. If we can make that switch stick permanently via the
>>>> settings.xml, so much the better.
>>>
>>> +1 (even better, configure number of parallel threads, just set it
to
>>> 1 to turn it off).
>>>
>>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>>
>>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>>> all in agreement about moving directly toward 2.1.0 generally.
>>>>
>>>
>>> Let's slow down a bit...
>>>
>>> We are totally in agreement to moving towards 2.1.0 generally, and
the
>>> list in JIRA now reflects that.
>>>
>>> However, I don't see why we'd cancel a milestone release when
there's
>>> already been good progress. I was all ready to roll that once the
>>> remaining snapshot was released (I've been working on it since
>>> December since you said you didn't have time), but now JIRA has been
>>> transformed and any release is 23 issues (I'm guessing probably 2
>>> weeks minimum) away. Then the RC cycle will be more brutal.
>>>
>>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>>> more intermediate releases.
>>>
>>> - Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Dennis Lundberg <de...@apache.org>.
I'm undecided about what version number to use, and leave that decision
to others.
One issue that I strongly feel needs to go into 2.1.0 final is MNG-3602,
the inclusion of Doxia 1.1 into the core. According to the release plan
for Doxia [1], Lukas had agreed to release Doxia 1.1. If he's not
available to do it I can do it.
[1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
John Casey wrote:
> I fully agree with Brian about the version naming for the next release.
> Given its track record over the last 6 months, using -M1 for the last
> release crippled it unfairly in the public view; it's at least as stable
> as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4.
>
> IMO, there is absolutely no reason to do another milestone release. We
> should be moving toward 2.1.0 final, resolving the worst regressions and
> the most watched/voted-for issues before doing so. Currently, we have
> what looks like 4 major issues still unresolved in the 2.1.0 bucket,
> judging from the votes. Three of these are in progress, I think. I know
> I'm working on MNG-3057, for instance, and I thought Oleg was working on
> MNG-553 still...Brett, are you still working on MNG-3379, and did you
> plan to finish that before we release 2.1.0? The fourth top issue seems
> on the face of it to be based on a common misunderstanding about how
> profiles are triggered and applied...probably more of a
> documentation/education task than anything else.
>
> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
> that the wagon version we're using is stable. I seem to remember an
> issue coming up shortly after the release of 2.1.0-M1 related to one of
> the new Wagon implementations - WebDAV, maybe? I'm having some trouble
> remembering/finding that issue in my gmail, but we need to make sure
> that doesn't get left out of this release. If it means rolling back to
> an older wagon version, then let's do that.
>
> I'm not in favor of releasing another milestone of 2.1.0 at this point.
> Sure, we should have done more work to execute that release plan last
> fall. I for one got very sidetracked putting together a build farm that
> we can use to help verify future releases of Maven proactively. In any
> case, I think the value of milestone releases is greatly diminished at
> this point, and we need to get serious about 2.1.0 final. We can push
> off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1
> bucket, and get on with it once we have these four dealt with.
>
> -john
>
> Brett Porter wrote:
>> So, there seems to be some agreement.
>>
>> However, I've come back from underground and now there are *two*
>> snapshots on trunk. I'm already spending valentine's day alone, so I
>> didn't really need another reason to curl up in the corner and cry :)
>>
>> I would really like to pull an M2 release in the next week with the
>> stuff that is already there. John, what do you think?
>>
>> Thanks,
>> Brett
>>
>> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>>
>>> Yep good idea.
>>>
>>> -----Original Message-----
>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>> Porter
>>> Sent: Monday, February 09, 2009 7:44 PM
>>> To: Maven Developers List
>>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>>
>>>
>>>>
>>>> I'm +1 for including it and providing an opt-out switch to turn it
>>>> off. If we can make that switch stick permanently via the
>>>> settings.xml, so much the better.
>>>
>>> +1 (even better, configure number of parallel threads, just set it to
>>> 1 to turn it off).
>>>
>>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>>
>>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>>> all in agreement about moving directly toward 2.1.0 generally.
>>>>
>>>
>>> Let's slow down a bit...
>>>
>>> We are totally in agreement to moving towards 2.1.0 generally, and the
>>> list in JIRA now reflects that.
>>>
>>> However, I don't see why we'd cancel a milestone release when there's
>>> already been good progress. I was all ready to roll that once the
>>> remaining snapshot was released (I've been working on it since
>>> December since you said you didn't have time), but now JIRA has been
>>> transformed and any release is 23 issues (I'm guessing probably 2
>>> weeks minimum) away. Then the RC cycle will be more brutal.
>>>
>>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>>> more intermediate releases.
>>>
>>> - Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Henri Gomez <he...@gmail.com>.
2009/2/18 Brett Porter <br...@apache.org>:
> On 18/02/2009, at 11:59 PM, Henri Gomez wrote:
>
>> I build my JAX-WS project with maven 2.1.0-M1 and it works :)
>>
>> Good news, but could it be used in m2eclipse ?
>
> It's really something to take up with m2eclipse... but I don't see it
> happening for the reason I outlined earlier regarding the embedder.
Sniff ;(
I'll ask on m2eclipse.
Thanks Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
On 18/02/2009, at 11:59 PM, Henri Gomez wrote:
> I build my JAX-WS project with maven 2.1.0-M1 and it works :)
>
> Good news, but could it be used in m2eclipse ?
It's really something to take up with m2eclipse... but I don't see it
happening for the reason I outlined earlier regarding the embedder.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Henri Gomez <he...@gmail.com>.
I build my JAX-WS project with maven 2.1.0-M1 and it works :)
Good news, but could it be used in m2eclipse ?
2009/2/18 Brett Porter <br...@apache.org>:
> As was highlighted before in these threads, this is a completely different
> 2.1.0 to the one previously included in m2eclipse (it never has been
> included):
>
> http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/
>
> - Brett
>
> On 18/02/2009, at 10:32 PM, Henri Gomez wrote:
>
>> 2009/2/18 Brett Porter <br...@apache.org>:
>>>
>>> On 18/02/2009, at 7:43 PM, Henri Gomez wrote:
>>>
>>>> Question about 2.1.0 / 3.0.0.
>>>>
>>>> In 3.0 alpha2 Jason fix a problem with jaxws-maven.
>>>>
>>>> Could it be backported to 2.1.0 ?
>>>
>>> I believe that problem doesn't affect 2.1.0.
>>
>> Nope, the jaxws maven plugin didn't works with maven 2.1.0 (at least
>> the version in m2eclipse 0.9.7) :(
>>
>> The following mojo encountered an error while executing:
>> Group-Id: org.codehaus.mojo
>> Artifact-Id: jaxws-maven-plugin
>> Version: 1.11
>> Mojo: wsgen
>> brought in via: POM
>>
>> While building project:
>> Group-Id: mycorp.can
>> Artifact-Id: mycorp-framework
>> Version: 2.0.0-19-SNAPSHOT
>> From file: C:\workspace-34\mycorp-framework\pom.xml
>> Reason: Failed to execute wsgen
>>
>> java.lang.NoClassDefFoundError:
>> com/sun/mirror/apt/AnnotationProcessorFactory
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>> at
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
>> at
>> org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>> at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
>> at
>> org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
>> at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
>> at
>> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
>> at
>> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
>>
>>
>>
>> Error stacktrace:
>> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error
>> in the plugin manager executing goal
>> 'org.codehaus.mojo:jaxws-maven-plugin:1.11:wsgen': Mojo execution
>> failed.
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
>> at
>> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
>> at
>> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
>> at
>> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
>> Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo
>> execution failed.
>> at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
>> ... 20 more
>> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
>> execute wsgen
>> at
>> org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:102)
>> at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
>> ... 21 more
>> Caused by: java.lang.NoClassDefFoundError:
>> com/sun/mirror/apt/AnnotationProcessorFactory
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>> at
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
>> at
>> org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>> at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
>> at
>> org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
>> ... 22 more
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
As was highlighted before in these threads, this is a completely
different 2.1.0 to the one previously included in m2eclipse (it never
has been included):
http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/
- Brett
On 18/02/2009, at 10:32 PM, Henri Gomez wrote:
> 2009/2/18 Brett Porter <br...@apache.org>:
>>
>> On 18/02/2009, at 7:43 PM, Henri Gomez wrote:
>>
>>> Question about 2.1.0 / 3.0.0.
>>>
>>> In 3.0 alpha2 Jason fix a problem with jaxws-maven.
>>>
>>> Could it be backported to 2.1.0 ?
>>
>> I believe that problem doesn't affect 2.1.0.
>
> Nope, the jaxws maven plugin didn't works with maven 2.1.0 (at least
> the version in m2eclipse 0.9.7) :(
>
> The following mojo encountered an error while executing:
> Group-Id: org.codehaus.mojo
> Artifact-Id: jaxws-maven-plugin
> Version: 1.11
> Mojo: wsgen
> brought in via: POM
>
> While building project:
> Group-Id: mycorp.can
> Artifact-Id: mycorp-framework
> Version: 2.0.0-19-SNAPSHOT
> From file: C:\workspace-34\mycorp-framework\pom.xml
> Reason: Failed to execute wsgen
>
> java.lang.NoClassDefFoundError: com/sun/mirror/apt/
> AnnotationProcessorFactory
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:
> 124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org
> .codehaus
> .plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:
> 174)
> at
> org
> .codehaus
> .plexus
> .classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:
> 67)
> at
> org
> .codehaus
> .plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
> at
> org
> .codehaus
> .mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
> at
> org
> .apache
> .maven
> .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
> 579)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:
> 223)
> at
> org
> .apache
> .maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> at
> org
> .apache
> .maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:
> 904)
> at
> org
> .apache
> .maven
> .embedder
> .MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org
> .codehaus
> .plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:
> 289)
> at
> org
> .codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:
> 229)
> at
> org
> .codehaus
> .plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:
> 408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
> 351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
>
>
>
> Error stacktrace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error
> in the plugin manager executing goal
> 'org.codehaus.mojo:jaxws-maven-plugin:1.11:wsgen': Mojo execution
> failed.
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:
> 223)
> at
> org
> .apache
> .maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> at
> org
> .apache
> .maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:
> 904)
> at
> org
> .apache
> .maven
> .embedder
> .MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org
> .codehaus
> .plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:
> 289)
> at
> org
> .codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:
> 229)
> at
> org
> .codehaus
> .plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:
> 408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
> 351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo
> execution failed.
> at
> org
> .apache
> .maven
> .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
> 601)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> ... 20 more
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> execute wsgen
> at
> org
> .codehaus
> .mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:102)
> at
> org
> .apache
> .maven
> .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
> 579)
> ... 21 more
> Caused by: java.lang.NoClassDefFoundError:
> com/sun/mirror/apt/AnnotationProcessorFactory
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:
> 124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org
> .codehaus
> .plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:
> 174)
> at
> org
> .codehaus
> .plexus
> .classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:
> 67)
> at
> org
> .codehaus
> .plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
> at
> org
> .codehaus
> .mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
> ... 22 more
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Henri Gomez <he...@gmail.com>.
2009/2/18 Brett Porter <br...@apache.org>:
>
> On 18/02/2009, at 7:43 PM, Henri Gomez wrote:
>
>> Question about 2.1.0 / 3.0.0.
>>
>> In 3.0 alpha2 Jason fix a problem with jaxws-maven.
>>
>> Could it be backported to 2.1.0 ?
>
> I believe that problem doesn't affect 2.1.0.
Nope, the jaxws maven plugin didn't works with maven 2.1.0 (at least
the version in m2eclipse 0.9.7) :(
The following mojo encountered an error while executing:
Group-Id: org.codehaus.mojo
Artifact-Id: jaxws-maven-plugin
Version: 1.11
Mojo: wsgen
brought in via: POM
While building project:
Group-Id: mycorp.can
Artifact-Id: mycorp-framework
Version: 2.0.0-19-SNAPSHOT
>From file: C:\workspace-34\mycorp-framework\pom.xml
Reason: Failed to execute wsgen
java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
at org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
at org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
Error stacktrace:
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error
in the plugin manager executing goal
'org.codehaus.mojo:jaxws-maven-plugin:1.11:wsgen': Mojo execution
failed.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo
execution failed.
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
... 20 more
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
execute wsgen
at org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:102)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
... 21 more
Caused by: java.lang.NoClassDefFoundError:
com/sun/mirror/apt/AnnotationProcessorFactory
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
at org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
at org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97)
... 22 more
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
On 18/02/2009, at 7:43 PM, Henri Gomez wrote:
> Question about 2.1.0 / 3.0.0.
>
> In 3.0 alpha2 Jason fix a problem with jaxws-maven.
>
> Could it be backported to 2.1.0 ?
I believe that problem doesn't affect 2.1.0.
>
>
> Also did this new 'mileston' will be used in m2eclipse.
>
> I know Maven 3.0 is the target for m2eclipse but during the intermin,
> having a stable and known 2.1 would be nice.
We're not planning to backport the embedder at this stage, but of
course 2.1.0 will be available as an external installation should you
want to use it that way.
HTH,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Henri Gomez <he...@gmail.com>.
Question about 2.1.0 / 3.0.0.
In 3.0 alpha2 Jason fix a problem with jaxws-maven.
Could it be backported to 2.1.0 ?
Also did this new 'mileston' will be used in m2eclipse.
I know Maven 3.0 is the target for m2eclipse but during the intermin,
having a stable and known 2.1 would be nice.
Regards
2009/2/18 John Casey <jd...@commonjava.org>:
>
> Brett Porter wrote:
>>
>> On 18/02/2009, at 7:23 AM, John Casey wrote:
>>
>>
>> It will take less effort for me to just keep working on issues until they
>> are done, so that's what I'll do. So, agreed, next version is 2.1.0,
>> standard RC cycle applies.
>
> I'm fine whittling away some of what's left out there. I don't think it all
> has to happen in 2.1.0. IMO, we should take care of the four top-voted
> issues if we can - and if we can be relatively sure we're not angering the
> gods with our hubris - then do the rest in 2.1.1.
>
>>> The fourth top issue seems on the face of it to be based on a common
>>> misunderstanding about how profiles are triggered and applied...probably
>>> more of a documentation/education task than anything else.
>>
>> I'm not sure which one you are referring to.
>
> If you look at the 2.1.0 version bucket, enable the display of vote counts,
> and sort on that column, you'll see one pop out related to profiles in the
> parent not being applied to the child. I'm guessing it's just some
> explaining we need to do around that in terms of doco/education, and we're
> done.
>
>>
>>> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
>>> that the wagon version we're using is stable. I seem to remember an issue
>>> coming up shortly after the release of 2.1.0-M1 related to one of the new
>>> Wagon implementations - WebDAV, maybe? I'm having some trouble
>>> remembering/finding that issue in my gmail, but we need to make sure that
>>> doesn't get left out of this release. If it means rolling back to an older
>>> wagon version, then let's do that.
>>
>> It's a regression in the SSH wagon, which I've not been able to reproduce
>> and I never saw an issue filed for. We can wait and see what happens in the
>> RC cycle.
>
> Do you happen to have a Nabble link for that thread? I'll keep searching,
> but it'd be really nice to push that to resolution, as it's probably the
> biggest wart on 2.1.0-M1.
>
> -john
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
On 18/02/2009, at 4:58 PM, John Casey wrote:
>
> Brett Porter wrote:
>> On 18/02/2009, at 7:23 AM, John Casey wrote:
>> It will take less effort for me to just keep working on issues
>> until they are done, so that's what I'll do. So, agreed, next
>> version is 2.1.0, standard RC cycle applies.
>
> I'm fine whittling away some of what's left out there. I don't think
> it all has to happen in 2.1.0. IMO, we should take care of the four
> top-voted issues if we can - and if we can be relatively sure we're
> not angering the gods with our hubris - then do the rest in 2.1.1.
Ok, I dropped a couple of non-controversial ones and assigned some to
self. Some of them have patches so should be quick enough to get in
there.
>
>
>>> Beyond that, I'm alright releasing 2.1.0 final provided we can be
>>> sure that the wagon version we're using is stable. I seem to
>>> remember an issue coming up shortly after the release of 2.1.0-M1
>>> related to one of the new Wagon implementations - WebDAV, maybe?
>>> I'm having some trouble remembering/finding that issue in my
>>> gmail, but we need to make sure that doesn't get left out of this
>>> release. If it means rolling back to an older wagon version, then
>>> let's do that.
>> It's a regression in the SSH wagon, which I've not been able to
>> reproduce and I never saw an issue filed for. We can wait and see
>> what happens in the RC cycle.
>
> Do you happen to have a Nabble link for that thread? I'll keep
> searching, but it'd be really nice to push that to resolution, as
> it's probably the biggest wart on 2.1.0-M1.
I think it's the one from Henrique here: http://markmail.org/thread/2goikjq2x3nqrx5z
I can fiddle around with it again to see if I can reproduce.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
Brett Porter wrote:
>
> On 18/02/2009, at 7:23 AM, John Casey wrote:
>
>
> It will take less effort for me to just keep working on issues until
> they are done, so that's what I'll do. So, agreed, next version is
> 2.1.0, standard RC cycle applies.
I'm fine whittling away some of what's left out there. I don't think it
all has to happen in 2.1.0. IMO, we should take care of the four
top-voted issues if we can - and if we can be relatively sure we're not
angering the gods with our hubris - then do the rest in 2.1.1.
>> The fourth top issue seems on the face of it to be based on a common
>> misunderstanding about how profiles are triggered and
>> applied...probably more of a documentation/education task than
>> anything else.
>
> I'm not sure which one you are referring to.
If you look at the 2.1.0 version bucket, enable the display of vote
counts, and sort on that column, you'll see one pop out related to
profiles in the parent not being applied to the child. I'm guessing it's
just some explaining we need to do around that in terms of
doco/education, and we're done.
>
>> Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
>> that the wagon version we're using is stable. I seem to remember an
>> issue coming up shortly after the release of 2.1.0-M1 related to one
>> of the new Wagon implementations - WebDAV, maybe? I'm having some
>> trouble remembering/finding that issue in my gmail, but we need to
>> make sure that doesn't get left out of this release. If it means
>> rolling back to an older wagon version, then let's do that.
>
> It's a regression in the SSH wagon, which I've not been able to
> reproduce and I never saw an issue filed for. We can wait and see what
> happens in the RC cycle.
Do you happen to have a Nabble link for that thread? I'll keep
searching, but it'd be really nice to push that to resolution, as it's
probably the biggest wart on 2.1.0-M1.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Ralph Goers <ra...@dslextreme.com>.
2.1 has actually served the purpose it was intended for and should be
released. Obviously, the other items that were intended for 2.1
haven't been completed and shouldn't hold things up. So +1 on
releasing 2.1.0 now.
As for the other items that weren't completed, at this point it is
unclear to me whether the items that were on the roadmap are being
fixed in 3.0 or not. I'm still not quite sure how far off the 3.0
release is, but it is looking closer all the time. So I really don't
know if it makes sense to work on those items and target a 2.2 release
or not.
Ralph
On Feb 17, 2009, at 5:35 PM, Brett Porter wrote:
>
> On 18/02/2009, at 7:23 AM, John Casey wrote:
>
>> I fully agree with Brian about the version naming for the next
>> release.
>
> I couldn't possibly care less what version we use at this point,
> only that we start doing releases again. I want to see 2.1 out as
> much as anyone. However, it was frustrating to work the list of
> issues down to 0 and have that pulled away at the last minute. We
> should have stuck with the scheme we had in place already.
>
> It will take less effort for me to just keep working on issues until
> they are done, so that's what I'll do. So, agreed, next version is
> 2.1.0, standard RC cycle applies.
>
>> I thought Oleg was working on MNG-553 still...
>
> It's been closed today, but there is still a snapshot dependency on
> trunk. Oleg, can you release plexus-sec-dispatcher?
>
>> Brett, are you still working on MNG-3379, and did you plan to
>> finish that before we release 2.1.0?
>
> I was waiting for the milestone release before disrupting anything.
> If that's not happening, I'll push that down as soon as I have some
> free time this week.
>
>> The fourth top issue seems on the face of it to be based on a
>> common misunderstanding about how profiles are triggered and
>> applied...probably more of a documentation/education task than
>> anything else.
>
> I'm not sure which one you are referring to.
>
>> Beyond that, I'm alright releasing 2.1.0 final provided we can be
>> sure that the wagon version we're using is stable. I seem to
>> remember an issue coming up shortly after the release of 2.1.0-M1
>> related to one of the new Wagon implementations - WebDAV, maybe?
>> I'm having some trouble remembering/finding that issue in my gmail,
>> but we need to make sure that doesn't get left out of this release.
>> If it means rolling back to an older wagon version, then let's do
>> that.
>
> It's a regression in the SSH wagon, which I've not been able to
> reproduce and I never saw an issue filed for. We can wait and see
> what happens in the RC cycle.
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
On 18/02/2009, at 7:23 AM, John Casey wrote:
> I fully agree with Brian about the version naming for the next
> release.
I couldn't possibly care less what version we use at this point, only
that we start doing releases again. I want to see 2.1 out as much as
anyone. However, it was frustrating to work the list of issues down to
0 and have that pulled away at the last minute. We should have stuck
with the scheme we had in place already.
It will take less effort for me to just keep working on issues until
they are done, so that's what I'll do. So, agreed, next version is
2.1.0, standard RC cycle applies.
> I thought Oleg was working on MNG-553 still...
It's been closed today, but there is still a snapshot dependency on
trunk. Oleg, can you release plexus-sec-dispatcher?
> Brett, are you still working on MNG-3379, and did you plan to finish
> that before we release 2.1.0?
I was waiting for the milestone release before disrupting anything. If
that's not happening, I'll push that down as soon as I have some free
time this week.
> The fourth top issue seems on the face of it to be based on a common
> misunderstanding about how profiles are triggered and
> applied...probably more of a documentation/education task than
> anything else.
I'm not sure which one you are referring to.
> Beyond that, I'm alright releasing 2.1.0 final provided we can be
> sure that the wagon version we're using is stable. I seem to
> remember an issue coming up shortly after the release of 2.1.0-M1
> related to one of the new Wagon implementations - WebDAV, maybe? I'm
> having some trouble remembering/finding that issue in my gmail, but
> we need to make sure that doesn't get left out of this release. If
> it means rolling back to an older wagon version, then let's do that.
It's a regression in the SSH wagon, which I've not been able to
reproduce and I never saw an issue filed for. We can wait and see what
happens in the RC cycle.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
I fully agree with Brian about the version naming for the next release.
Given its track record over the last 6 months, using -M1 for the last
release crippled it unfairly in the public view; it's at least as stable
as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4.
IMO, there is absolutely no reason to do another milestone release. We
should be moving toward 2.1.0 final, resolving the worst regressions and
the most watched/voted-for issues before doing so. Currently, we have
what looks like 4 major issues still unresolved in the 2.1.0 bucket,
judging from the votes. Three of these are in progress, I think. I know
I'm working on MNG-3057, for instance, and I thought Oleg was working on
MNG-553 still...Brett, are you still working on MNG-3379, and did you
plan to finish that before we release 2.1.0? The fourth top issue seems
on the face of it to be based on a common misunderstanding about how
profiles are triggered and applied...probably more of a
documentation/education task than anything else.
Beyond that, I'm alright releasing 2.1.0 final provided we can be sure
that the wagon version we're using is stable. I seem to remember an
issue coming up shortly after the release of 2.1.0-M1 related to one of
the new Wagon implementations - WebDAV, maybe? I'm having some trouble
remembering/finding that issue in my gmail, but we need to make sure
that doesn't get left out of this release. If it means rolling back to
an older wagon version, then let's do that.
I'm not in favor of releasing another milestone of 2.1.0 at this point.
Sure, we should have done more work to execute that release plan last
fall. I for one got very sidetracked putting together a build farm that
we can use to help verify future releases of Maven proactively. In any
case, I think the value of milestone releases is greatly diminished at
this point, and we need to get serious about 2.1.0 final. We can push
off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1
bucket, and get on with it once we have these four dealt with.
-john
Brett Porter wrote:
> So, there seems to be some agreement.
>
> However, I've come back from underground and now there are *two*
> snapshots on trunk. I'm already spending valentine's day alone, so I
> didn't really need another reason to curl up in the corner and cry :)
>
> I would really like to pull an M2 release in the next week with the
> stuff that is already there. John, what do you think?
>
> Thanks,
> Brett
>
> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>
>> Yep good idea.
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>> Porter
>> Sent: Monday, February 09, 2009 7:44 PM
>> To: Maven Developers List
>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>
>>
>>>
>>> I'm +1 for including it and providing an opt-out switch to turn it
>>> off. If we can make that switch stick permanently via the
>>> settings.xml, so much the better.
>>
>> +1 (even better, configure number of parallel threads, just set it to
>> 1 to turn it off).
>>
>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>
>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>> all in agreement about moving directly toward 2.1.0 generally.
>>>
>>
>> Let's slow down a bit...
>>
>> We are totally in agreement to moving towards 2.1.0 generally, and the
>> list in JIRA now reflects that.
>>
>> However, I don't see why we'd cancel a milestone release when there's
>> already been good progress. I was all ready to roll that once the
>> remaining snapshot was released (I've been working on it since
>> December since you said you didn't have time), but now JIRA has been
>> transformed and any release is 23 issues (I'm guessing probably 2
>> weeks minimum) away. Then the RC cycle will be more brutal.
>>
>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>> more intermediate releases.
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Sorry, I only read the first part of your email. I think the controlling the
threads with a setting is a good idea.
I don't see any point in doing another milestone release. The current code
is as stable as 2.0.9/10 yet noone can use it because it's a milestone. It
serves us no point because we don't get any feedback. The original intent of
the milestones was to give the team targets to work towards quickly to get
2.1 out. Since no work was made towards those targets in the last 6 months,
we should just cut the release and move on. When a feature appears and is
ready with tests, then we can include it and release it. The nature of the
oss developent timeline is too haphazard to fully schedule releases like we
tried and in the meantime good code sits unused.
I think we should fix the minimum bugs that are regressions, clean up what
is already there and do a 2.1.0 release asap. Everything else can be 2.2
(features) or 2.1.1 (bugs)
On 2/14/09 7:22 AM, "Brett Porter" <br...@apache.org> wrote:
> So, there seems to be some agreement.
>
> However, I've come back from underground and now there are *two*
> snapshots on trunk. I'm already spending valentine's day alone, so I
> didn't really need another reason to curl up in the corner and cry :)
>
> I would really like to pull an M2 release in the next week with the
> stuff that is already there. John, what do you think?
>
> Thanks,
> Brett
>
> On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
>
>> Yep good idea.
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>> Porter
>> Sent: Monday, February 09, 2009 7:44 PM
>> To: Maven Developers List
>> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>>
>>
>>>
>>> I'm +1 for including it and providing an opt-out switch to turn it
>>> off. If we can make that switch stick permanently via the
>>> settings.xml, so much the better.
>>
>> +1 (even better, configure number of parallel threads, just set it to
>> 1 to turn it off).
>>
>> On 09/02/2009, at 11:18 PM, John Casey wrote:
>>
>>> I'll rearrange the JIRA versions today, then...it looks like we're
>>> all in agreement about moving directly toward 2.1.0 generally.
>>>
>>
>> Let's slow down a bit...
>>
>> We are totally in agreement to moving towards 2.1.0 generally, and the
>> list in JIRA now reflects that.
>>
>> However, I don't see why we'd cancel a milestone release when there's
>> already been good progress. I was all ready to roll that once the
>> remaining snapshot was released (I've been working on it since
>> December since you said you didn't have time), but now JIRA has been
>> transformed and any release is 23 issues (I'm guessing probably 2
>> weeks minimum) away. Then the RC cycle will be more brutal.
>>
>> Why couldn't we stick to the plan as it was yesterday? Same issues,
>> more intermediate releases.
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
So, there seems to be some agreement.
However, I've come back from underground and now there are *two*
snapshots on trunk. I'm already spending valentine's day alone, so I
didn't really need another reason to curl up in the corner and cry :)
I would really like to pull an M2 release in the next week with the
stuff that is already there. John, what do you think?
Thanks,
Brett
On 10/02/2009, at 9:43 AM, Brian E. Fox wrote:
> Yep good idea.
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Monday, February 09, 2009 7:44 PM
> To: Maven Developers List
> Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
>
>>
>> I'm +1 for including it and providing an opt-out switch to turn it
>> off. If we can make that switch stick permanently via the
>> settings.xml, so much the better.
>
> +1 (even better, configure number of parallel threads, just set it to
> 1 to turn it off).
>
> On 09/02/2009, at 11:18 PM, John Casey wrote:
>
>> I'll rearrange the JIRA versions today, then...it looks like we're
>> all in agreement about moving directly toward 2.1.0 generally.
>>
>
> Let's slow down a bit...
>
> We are totally in agreement to moving towards 2.1.0 generally, and the
> list in JIRA now reflects that.
>
> However, I don't see why we'd cancel a milestone release when there's
> already been good progress. I was all ready to roll that once the
> remaining snapshot was released (I've been working on it since
> December since you said you didn't have time), but now JIRA has been
> transformed and any release is 23 issues (I'm guessing probably 2
> weeks minimum) away. Then the RC cycle will be more brutal.
>
> Why couldn't we stick to the plan as it was yesterday? Same issues,
> more intermediate releases.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Yep good idea.
-----Original Message-----
From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
Porter
Sent: Monday, February 09, 2009 7:44 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 Plans (a proposal of sorts)
>
> I'm +1 for including it and providing an opt-out switch to turn it
> off. If we can make that switch stick permanently via the
> settings.xml, so much the better.
+1 (even better, configure number of parallel threads, just set it to
1 to turn it off).
On 09/02/2009, at 11:18 PM, John Casey wrote:
> I'll rearrange the JIRA versions today, then...it looks like we're
> all in agreement about moving directly toward 2.1.0 generally.
>
Let's slow down a bit...
We are totally in agreement to moving towards 2.1.0 generally, and the
list in JIRA now reflects that.
However, I don't see why we'd cancel a milestone release when there's
already been good progress. I was all ready to roll that once the
remaining snapshot was released (I've been working on it since
December since you said you didn't have time), but now JIRA has been
transformed and any release is 23 issues (I'm guessing probably 2
weeks minimum) away. Then the RC cycle will be more brutal.
Why couldn't we stick to the plan as it was yesterday? Same issues,
more intermediate releases.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
>
> I'm +1 for including it and providing an opt-out switch to turn it
> off. If we can make that switch stick permanently via the
> settings.xml, so much the better.
+1 (even better, configure number of parallel threads, just set it to
1 to turn it off).
On 09/02/2009, at 11:18 PM, John Casey wrote:
> I'll rearrange the JIRA versions today, then...it looks like we're
> all in agreement about moving directly toward 2.1.0 generally.
>
Let's slow down a bit...
We are totally in agreement to moving towards 2.1.0 generally, and the
list in JIRA now reflects that.
However, I don't see why we'd cancel a milestone release when there's
already been good progress. I was all ready to roll that once the
remaining snapshot was released (I've been working on it since
December since you said you didn't have time), but now JIRA has been
transformed and any release is 23 issues (I'm guessing probably 2
weeks minimum) away. Then the RC cycle will be more brutal.
Why couldn't we stick to the plan as it was yesterday? Same issues,
more intermediate releases.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Benjamin Bentmann <be...@udo.edu>.
John Casey wrote:
> I'm +1 for including it and providing an opt-out switch to turn it off.
+1
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Stephen Connolly <st...@gmail.com>.
2009/2/9 John Casey <jd...@commonjava.org>:
> I'll rearrange the JIRA versions today, then...it looks like we're all in
> agreement about moving directly toward 2.1.0 generally.
>
> As for the parallel download issue, I guess I'm mainly concerned about
> hidden race conditions, deadlocks, etc. Just because there are 400 people
> using it (guessing, I have no idea how many people use Don's builds) doesn't
> mean they've covered all of the use cases currently active in the Maven
> community.
>
> Since I do understand how hard it can be to nail down concurrency issues in
> any sort of standardized way (the grid builds might be one way, since the
> VMs have multiple CPUs), I understand that we could probably test this for
> another month to the exclusion of everything else and still not be 100%
> sure. So, fine...this is 2.1.0 we're talking about, not 2.1.1, right?
> Anything ending in ".0" is bound to have some small trouble.
>
> To keep from killing all of our users in the event something does go wrong
> (remember, this is central to everything Maven does), I'd be happiest with
> putting in place a switch between new and old style resolution. Maybe we can
> do this by simply introducing a "switching" resolver implementation as the
> component used everywhere by everything, then allowing Maven to set a flag
> on that implementation to let it determine internally which "real"
> implementation to use...a copied-and-patched version that constitutes the
> parallel option, or the old one.
>
> I'm +1 for including it and providing an opt-out switch to turn it off. If
> we can make that switch stick permanently via the settings.xml, so much the
> better.
>
> WDYT?
+1000
>
> -john
>
> Brett Porter wrote:
>>
>> (for some reason this got bounced as spam earlier, so I rewrote it and
>> chopped the quotation in the hope it gets through...)
>>
>> I thought this was already the direction we were going... (see "releasing
>> 2.0.10" thread).
>>
>> I already suggested we drop the auto parent version and PGP stuff from the
>> roadmap, and I'm all for getting to a final release ASAP.
>>
>> Personally, I would still like to give the Doxia change a trial - and
>> should it prove to have *any* problems we pull it back to 2.2. I think this
>> is causing the Doxia guys some grief - so I'd like to hear from them. I'm
>> probably 50/50 on parallel downloads - would prefer to see it in, but not if
>> it requires a lot of integration work or causes problems.
>>
>> We do need the password security changes finished. Oleg, are you working
>> on the docs or should I put them together based on your blog? Is there
>> anything else left to do in the code? I think that dependency needs to be
>> out of alpha before we go final - I think we discussed that sort of criteria
>> for external dependencies a while back.
>>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by John Casey <jd...@commonjava.org>.
I'll rearrange the JIRA versions today, then...it looks like we're all
in agreement about moving directly toward 2.1.0 generally.
As for the parallel download issue, I guess I'm mainly concerned about
hidden race conditions, deadlocks, etc. Just because there are 400
people using it (guessing, I have no idea how many people use Don's
builds) doesn't mean they've covered all of the use cases currently
active in the Maven community.
Since I do understand how hard it can be to nail down concurrency issues
in any sort of standardized way (the grid builds might be one way, since
the VMs have multiple CPUs), I understand that we could probably test
this for another month to the exclusion of everything else and still not
be 100% sure. So, fine...this is 2.1.0 we're talking about, not 2.1.1,
right? Anything ending in ".0" is bound to have some small trouble.
To keep from killing all of our users in the event something does go
wrong (remember, this is central to everything Maven does), I'd be
happiest with putting in place a switch between new and old style
resolution. Maybe we can do this by simply introducing a "switching"
resolver implementation as the component used everywhere by everything,
then allowing Maven to set a flag on that implementation to let it
determine internally which "real" implementation to use...a
copied-and-patched version that constitutes the parallel option, or the
old one.
I'm +1 for including it and providing an opt-out switch to turn it off.
If we can make that switch stick permanently via the settings.xml, so
much the better.
WDYT?
-john
Brett Porter wrote:
> (for some reason this got bounced as spam earlier, so I rewrote it and
> chopped the quotation in the hope it gets through...)
>
> I thought this was already the direction we were going... (see
> "releasing 2.0.10" thread).
>
> I already suggested we drop the auto parent version and PGP stuff from
> the roadmap, and I'm all for getting to a final release ASAP.
>
> Personally, I would still like to give the Doxia change a trial - and
> should it prove to have *any* problems we pull it back to 2.2. I think
> this is causing the Doxia guys some grief - so I'd like to hear from
> them. I'm probably 50/50 on parallel downloads - would prefer to see it
> in, but not if it requires a lot of integration work or causes problems.
>
> We do need the password security changes finished. Oleg, are you working
> on the docs or should I put them together based on your blog? Is there
> anything else left to do in the code? I think that dependency needs to
> be out of alpha before we go final - I think we discussed that sort of
> criteria for external dependencies a while back.
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Arnaud HERITIER <ah...@gmail.com>.
> We do need the password security changes finished. Oleg, are you working on
> the docs or should I put them together based on your blog? Is there anything
> else left to do in the code? I think that dependency needs to be out of
> alpha before we go final - I think we discussed that sort of criteria for
> external dependencies a while back.
>
>
About this issue and oleg's post (
http://www.sonatype.com/people/2009/02/new-feature-maven-settings-password-encryption/)
I think we have also to create new scripts (or add new features in mvn
script) to hide the usage of the DefaultSecDispatcher.
cheers
--
Arnaud
Re: Maven 2.1.0 Plans (a proposal of sorts)
Posted by Brett Porter <br...@apache.org>.
(for some reason this got bounced as spam earlier, so I rewrote it and
chopped the quotation in the hope it gets through...)
I thought this was already the direction we were going... (see
"releasing 2.0.10" thread).
I already suggested we drop the auto parent version and PGP stuff from
the roadmap, and I'm all for getting to a final release ASAP.
Personally, I would still like to give the Doxia change a trial - and
should it prove to have *any* problems we pull it back to 2.2. I think
this is causing the Doxia guys some grief - so I'd like to hear from
them. I'm probably 50/50 on parallel downloads - would prefer to see
it in, but not if it requires a lot of integration work or causes
problems.
We do need the password security changes finished. Oleg, are you
working on the docs or should I put them together based on your blog?
Is there anything else left to do in the code? I think that dependency
needs to be out of alpha before we go final - I think we discussed
that sort of criteria for external dependencies a while back.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/