Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[nicolas de loof]

I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel with
7/8 specific code being used for the JDK that do support them, so I wonder
such a multi-module setup would work in this scenario, or would need yet
another maven module for tests :'(

2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY :

> Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit :
> > I've been giving this subject lots of thought in some of spare time. IMO,
> > the most straightforward way of meeting the requirement of the MVJAR is
> to
> > break up one's JAR project into separate modules. One module would
> contain
> > the version independent code, and then other modules would be per Java
> > version.
> more precisely: the first module would contain the source for minimum Java
> version: sometimes, it will contain code that won't run with later JRE
>
> > This kind of slicing is necessary because you do need different
> > kinds of compiler directives (like -source), different JREs to run unit
> > tests differently, and most importantly, the different JREs to allow
> > debugging according to the Java version you want to test.
> >
> > The other piece that doesn't yet exist is a way to bundle the modules
> into
> > one jar. Perhaps this can be accomplished by introducing a new "mvjar"
> > Maven type.
> I didn't imagine this scenario: no Maven plugins updates nor IDE, "just" a
> new
> feature to merge multiple modules into on MV jar
>
> interesting idea, in fact: this would seriously reduce the impact on
> tooling,
> even if the result is less compact, ie creates a lot of Maven modules
>
> and I am wondering what unit tests will look like for additional versions:
> the
> good thing is that they can be tweaked easily. Then bad thing is that we
> may
> end up in copy/pasting them
>
> Regards,
>
> Hervé
>
> >
> > Paul
> >
> >
> > Cheers,
> > Paul
> >
> > On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY 
> >
> > wrote:
> > > Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
> > > > Technically we support "main" scoped sources in java6 and "test"
> > > > scoped sources in java7 today, but the feature is largely unusable
> > > > since IDE support is totally missing. Even IntelliJ does not support
> > > > it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other
> issues)
> > > >
> > > > :(
> > > >
> > > > There might be some hope of gaining some kind of traction to both
> > > > source and main-level support of multi-language-level modules. Maybe
> > > > something like (src/main/java and src/test/java = "default language"
> > > > level) while src/[main|test]/java-8 would be a specific language
> > > > level. This sounds infinitely cool,
> > >
> > > yes, that's what I did in plexus-utils jdep-238 branch
> > > https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main
> > >
> > > > but also like a great can of worms
> > > >
> > > > :)
> > >
> > > yes, I fear it's not so easy for IDEs...
> > >
> > > > I assume minimum compiler requirement would be java-8 for a project
> > > >
> > > > with src/main/java-8 ?
> > >
> > > yes, I think that's what makes such support hard at the moment: require
> > > the
> > > highest JDK, and signature for every lower JDK to avoid newer APIs
> > > unless JDK 9 can safely compile for any older target, checking the API
> > > (without having to run Animal Sniffer after that)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > > K
> > > >
> > > > 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY :
> > > > > Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
> > > > >> IDE support for multiple source trees seems quite far off ?
> > > > >
> > > > > IDE support for current situation, where we mix multiple Java API
> > >
> > > versions
> > >
> > > > > in one single source tree, is even more far off!
> > > > >
> > > > > With separate source trees, IDE support starts like we are at the
> > >
> > > moment =
> > >
> > > > > no IDE support
> > > > >
> > > > > but IDEs that want to do something about it have a chance: that's
> the
> > >
> > 

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[nicolas de loof]

This was part of the discussion we had with Brian,

The need for "some way" to address multi-JDK target environment without
just using the poorest API is a common thing for tools/framework/library
developers. They use to rely on complex profile-based maven builds,
hack-ish ant/gradle scripts, etc and produce -jdk6 / -jdk7 classified
artifacts. This JEP offer a nice alternative, but this for sure only make
sense if adopted by development tools.

I thing Maven is the one who can help this being a success. If maven do
support multi-version source directories, then for sure Idea will embrace
this and Eclipse as well (but probably later #troll)

In the meantime, lack of IDE support is for sure an issue.
BUT considering JDK7/8/9 features are in most case encapsulated into some
utility class which offer an alternate implementation on lower JDK, and
this is not something you have to work on a daily basis, you can just
configure IDE with the lowest JDK level and ignore errors in the java-7 /
java-8 source tree which only contain some optimized code (or exclude from
IDE), and (temporary) switch to higher JDK when you need to edit them.

As Hervé said, the impact on compiler/jar/resource/surefire plugin has to
be explored, but could probably be implemented today as a PoC with some
dozen lines of plugin executions xml config. I plan to experiment with the
runtime classloader which is able to load the adequate class file depending
on runtime JDK to setup a demo.





2015-04-11 10:54 GMT+02:00 Kristian Rosenvold 
:

> IDE support for multiple source trees seems quite far off ?
>
> Kristian
>
>
> 2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY :
> > Hi,
> >
> > Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof
> and me
> > met Brian Goetz and discussed about the objective of JEP 238 and what we
> could
> > get from such a feature.
> >
> > Having a face to face explanation in front of a white board gave
> interesting
> > ideas: then, *as library maintainer*, I tried to modifiy plexus-utils
> code to
> > use MVJAR for Java 7 enhancement that are currently triggerred through
> > reflection
> >
> >
> > Here is the result [1]:
> >
> > I extracted 2 little xxxMv classes containing only the few methods that
> had to
> > be enhanced when runing on Java 7, replacing the
> > if (Java7Detector.isJava7()) {
> >   // java 7
> > } else {
> >  // Java 5
> > }
> > stanza with the default Java 5 code in the main src/main/java source tree
> > and Java 7 reimplementation in src/main/java-7 source tree
> >
> > and I did cleanup: removed Java7Detector and moved NioFiles to this
> java-7
> > specific source tree
> >
> >
> > the result is a main src/main/java source tree that can be compiled with
> JDK 5
> > and a src/main/java-7 source tree that is minimal to be compiled with
> JDK 7
> >
> >
> > I still didn't try to update pom.xml to see what maven-compiler-plugin
> and
> > maven-jar-plugin configurations could look like.
> >
> > and I don't know if javac will be enhanced to do the 2 compilations in 1
> > command like "javac -target 1.5 src/main/java -target 1.7
> src/main/java-7" or
> > if it'l have to launch 2 javac one after the other
> >
> > I didn't look at maven-jar-plugin to see if it uses "jar" command that
> will be
> > enhanced to mix multiple target/classes or if it uses JarFile class then
> will
> > need to code the mix
> >
> > and I don't know if javac will have tru crossplatform compilation
> option, to
> > avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being sure
> there is
> > no Java 7 API reference, and JDK 7 for the java 7 part)
> >
> >
> > I see there will be impact on tooling, and if javac does a part of the
> job,
> > this will be a lot easier to implement at Maven level
> >
> >
> > But at the moment, my objective was not from Maven point of view but
> library
> > developper point of view: show a real world case of how an existing
> library
> > could be refactored to use the feature, expecting that the new source
> code
> > would be easier to maintain
> >
> >
> > WDYT?
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> >
> > [1]
> https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/java-7/org/codehaus/plexus/util
> >
> > Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit :
> >> Hi,
> >>
> >> we've been asked to give our opinion on the JEP 238: Multi-Version JAR
> >> Files
> &

Re: fix wagon http lightweight

[nicolas de loof]

I merged my fix to 2.x / trunk and committed
I'll no look for a fix on java 1.4 - will probably be a brute force
syncrhonized(LightWeightHttpWagon.class) { ... }

2011/8/28 Mark Struberg 

> In wagon-2.0 we also upgraded from commons-httpclient-3.x to
> httpcomponents.client-4.x. There have been lots of changes under the hood.
> I'd not be surprised if they have also changed the logging. But would need
> to check that.
>
> LieGrue,
> strub
>
> --- On Sun, 8/28/11, nicolas de loof  wrote:
>
> > From: nicolas de loof 
> > Subject: Re: fix wagon http lightweight
> > To: "Maven Developers List" 
> > Date: Sunday, August 28, 2011, 9:30 AM
> > can't we use slf4j to redirect such
> > log to whatever logging system ?
> >
> > 2011/8/28 Olivier Lamy 
> >
> > > Hello
> > > Not so easy for core distrib due to commons-logging
> > dependency which is
> > > exclude.
> > >
> > > --
> > > Olivier
> > > send from a mobile
> > >  Le 28 août 2011 10:05, "nicolas de loof" 
> > a
> > > écrit :
> > > > lightweight-http-wagon
> > > > http-wagon could replace it
> > > >
> > > > 2011/8/28 Mark Struberg 
> > > >
> > > >> Hi Nicolas!
> > > >>
> > > >> Not really sure what you are talking of.
> > Which parts/versions do you
> > > like
> > > >> to deprecate and which part of wagon-webdav
> > got deprecated?
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >> --- On Sun, 8/28/11, nicolas de loof 
> > wrote:
> > > >>
> > > >> > From: nicolas de loof 
> > > >> > Subject: Re: fix wagon http lightweight
> > > >> > To: "Maven Developers List" 
> > > >> > Date: Sunday, August 28, 2011, 7:30 AM
> > > >> > Merge fails, need some rework to
> > > >> > match trunk changes
> > > >> > would be simpler to deprecate and drop
> > this shit out from
> > > >> > repository as we
> > > >> > did for wagon-webdav
> > > >> >
> > > >> > 2011/8/27 Mark Struberg 
> > > >> >
> > > >> > > Nicolas,
> > > >> > >
> > > >> > > I'm currently reviewing your github
> > work. It basically
> > > >> > looks good, but it
> > > >> > > should be applied to trunk
> > (maven-2.x). The changes
> > > >> > you did needs java5, but
> > > >> > > wagon-1.x is still java-1.4 only.
> > Switching to java5
> > > >> > is one of the main
> > > >> > > difference between wagon-1.x and
> > wagon-2.x
> > > >> > >
> > > >> > > The patch should pretty much apply
> > without much
> > > >> > changes.
> > > >> > >
> > > >> > > txs and LieGrue,
> > > >> > > strub
> > > >> > >
> > > >> > > --- On Sat, 8/27/11, nicolas de
> > loof 
> > > >> > wrote:
> > > >> > >
> > > >> > > > From: nicolas de loof 
> > > >> > > > Subject: Re: fix wagon http
> > lightweight
> > > >> > > > To: "Maven Developers List"
> > 
> > > >> > > > Date: Saturday, August 27,
> > 2011, 5:27 AM
> > > >> > > > I just can't get git svn to
> > work and
> > > >> > > > push my changes to wagon 1.x
> > branch
> > > >> > > > feel free to pick-up those
> > changes if you like
> > > >> > them
> > > >> > > >
> > > >> > > > 2011/8/24 nicolas de loof
> > 
> > > >> > > >
> > > >> > > > > I'm testing a fix for
> > WAGON-346<
> > > >> > > http://jira.codehaus.org/browse/WAGON-346> and
> > > >> > > > > WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> > > >> > > > > Before I commit anything
> > to svn I'd like
> > > >> > your advice :
> > > >> > > > see
> > > >> > > > > https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
> > > >> > > > >
> > > >> > > > > The idea to make
> > LightWeightHttpWagon
> > > >> > thread-safe
> > > >> > > > despite the
> > > >> > > > > java.net.Authenticator
> > static singleton, is
> > > >> > to have a
> > > >> > > > custom Authenticator
> > > >> > > > > shared component and
> > callback methods to the
> > > >> > wagon
> > > >> > > > instance, using a
> > > >> > > > > ThreadLocal to keep track
> > of "current"
> > > >> > wagon
> > > >> > > > >
> > > >> > > > > For WAGON-347 the
> > preemptive authentication
> > > >> > can be
> > > >> > > > configured either per
> > > >> > > > > repository using a
> > > >> > "preemptiveAuthentication"
> > > >> > > > parameter, or system wide
> > > >> > > > > using
> > > >> > > >
> > -Dmaven.wagon.http.preemptiveAuthentication=true
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > -
> > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>
> > > >>
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: fix wagon http lightweight

[nicolas de loof]

can't we use slf4j to redirect such log to whatever logging system ?

2011/8/28 Olivier Lamy 

> Hello
> Not so easy for core distrib due to commons-logging dependency which is
> exclude.
>
> --
> Olivier
> send from a mobile
>  Le 28 août 2011 10:05, "nicolas de loof"  a
> écrit :
> > lightweight-http-wagon
> > http-wagon could replace it
> >
> > 2011/8/28 Mark Struberg 
> >
> >> Hi Nicolas!
> >>
> >> Not really sure what you are talking of. Which parts/versions do you
> like
> >> to deprecate and which part of wagon-webdav got deprecated?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> --- On Sun, 8/28/11, nicolas de loof  wrote:
> >>
> >> > From: nicolas de loof 
> >> > Subject: Re: fix wagon http lightweight
> >> > To: "Maven Developers List" 
> >> > Date: Sunday, August 28, 2011, 7:30 AM
> >> > Merge fails, need some rework to
> >> > match trunk changes
> >> > would be simpler to deprecate and drop this shit out from
> >> > repository as we
> >> > did for wagon-webdav
> >> >
> >> > 2011/8/27 Mark Struberg 
> >> >
> >> > > Nicolas,
> >> > >
> >> > > I'm currently reviewing your github work. It basically
> >> > looks good, but it
> >> > > should be applied to trunk (maven-2.x). The changes
> >> > you did needs java5, but
> >> > > wagon-1.x is still java-1.4 only. Switching to java5
> >> > is one of the main
> >> > > difference between wagon-1.x and wagon-2.x
> >> > >
> >> > > The patch should pretty much apply without much
> >> > changes.
> >> > >
> >> > > txs and LieGrue,
> >> > > strub
> >> > >
> >> > > --- On Sat, 8/27/11, nicolas de loof 
> >> > wrote:
> >> > >
> >> > > > From: nicolas de loof 
> >> > > > Subject: Re: fix wagon http lightweight
> >> > > > To: "Maven Developers List" 
> >> > > > Date: Saturday, August 27, 2011, 5:27 AM
> >> > > > I just can't get git svn to work and
> >> > > > push my changes to wagon 1.x branch
> >> > > > feel free to pick-up those changes if you like
> >> > them
> >> > > >
> >> > > > 2011/8/24 nicolas de loof 
> >> > > >
> >> > > > > I'm testing a fix for WAGON-346<
> >> > > http://jira.codehaus.org/browse/WAGON-346> and
> >> > > > > WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> >> > > > > Before I commit anything to svn I'd like
> >> > your advice :
> >> > > > see
> >> > > > > https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
> >> > > > >
> >> > > > > The idea to make LightWeightHttpWagon
> >> > thread-safe
> >> > > > despite the
> >> > > > > java.net.Authenticator static singleton, is
> >> > to have a
> >> > > > custom Authenticator
> >> > > > > shared component and callback methods to the
> >> > wagon
> >> > > > instance, using a
> >> > > > > ThreadLocal to keep track of "current"
> >> > wagon
> >> > > > >
> >> > > > > For WAGON-347 the preemptive authentication
> >> > can be
> >> > > > configured either per
> >> > > > > repository using a
> >> > "preemptiveAuthentication"
> >> > > > parameter, or system wide
> >> > > > > using
> >> > > > -Dmaven.wagon.http.preemptiveAuthentication=true
> >> > > > >
> >> > > >
> >> > >
> >> > >
> >> > -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >> > >
> >> > >
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: fix wagon http lightweight

[nicolas de loof]

except for getting volunteers, why shouldn't we be able to release pretty
quickly ?
jenkins releases every week :P

2011/8/28 Mark Struberg 

> yea, wagon-http-lightweight has lots of systematic problems. Mainly the
> inability to correctly handle files which are bigger than the memory given
> via -Xmx
>
> I think John tried once to deprecate the lightweight provider, but then
> reverted it back because we got quite a few bugs reported for wagon-http. I
> think it is worth it to try it again and this time to just fix the bugs in
> wagon-http.
>
> Of course this would mean that we should be ready to release 2 or 3 new
> wagon + maven versions pretty quickly...
>
> LieGrue,
> strub
>
> --- On Sun, 8/28/11, nicolas de loof  wrote:
>
> > From: nicolas de loof 
> > Subject: Re: fix wagon http lightweight
> > To: "Maven Developers List" 
> > Date: Sunday, August 28, 2011, 8:04 AM
> > lightweight-http-wagon
> > http-wagon could replace it
> >
> > 2011/8/28 Mark Struberg 
> >
> > > Hi Nicolas!
> > >
> > > Not really sure what you are talking of. Which
> > parts/versions do you like
> > > to deprecate and which part of wagon-webdav got
> > deprecated?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > --- On Sun, 8/28/11, nicolas de loof 
> > wrote:
> > >
> > > > From: nicolas de loof 
> > > > Subject: Re: fix wagon http lightweight
> > > > To: "Maven Developers List" 
> > > > Date: Sunday, August 28, 2011, 7:30 AM
> > > > Merge fails, need some rework to
> > > > match trunk changes
> > > > would be simpler to deprecate and drop this shit
> > out from
> > > > repository as we
> > > > did for wagon-webdav
> > > >
> > > > 2011/8/27 Mark Struberg 
> > > >
> > > > > Nicolas,
> > > > >
> > > > > I'm currently reviewing your github work. It
> > basically
> > > > looks good, but it
> > > > > should be applied to trunk (maven-2.x). The
> > changes
> > > > you did needs java5, but
> > > > > wagon-1.x is still java-1.4 only. Switching
> > to java5
> > > > is one of the main
> > > > > difference between wagon-1.x and wagon-2.x
> > > > >
> > > > > The patch should pretty much apply without
> > much
> > > > changes.
> > > > >
> > > > > txs and LieGrue,
> > > > > strub
> > > > >
> > > > > --- On Sat, 8/27/11, nicolas de loof 
> > > > wrote:
> > > > >
> > > > > > From: nicolas de loof 
> > > > > > Subject: Re: fix wagon http
> > lightweight
> > > > > > To: "Maven Developers List" 
> > > > > > Date: Saturday, August 27, 2011, 5:27
> > AM
> > > > > > I just can't get git svn to work and
> > > > > > push my changes to wagon 1.x branch
> > > > > > feel free to pick-up those changes if
> > you like
> > > > them
> > > > > >
> > > > > > 2011/8/24 nicolas de loof 
> > > > > >
> > > > > > > I'm testing a fix for
> > WAGON-346<
> > > > > http://jira.codehaus.org/browse/WAGON-346> and
> > > > > > > WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> > > > > > > Before I commit anything to svn
> > I'd like
> > > > your advice :
> > > > > > see
> > > > > > > https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
> > > > > > >
> > > > > > > The idea to make
> > LightWeightHttpWagon
> > > > thread-safe
> > > > > > despite the
> > > > > > > java.net.Authenticator static
> > singleton, is
> > > > to have a
> > > > > > custom Authenticator
> > > > > > > shared component and callback
> > methods to the
> > > > wagon
> > > > > > instance, using a
> > > > > > > ThreadLocal to keep track of
> > "current"
> > > > wagon
> > > > > > >
> > > > > > > For WAGON-347 the preemptive
> > authentication
> > > > can be
> > > > > > configured either per
> > > > > > > repository using a
> > > > "preemptiveAuthentication"
> > > > > > parameter, or system wide
> > > > > > > using
> > > > > >
> > -Dmaven.wagon.http.preemptiveAuthentication=true
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: fix wagon http lightweight

[nicolas de loof]

lightweight-http-wagon
http-wagon could replace it

2011/8/28 Mark Struberg 

> Hi Nicolas!
>
> Not really sure what you are talking of. Which parts/versions do you like
> to deprecate and which part of wagon-webdav got deprecated?
>
> LieGrue,
> strub
>
>
> --- On Sun, 8/28/11, nicolas de loof  wrote:
>
> > From: nicolas de loof 
> > Subject: Re: fix wagon http lightweight
> > To: "Maven Developers List" 
> > Date: Sunday, August 28, 2011, 7:30 AM
> > Merge fails, need some rework to
> > match trunk changes
> > would be simpler to deprecate and drop this shit out from
> > repository as we
> > did for wagon-webdav
> >
> > 2011/8/27 Mark Struberg 
> >
> > > Nicolas,
> > >
> > > I'm currently reviewing your github work. It basically
> > looks good, but it
> > > should be applied to trunk (maven-2.x). The changes
> > you did needs java5, but
> > > wagon-1.x is still java-1.4 only. Switching to java5
> > is one of the main
> > > difference between wagon-1.x and wagon-2.x
> > >
> > > The patch should pretty much apply without much
> > changes.
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > > --- On Sat, 8/27/11, nicolas de loof 
> > wrote:
> > >
> > > > From: nicolas de loof 
> > > > Subject: Re: fix wagon http lightweight
> > > > To: "Maven Developers List" 
> > > > Date: Saturday, August 27, 2011, 5:27 AM
> > > > I just can't get git svn to work and
> > > > push my changes to wagon 1.x branch
> > > > feel free to pick-up those changes if you like
> > them
> > > >
> > > > 2011/8/24 nicolas de loof 
> > > >
> > > > > I'm testing a fix for WAGON-346<
> > > http://jira.codehaus.org/browse/WAGON-346> and
> > > > > WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> > > > > Before I commit anything to svn I'd like
> > your advice :
> > > > see
> > > > > https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
> > > > >
> > > > > The idea to make LightWeightHttpWagon
> > thread-safe
> > > > despite the
> > > > > java.net.Authenticator static singleton, is
> > to have a
> > > > custom Authenticator
> > > > > shared component and callback methods to the
> > wagon
> > > > instance, using a
> > > > > ThreadLocal to keep track of "current"
> > wagon
> > > > >
> > > > > For WAGON-347 the preemptive authentication
> > can be
> > > > configured either per
> > > > > repository using a
> > "preemptiveAuthentication"
> > > > parameter, or system wide
> > > > > using
> > > > -Dmaven.wagon.http.preemptiveAuthentication=true
> > > > >
> > > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: fix wagon http lightweight

[nicolas de loof]

Merge fails, need some rework to match trunk changes
would be simpler to deprecate and drop this shit out from repository as we
did for wagon-webdav

2011/8/27 Mark Struberg 

> Nicolas,
>
> I'm currently reviewing your github work. It basically looks good, but it
> should be applied to trunk (maven-2.x). The changes you did needs java5, but
> wagon-1.x is still java-1.4 only. Switching to java5 is one of the main
> difference between wagon-1.x and wagon-2.x
>
> The patch should pretty much apply without much changes.
>
> txs and LieGrue,
> strub
>
> --- On Sat, 8/27/11, nicolas de loof  wrote:
>
> > From: nicolas de loof 
> > Subject: Re: fix wagon http lightweight
> > To: "Maven Developers List" 
> > Date: Saturday, August 27, 2011, 5:27 AM
> > I just can't get git svn to work and
> > push my changes to wagon 1.x branch
> > feel free to pick-up those changes if you like them
> >
> > 2011/8/24 nicolas de loof 
> >
> > > I'm testing a fix for WAGON-346<
> http://jira.codehaus.org/browse/WAGON-346> and
> > > WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> > > Before I commit anything to svn I'd like your advice :
> > see
> > > https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
> > >
> > > The idea to make LightWeightHttpWagon thread-safe
> > despite the
> > > java.net.Authenticator static singleton, is to have a
> > custom Authenticator
> > > shared component and callback methods to the wagon
> > instance, using a
> > > ThreadLocal to keep track of "current" wagon
> > >
> > > For WAGON-347 the preemptive authentication can be
> > configured either per
> > > repository using a "preemptiveAuthentication"
> > parameter, or system wide
> > > using
> > -Dmaven.wagon.http.preemptiveAuthentication=true
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: fix wagon http lightweight

[nicolas de loof]

I just can't get git svn to work and push my changes to wagon 1.x branch
feel free to pick-up those changes if you like them

2011/8/24 nicolas de loof 

> I'm testing a fix for WAGON-346<http://jira.codehaus.org/browse/WAGON-346> and
> WAGON-347 <http://jira.codehaus.org/browse/WAGON-347>
> Before I commit anything to svn I'd like your advice : see
> https://github.com/ndeloof/maven-wagon/tree/wagon-1.x
>
> The idea to make LightWeightHttpWagon thread-safe despite the
> java.net.Authenticator static singleton, is to have a custom Authenticator
> shared component and callback methods to the wagon instance, using a
> ThreadLocal to keep track of "current" wagon
>
> For WAGON-347 the preemptive authentication can be configured either per
> repository using a "preemptiveAuthentication" parameter, or system wide
> using -Dmaven.wagon.http.preemptiveAuthentication=true
>

fix wagon http lightweight

[nicolas de loof]

I'm testing a fix for WAGON-346  and
WAGON-347 
Before I commit anything to svn I'd like your advice : see
https://github.com/ndeloof/maven-wagon/tree/wagon-1.x

The idea to make LightWeightHttpWagon thread-safe despite the
java.net.Authenticator static singleton, is to have a custom Authenticator
shared component and callback methods to the wagon instance, using a
ThreadLocal to keep track of "current" wagon

For WAGON-347 the preemptive authentication can be configured either per
repository using a "preemptiveAuthentication" parameter, or system wide
using -Dmaven.wagon.http.preemptiveAuthentication=true

Re: Improvement in wagon-http (use http connection pooling from ASF httpclient)

[nicolas de loof]

+1 to set this as default
why use system properties to set this flag and not use a per-instance
configuration ?

2011/8/24 Olivier Lamy 

> Hello Folks,
> I have just loaded an issue [1] regarding an improvement for wagon
> http (the wagon http which use asf httpclient).
> This small improvement will simply add a connection pooling mechanism
> to avoid http(s) connection for artifacts requests.
>
> My first idea was to not enable it by default but using a sysprops to
> enable it : -Dmaven.wagon.http.connectionManager.multihreaded=true .
> But IMHO this could be activate by default (with a flag to desactivate it).
>
> WDYT ?
>
> Thanks,
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> [1] : https://jira.codehaus.org/browse/WAGON-348
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: svn commit: r1127427 - /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/Base64Test.java

[nicolas de loof]

Fun to know we will have to hack commons-io to backport plexus-utils bugs ;)

2011/5/25 Stephen Connolly 

> These were Nicolas' tests, but a good catch and I've made the change.
>
> BTW, the aim here is to reproduce the bugs for the first go... so if
> Plexus Utils is incorrectly using platform encoding then actually the
> test would be correct! So it may be that we revert this... should
> probably add an annotation around tests which are testing bugs
>
> On 25 May 2011 09:48, Hervé BOUTEMY  wrote:
> > notice that encoding (US-ASCII or UTF-8) should be precised both when
> > converting String to byte[] and byte[] to String, or you're implicitely
> using
> > platform encoding which is not the best: if anybody tries to run tests on
> an
> > EBCDIC platform, they will fail (I know, this is quite rare, but that's
> > chicken and egg problem: it is rare because it always fail for stupid
> reasons,
> > then nobody takes care of such little things)
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 25 mai 2011, steph...@apache.org a écrit :
> >> +assertThat( new String( new Base64().encode( "test".getBytes()
> )
> >> ), is( "dGVzdA==" ) ); }
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM 4+ was Re: Moving forward with mixins

[nicolas de loof]

+1, simple and efficient

2011/5/24 Stephen Connolly 

> deploy new poms as poms with classifier
>
> new maven tries to download pom with classifier... fails and falls
> back to pom without
>
> old maven only ever sees pom without classifier
>
> 2011/5/24 Arnaud Héritier :
> > It doesn't seem so easy for me.
> > If we deploy 4.0.0 only we'll never be able to reuse new POMs in the
> build
> > process by inheritance for example.
> > Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility but
> > won't allow us to evolve.
> > The problem is how to depend and how to extend (without talking about a
> > future : how to mix..)
> >
> >
> > On Tue, May 24, 2011 at 4:09 PM, John Casey 
> wrote:
> >
> >>
> >>
> >> On 5/24/11 8:25 AM, Brian Fox wrote:
> >>
> >>> 2011/5/24 Arnaud Héritier:
> >>>
>  Before talking about a specific change in the model like the addition
> of
>  mixins (which may be cool but not critical) did we :
>  - studied that we had everything necessary to manage new versions of
> POMs
>  with something a little bit dynamic inside the core and all that is
>  necessary on repositories side ?
>  - studied if we couldn't start by really simple issues that may
> already
>  do a
>  very useful 3.1 version like the addition of global exclusions ?
> 
> 
> >>> I didn't read the proposal in detail yet, but my initial concern was
> >>> on pom compat as well.
> >>>
> >>
> >> I think doing some sort of on-the-fly translation into a 4.0.0 POM
> purely
> >> to be deployed for backwards compat would be enough here...though we may
> >> want to explore how we could make Maven smart enough to say, "I can't
> read
> >> this POM, use a later version" or somesuch...
> >>
> >>
> >>
> >>>
> >>>  Arnaud
> 
>  On Tue, May 24, 2011 at 7:30 AM, Brett Porter
>  wrote:
> 
>   Hi,
> >
> > I'm working with some projects at the moment that have a high amount
> of
> > repetition in the build section (and in some cases dependencies), but
> no
> > common parent due to different organisational hierarchies. Currently
> > it's
> > being solved by using archetypes to create projects consistently, but
> it
> > isn't very satisfying if someone wants to change the archetype later
> on.
> > I've minimised that by limiting what needs to change between projects
> > based
> > on the archetype, but it is exactly the situation that calls for
> mixins.
> >
> > At the same time, this issue was filed today:
> > http://jira.codehaus.org/browse/MNG-5102, and I was surprised not to
> > find
> > a dupe given how often it has come up here.
> >
> > Previous discussions I found:
> > http://s.apache.org/maven-mixin-1
> > http://s.apache.org/maven-mixin-2
> > http://s.apache.org/maven-mixin-3
> > http://s.apache.org/maven-mixin-4
> >
> > I don't see any concrete proposals, other than the notes from Jason
> > Dillon.
> > So, I thought I'd start collecting them here.
> >
> > I actually prefer the name "template", so I'll use that here, but
> happy
> > to
> > take other's opinions on that.
> >
> > --
> >
> > Pre-requisites: the ability to make modifications to the POM,
> published
> > to
> > the repository, without impacting older clients. This needs an issue
> of
> > it's
> > own, but I don't think it's challenging if we continue to spit out
> > v4.0.0 to
> > the repository.
> >
> > Some notes on how I think it should work:
> > - templates should look like a normal POM (perhaps only differing in
> > root
> > element, and less strict validation requirements), so that normal
> > validation
> > can be applied
> > - any POM element is valid, other
> than,,,
> > ,,
> > - templates need to be sourced from the repository using the normal
> > mechanism (similarly to the parent POM)
> > - templates should have an extension "xml" in the repository. It is
> > attached to the corresponding POM project with packaging
> "pom-template".
> > Multiple templates can be attached using classifiers. The POM of the
> > template must be separate to the template itself, as some elements
> would
> > otherwise overlap (e.g.  of the template vs the templated name,
> or
> > distributionManagement)
> > - we rely on the later interpolation step to resolve variables -
> there
> > should be no filtering or macro capability on the template
> > - there should be no additional merge semantics - I think they can be
> > handled very similarly to external profiles in terms of building
> > - there should be no conditionals within or around the template
> (that's
> > the
> > purpose of profiles)
> >
> > I think that makes the sequence of project building:
> > - parents&  templates are resolved
> > - templates are injected, sequentially as declared in the POM. Note
> th

Re: svn commit: r1127056 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: ./ plexus-utils-commons-bridge/ plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/ plexus-utils-tck/src

[nicolas de loof]

> +assertEquals("dGVzdA==", new Base64().encode("test".getBytes()));
>
> assertThat with the matchers is far nicer, but if you like keeping it
> old-style I'm fine with that!
>
>
I'm not used with matchers (maybe I should be deprecated and replaced by
some nicolas-update-bridge),
can you please provide a sample in such case ?

Re: POM 4+ was Re: Moving forward with mixins

[nicolas de loof]

>
> I think doing some sort of on-the-fly translation into a 4.0.0 POM purely
> to be deployed for backwards compat would be enough here...though we may
> want to explore how we could make Maven smart enough to say, "I can't read
> this POM, use a later version" or somesuch...
>
> Why only consider deployed POM for backward compatibility ? Same system may
use older maven somewhere else and still share the localRepository. We
should either always translate the POM to 4.0.0 even during install, or do
some sort of double-versioning.

Re: Anyone want to help?

[nicolas de loof]

Oups, moved to

https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement

2011/5/24 Olivier Lamy 

> 2011/5/24 nicolas de loof :
> >>
> >> +1 and Nike it: Just do it(tm)
> >>
> >
> > http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
> >
>
> Thanks.
> But personnally I would prefer we use Apache confluence :
> https://cwiki.apache.org/confluence/display/MAVEN .
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://www.linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Anyone want to help?

[nicolas de loof]

>
> +1 and Nike it: Just do it(tm)
>

http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement

Re: Anyone want to help?

[nicolas de loof]

I'd be pleased to join,
(let's drop this dinosaur)

Should we setup a wiki page to know who is working on wich part, let
contributors pick-up tasks, and trace progess ?
Should we clone the svn repo to github / apache extras so that non-apache
contributors can help (I'm an optimistic naive guy :P)

Cheers,
Nicolas

2011/5/24 Stephen Connolly 

> I'm working on providing a compatibility layer for plexus-utils that
> uses the commons-* stuff to provide the implementation.
>
> If anyone is interested in helping please shout out.
>
> Most of the work is actually writing the crazy test cases, everything
> else should be simple shims through to existing commons functionality.
>
> You can join in here if you are an Apache Committer (sandbox is open
> to all Apache Committers)
>
> https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
>
> Pick a plexus-utils class, and start creating tests... better still
> write the tests black box (that's what I am doing!)
>
> Then when you have some tests written in the TCK module, create the
> implementation class with all the methods:
>
> { throw new UnsupportedOperationException("Not implemented yet!"); }
>
> and then you can knock off implementations and see your test pass rate
> rise in the bridge module.
>
> I'm tackling IOUtil first and then PropertyUtils.
>
> To stake your claim, commit the test case class first and then unless
> you tell us otherwise you are working on that class!
>
> -Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Surefire Plugin version 2.8

[nicolas de loof]

+1

2011/3/10 Olivier Lamy 

> +1
>
> Thanks !
> --
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
>
> 2011/3/9 Kristian Rosenvold :
> > Hi,
> >
> > We solved 16 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=17039
> >
> > The ability to run a single test method is the new feature in this
> > release: http://jira.codehaus.org/browse/SUREFIRE-577
> > A significant memory leak fix for those with really long reactor builds:
> > http://jira.codehaus.org/browse/SUREFIRE-711
> > Also noteworthy is http://jira.codehaus.org/browse/SUREFIRE-700, which
> > has been hampering evolution of surefire itself severely for years.
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-009/
> >
> > Staging site: (Sync pending)
> > http://maven.apache.org/plugins/maven-surefire-plugin-2.8/
> > http://maven.apache.org/plugins/maven-failsafe-plugin-2.8/
> > http://maven.apache.org/plugins/maven-surefire-report-plugin-2.8/
> > http://maven.apache.org/surefire/staging/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > And here's my +1
> >
> >
> > Kristian
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.0.3

[nicolas de loof]

+1

Le 1 mars 2011 09:28, Arnaud Héritier  a
écrit :

> +1
>
> Arnaud
>
> On Tue, Mar 1, 2011 at 2:40 PM, Mark Derricutt  wrote:
>
> > -1 non binding - I had that null version issue earlier.  Now home and
> will
> > try to reproduce it with a currently nightly.
> >
> >
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
> >
> > 2011/3/1 Tamás Cservenák 
> >
> > > +1
> > > On Feb 28, 2011 6:59 PM, "Benjamin Bentmann" <
> benjamin.bentm...@udo.edu>
> > > wrote:
> > > > Hi,
> > > >
> > > > Thanks to those who tested the RC, I think we can move on to the real
> > > > thing now.
> > > >
> > > > We solved 29 issues since 3.0.2:
> > > >
> > >
> > >
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=17061
> > > >
> > > > There are still a couple of issues left in JIRA:
> > > >
> > >
> > >
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-065/
> > > >
> > > > Staged source and binary distros:
> > > >
> > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.0.3/
> > > >
> > > > Guide to testing staged releases:
> > > >
> http://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > +1 from me
> > > >
> > > >
> > > > Benjamin
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> >
>

Re: [VOTE] Release Maven Resources Plugin version 2.5

[nicolas de loof]

+1

2011/2/26 Hervé BOUTEMY 

> +1
>
> Hervé
>
> Le jeudi 24 février 2011, Dennis Lundberg a écrit :
> > Hi,
> >
> > We solved 5 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11145&styleName=
> > Html&version=16232
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11145&st
> > atus=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-047/
> >
> > Staging site:
> > http://maven.apache.org/plugins/maven-resources-plugin-2.5/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: How to compile code using maven

[nicolas de loof]

Don't consider Maven as a scripting engine
Maven works based on conventions, and plugins use them to avoid
configuration and scripting

Don't try to override conventions as you do in compiler, war plugin. Follow
them and discover how the plugins can naturaly run in your build without
anything to configure.

Move your java source folder at "src/main/java"
Move your web application descriptor at src/main/webapp/WEB-INF
remove all your configuration stuff, especially your antrun attempt to
script the build
just run "mvn install"

you will get a packaged WAR you can deploy on tomcat,
you can also configure your local tomcat instance to use the exploded war at
target/youratifact-version

Good luck with Maven
(I just suggest you to take few minutes and read a good introduction to
maven to better understand its principles)

Nicolas

2011/2/23 Fuke, Amol 

> Hi All,
>
>
>
> I have ant build file and now need to convert it into mvn pom file. My
> problem is how do I get my code compiled using pom.xml.
>
>
>
> I have below pom xml;
>
> ***
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>
>  4.0.0
>
>  com.nielsen.outbound
>
>  outbound
>
>  war
>
>  1.0-SNAPSHOT
>
>  outbound
>
>  http://maven.apache.org
>
>  
>
>
>
>  junit
>
>  junit
>
>  3.8.1
>
>  test
>
>
>
>  
>
>  
>
>  
>
>  
>
>org.apache.maven.plugins
>
>maven-compiler-plugin
>
>
>
>
> src/com/nielsen/outbound/*.java
>
>  target/classes
>
>
>
>  
>
>  
>
>org.apache.maven.plugins
>
>maven-war-plugin
>
>
>
>  conf/web.xml
>
>
> target/work/outbound.war
>
>
>
>  
>
>  
>
>org.apache.maven.plugins
>
>maven-antrun-plugin
>
>
>
>  
>
>compile
>
>
>
>  
>
>Deleting
> deployment..
>
> includeEmptyDirs="true"
>
>
> dir="C:/Tomcat6/webapps/outbound" />
>
> dir="C:/Tomcat6/webapps/outbound" />
>
>  
>
>
>
>
>
>  run
>
>
>
>  
>
>  
>
>compile
>
>copy-resources2classes
>
>
>
>  
>
>Copying resources
> to WEB-INF/classes..
>
>
>
>   dir="target/classes" >
>
> name="**/*.properties" />
>
> name="**/*.*" />
>
>  
>
>
>
>  
>
>
>
>
>
>  run
>
>
>
>  
>
>
>
>  
>
>  
>
> 
>
> 
>
> **
>
>
>
> Can you please help me ?
>
>
>
> Thanks,
>
> Amol Fuke
>
>
>
>

Re: [PROPOSAL] Auto-Mirror Selection for Maven 3.x

[nicolas de loof]

I really like this feature suggest, and it would be a must-have if also
backported to maven2 !

Having to maintain mirroring based on declared repositories ID is a pain,
especially when transitive dependencies pull multiple IDs for the same repo
URL. From your schema, it seems the routing rules are based on target URL,
that would solve this with a centralized setup.

I'll take a look at code ASAP.
Nicolas

2011/2/19 Stephen Connolly 

> Yep
>
> On 18 February 2011 22:39, John Casey  wrote:
>
> > So you're saying it would work with existing releases of Maven, like
> 2.2.1?
> > I'd be very interested to see that.
> >
> > -john
> >
> >
> > On 2/18/11 5:23 PM, Stephen Connolly wrote:
> >
> >> I'll have a look at your branch, but I have an alternative proposal that
> >> can
> >> (I think) be made to work for any version of maven, perhaps ivy too all
> by
> >> just dropping a jar into the lib folder... I'll have to flesh it out to
> >> confirm my theory. I'll be on two long flights at the start of march, so
> I
> >> hope to be able to share something the 2nd week march
> >>
> >> - Stephen
> >>
> >> ---
> >> Sent from my Android phone, so random spelling mistakes, random nonsense
> >> words and other nonsense are a direct result of using swype to type on
> the
> >> screen
> >> On 18 Feb 2011 22:10, "John Casey"  wrote:
> >>
> >>
> > --
> > John Casey
> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
> > Blog: http://www.johnofalltrades.name/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml

[nicolas de loof]

2011/2/11 Jesse Farinacci 

> Hi,
>
> On Fri, Feb 11, 2011 at 7:58 AM, nicolas de loof
>  wrote:
> > It does, since version 2.3, but the version set by super-pom is more
> > conservative
> > Maybe you suggested Apache POM should set a recent compiler plugin
> version ?
>
> Check http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup
> line 126-127. If you're going to bump from the ancient Maven 2.0.x
> line to Maven 2.2.x line, why not go all the way? Let's get default
> values out of 1990s and into 2000s. :-)
>

I missed this one.
+1 to start working in XIth century ;)



>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml

[nicolas de loof]

>
>
> By that logic, which I happen to agree with, then shouldn't the
> compiler plugin start using 1.5 by default then?
>

It does, since version 2.3, but the version set by super-pom is more
conservative
Maybe you suggested Apache POM should set a recent compiler plugin version ?

Nicolas


>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Create a enforcer-incubator-rules project (was:Re: MENFORCER-19 (enforce dependencyManagement))

[nicolas de loof]

Brian, I'll then close MENFORCER-19 and comment with a link to
dependency:analyse-dpt-mgt

Baptiste, Mojo.codehaus.org could be a good place for such
contributor-driven incubator.
We allready merged some major mojo plugins into maven ones.

2011/2/3 Baptiste MATHUS 

> Hi all,
>
> I've been thinking about enforcer rules for some times.
> I think it would be a good thing to have a kind of enforcer-rules-incubator
> project somewhere that would encourage users share¢ralize their rules.
>
> I personnally have already written rules that I think are not very specific
> to my organization (forbid putting true inside surefire conf,
> for example). I already considered pushing it somewhere, but even if
> creating a new project each time would indeed work, I really think it would
> be a bad thing for users (Maven ecosystem is already an enough
> diluted/large/complex one to add so many small projects).
> I think Maven community should encourage users to grow/contribute their
> rules to the standard rulesets, by creating for example an
> enforcer-incubator-rules project that would be a sandbox for rules that
> might become promoted in the standard ruleset when stable/interesting.
>
> WDYT?
>
> Cheers
>
> 2011/2/2 Brian Fox 
>
> > You could simply add a flag or alternate mojo to the dependency plugin
> > to allow it to fail. IIRC the analyze goal already does this. IOW it's
> > not a requirement that every mojo that fails a build be rolled into
> > the enforcer plugin. Failing that, you'd have to pull all the logic
> > out into a shared component.
> >
> > On Wed, Feb 2, 2011 at 8:16 AM, nicolas de loof
> >  wrote:
> > > Hi folks,
> > >
> > > I'd like to work on MENFORCER-19,
> > > org.apache.maven.plugin.dependency.AnalyzeDepMgt has all the necessary
> > code
> > > to create an EnforcerRule "EnforceDependencyManagement", but I wonder
> how
> > we
> > > should manage such code duplication. Copy/paste some hundred lines from
> > > dependency plugin into enforcer-rules is not very pleasant.
> > >
> > > Nicolas
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

MENFORCER-19 (enforce dependencyManagement)

[nicolas de loof]

Hi folks,

I'd like to work on MENFORCER-19,
org.apache.maven.plugin.dependency.AnalyzeDepMgt has all the necessary code
to create an EnforcerRule "EnforceDependencyManagement", but I wonder how we
should manage such code duplication. Copy/paste some hundred lines from
dependency plugin into enforcer-rules is not very pleasant.

Nicolas

Re: '+1' vs 'I agree'

[nicolas de loof]

2011/1/26 John Casey 

>
> Apologies if my addition to the veto thread was what touched this off. :-)
> It was a combination of using a phone for email for the first time (yes, I
> know, I must be some kind of Luddite),


I also sent my first mail from my first web-enabled mobile phone yesterday -
shall we create a group page on linkedIn ? :P

Nicolas

Re: Invite Evgeny Mandrikov to join Maven committers

[nicolas de loof]

+1
Le 26 janv. 2011 09:40, "Arnaud Héritier" 
a écrit :
>
> +1
>
> Arnaud
>
> On Wed, Jan 26, 2011 at 9:23 AM, Lukas Theussl 
wrote:
>
> >
> > +1
> >
> > -Lukas
> >
> >
> >
> > Olivier Lamy wrote:
> >
> >> Hello,
> >> I propose Evgeny Mandrikov as a new committer.
> >> He as done a lot of patches for Maven SCM, he is a Mojo and Sonar
> >> contributor @codehaus.
> >>
> >> Vote is open for 72H.
> >>
> >> Here my +1.
> >>
> >> Thanks,
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy
> >> http://www.linkedin.com/in/olamy
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >

Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml

[nicolas de loof]

Can I suggest that such debate moves to the PMC list ?

Not sure discussion about licensing and in/out hosting of core components
should occur here

2011/1/25 Jason van Zyl 

>
> On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote:
>
> > On 25 January 2011 15:47, Jason van Zyl  wrote:
> >
> >> On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote:
> >>
> >>> The problem here is that fundamental maven functionality got moved over
> >> to external jars. And now those jars got changed from ALv2 to EPL. Don't
> get
> >> me wrong, EPL is not a bad thing, but we cannot contribute to this
> library
> >> anymore without going all the (very stony) route of contributing patches
> to
> >> the Eclipse foundation. If they refuse the patches then maven is doomed
> to
> >> fail... As someone already mentioned: In the worst case maven3 will get
> >> nothing more than a plugin processor for aether. From a project
> perspective
> >> this is a no-go, so I strongly support the veto.
> >>>
> >>
> >> Yet, on the other hand the Eclipse Foundation consumes many ASL licensed
> >> artifacts from the ASF. You don't see their projects spouting this
> nonsense.
> >> That a project at the Eclipse Foundation is doomed because it has to
> consume
> >> dependencies from Apache? Contributing at Eclipse is no more thorny then
> >> trying to contribute at the ASF.
> >>
> >> If an Apache project can only consume dependencies from within Apache
> and
> >> nothing else is acceptable then that project is going to fail anyway.
> >>
> >>
> > See: www.apache.org/legal/resolved.html
> >
> > There are a number of issues with how the various dependencies can get
> > consumed. The PMC has yet to issue a ploicy on what kinds of dependencies
> > are permitted for maven-core. When the PMC has decided the policy that
> will
> > be communicated to the committers of Maven.
> >
> > EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed
> > projects to consume ASLv2 code... on the other hand it is not so
> acceptible
> > for ASLv2 licensed projects to consume EPL licensed projects.
>
> That is completely not true. Read the actual document you linked to. An
> Apache project can consume EPL binaries.
>
> > There are
> > ways for an Apache project to consume and distribute EPL licensed code,
>
> Yes, it's documented in the link you provided.
>
> > however given that the PMC is currently working on the policy for Maven's
> > core dependencies, Ralph has decided to temporarily veto any change of a
> > dependency in maven-core to a non-Category A license.
> >
> > My understanding is that once the policy has been approved the veto will
> > either be removed, or the policy will make clear what is to be done.
> >
> > I can appreciate that for somebody who has resigned from the PMC and the
> > Apache foundation it may appear that the veto has come out of thin air.
> >
> > -Stephen
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> To do two things at once is to do neither.
>
>  -—Publilius Syrus, Roman slave, first century B.C.
>
>
>
>

Re: Regarding maven 3 integration with Hudson

[nicolas de loof]

take a look at Olivier blog about maven3 support on hudson
http://olamy.blogspot.com/

2010/12/15 amit pugalia 

> Hi,
>
> I'm facing issues when using Maven 3 with latest build of Hudson.
> The maven plugin doesn't seem to be compatible with Maven 3.
> It throws errors as,
>
>
> C:\hudson1\home\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.389.jar
> 52039
>
> Exception in thread "main" java.lang.NoSuchMethodError:
>
> org.codehaus.classworlds.Launcher.getWorld()Lorg/codehaus/classworlds/ClassWorld;
> at hudson.maven.agent.Main.main(Main.java:115) at
> hudson.maven.agent.Main.main(Main.java:62)
> ERROR: Failed to launch Maven. Exit code = 1
>
> I tried building a Free Style Project on the same but still facing issues.
> Do we have a solution, please help.
>
> Thanks,
> Amit Pugalia.
>

Re: Use of standards in the Maven core

[nicolas de loof]

I may be wrong regarding maven3-core, but AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing. Such a migration to JAXB (or other),
without consideration to the technical beneficts, would require a
compatibility layer. Can we provide some Xpp3-compliant API on top of JAXB ?

2010/11/12 Lennart Jorelid 

> Hello all,
>
> I must confess I appreciate standards in larger projects.
> Unless there are solid technology-based reasons not to use
> existing standards, I say we should strive to use standards
> as often as we can. If we do, we can acquire better
> feedback and more informed suggestions for improvement.
>
> We use quite a few nonstandard patterns and components within
> the Maven3 core - so let me suggest some refactoring ideas,
> which I believe will simplify and augment Maven's internals
> in upcoming releases.
>
> Model improvements:
>a) Xpp3 --> JAXB.
>   We use Xpp3 to move entities to/from XML.
>   The JSE standard is JAXB which could generate both
>   XML and XSD documents for all our projects.
>   We need only add JAXB annotations to our classes
>   and properties for it to happen. If we feel that
>   the model becomes bogged down in annotations, we
>   can simply create our own compound annotations
>   to reduce clutter.
>
>b) .mdo --> .java.
>   We use Modello to generate large portions of the
>   mainly static central parts of Maven. I believe we
>   would do better without generated code within the
>   Maven distribution, for 3 reasons:
>
>   1) Java is simple to read, understand and refactor.
>   XML source files - such as Modello's - are neither.
>   For that reason alone, we should contemplate removing
>   a code generation tool. Moreover, to properly handle
>   changes in the Maven model, one needs to understand
>   Modello. This increases the time required to get started
>   in committing patches and ideas to the Maven core/model.
>
>   2) The Maven model is largely stable, so code generation
>   shouldn't really be needed. It's easier just to remove
>   the code generation and commit well-written Java code.
>
>   3) Generated code tends to contain quite a number of
>   no-op setters/getters (i.e. bloat), take poor use of
>   OO constructs such as inheritance (we generate no
>   abstract classes with common/template methods for use
>   in several subclasses) and provide somewhat poor javadoc.
>
>   This discussion can be exemplified with the setter below,
>   which provides no parameter validation
>   (i.e. "no-op setter antipattern"), not quite a sensible
>   JavaDoc and no explanation of its parameter's significance.
>   While I believe that most of us will eventually understand
>   what goes on here, I suggest that overall code quality is
>   reduced by the generation tool. Let's move to a Java model.
>
>/**
> * Set specifies that this profile will be activated when
> * matching operating system
> * attributes are detected.
> *
> * @param os
> */
>public void setOs( ActivationOS os )
>{
>this.os = os;
>} //-- void setOs( ActivationOS )
>
> --
> +==+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: l...@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==+
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [ANN] Apache Maven 3.0 Released

[nicolas de loof]

aren't "software" and "late" some sort of synonyms ?

2010/10/8 Jason van Zyl 

> A week late, but better then most of my predictions :-)
>
> On Oct 8, 2010, at 9:59 AM, Jochen Wiedmann wrote:
>
> > Thanks god, this didn't become a new Perl 6 ... :-)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> A language that doesn’t affect the way you think about programming is not
> worth knowing.
>
>  -— Alan Perlis
>
>
>
>

Re: [VOTE] Release Apache Maven 3.0

[nicolas de loof]

+1,

works fine for me
Nicolas

2010/10/4 Greg Akins 

> +1
>
> Ran against all my projects successfully
>
> On Mon, Oct 4, 2010 at 8:16 AM, Benjamin Bentmann
>  wrote:
> > Hi,
> >
> > feedback on the RCs seems to be decreasing and I am currently not aware
> of
> > any major regression so let's try and cross the finishing line of this
> > marathon.
> >
> > We solved 31 issues since 3.0-beta-3:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=13142
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-004/
> >
> > Staged source and binary distros:
> >
> https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me
> >
> >
> > Benjamin
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
>
> --
> Greg Akins
>
> http://insomnia-consulting.org
> http://www.pghcodingdojo.org
> http://pittjug.dev.java.net
> http://twitter.com/akinsgre
> http://www.linkedin.com/in/akinsgre
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Site Plugin 3.0-beta-2 for maven 3

[nicolas de loof]

Link to migration doc on index page is wrong "/#migrate.html, should be
/migrate.html)

2010/9/5 Tony Chemit 

> +1
>
> Le Sat, 4 Sep 2010 23:06:51 +0200,
> Olivier Lamy  a écrit :
>
> > Hi,
> > We solved 2 issues :
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&version=16693
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-031
> >
> > Staging site (sync pending):
> > http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-2
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> >  [ ] +1
> >  [ ] +0
> >  [ ] -1
> >
> >  +1 from me.
> >
>
>
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> email: che...@codelutin.com
> http://www.codelutin.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Compiler Plugin 2.3.2

[nicolas de loof]

+1
Nicolas

2010/9/5 Tony Chemit 

> +1
>
> Le Sat, 04 Sep 2010 16:21:50 +0200,
> Benjamin Bentmann  a écrit :
>
> > Hi,
> >
> > We solved 1 issue:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130&version=16731
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11130&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-030/
> >
> > Staging site (sync pending):
> > http://maven.apache.org/plugins/maven-compiler-plugin-2.3.2/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me.
> >
> >
> > Benjamin
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> email: che...@codelutin.com
> http://www.codelutin.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)

[nicolas de loof]

+1 (non binding)

works fine with gwt-maven plugin

2010/9/2 Hervé BOUTEMY 

> +1
>
> Hervé
>
> Le lundi 30 août 2010, Benjamin Bentmann a écrit :
> > Hi,
> >
> > what's a better start for a week than a new fresh release :-) ? So here
> > we go!
> >
> > Apart from another few regression fixes, this release includes Guice and
> > Aether [0] and shall help to get some more community testing on these
> > new components.
> >
> > Overall, we solved 19 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16
> > 681
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&st
> > atus=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-157/
> >
> > Staged source and binary distros:
> >
> https://repository.apache.org/content/repositories/maven-157/org/apache/mav
> > en/apache-maven/3.0-beta-3/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me
> >
> >
> > Benjamin
> >
> >
> > [0] http://github.com/sonatype/sonatype-aether
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Fwd: maven3 embedder

[nicolas de loof]

just use the HPPT (not "S") url
http://svn.sonatype.org/spice/trunk/maven-performance-tests/src/test/java/org/apache/maven/performance/tests/p001/P001EmbedderTest.java

2010/8/10 Steffen Stundzig 

> hi,
>
> thanks igor. For the second I need a login. Do you have a guest account
> or something else?
>
> regards
>
> Am 10.08.10 18:46, schrieb Igor Fedorenko:
> > You may want to check how we do this in m2eclipse [1] or during maven
> > performance regression tests [2].
> >
> >
> > [1]
> >
> http://github.com/sonatype/m2eclipse-core/blob/master/org.maven.ide.eclipse/src/org/maven/ide/eclipse/internal/embedder/MavenImpl.java
> >
> > [2]
> >
> https://svn.sonatype.org/spice/trunk/maven-performance-tests/src/test/java/org/apache/maven/performance/tests/p001/P001EmbedderTest.java
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Aether questions answered for JAX

[nicolas de loof]

Do you plan to also use Aether for Provisio ?
I read at http://www.scribd.com/doc/29909925/Managing-Run-Times-With-Proviso
that
it uses P2 for provisioning, but this may be outdated

Cheers,
Nicolas

2010/8/9 Jason van Zyl 

> Some more public information for those interested in Aether:
>
> http://www.sonatype.com/people/2010/08/aether-questions-answered-for-jax/
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
>  -- Thoreau
>
>
>
>

Re: [VOTE] Release Maven Site Plugin 3.0-beta-1 for maven 3

[nicolas de loof]

+1 (non binding)
Nicolas

2010/8/7 Olivier Lamy 

> Hi,
> In order to have a good companion to the coming Apache Maven 3.0-beta-2
> release.
> I'd like to release Maven Site Plugin 3.0-beta-1 for maven 3.
> We solved 10 issues :
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&version=15554
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-070/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Notes :
> * this release has been build using the staged Apache Maven 3.0-beta-2
> (so you must use the staged repository [1] )
> * some informations can be found [2], specially how to configure your
> pom in order to be able to continue building site with both maven 2.x
> and maven 3.
>
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
> --
> Olivier
>
> [1] https://repository.apache.org/content/repositories/maven-069/
> [2] https://cwiki.apache.org/confluence/x/sokr
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof]

Could it be supported by a JSR ?

Not a lightweight process, even considering JSR-330 was out after 6 month,
but the most agnostic way to group community efforts. Aether could then be
proposed as RI

2010/8/4 John Casey 

> On 8/4/10 10:39 AM, nicolas de loof wrote:
>
>> Ivy Guys could be interested in such a "neutral" repository API, as they
>> also support both m2 and proprietary repo format.
>>
>
> Is Ivy even active still?
>
> I see Eclipse p2 as a better target for interoperability, but that's beside
> the point.
>
> We're talking about mediating the way artifacts are shared in software
> builds and deployments. Gradle, Ant, Ivy, Maven, Eclipse are all projects
> interested in this space. Users of this sharing mechanism may come to it via
> a wide variety of applications.
>
> Surely we can agree that establishing a standard and having everyone on the
> same page contributing to a fully interoperable design would be a good
> thing? We have two fairly mature designs out there, so this wouldn't be
> whole-cloth design by committee. It's more of a standards board, or steering
> committee, or whatever.
>
> Personally, I'm sick of coding against implementations without some stable
> API specification I can depend on. It breeds bugs.
>
>
>
>> 2010/8/4 John Casey
>>
>>  On 8/3/10 2:21 PM, Jason van Zyl wrote:
>>>
>>>  Hi,
>>>>
>>>> We have two major pieces that we, Sonatype, would like to merge into
>>>> Maven
>>>> 3.x trunk.
>>>>
>>>> The first are the Guice changes that we've been talking about for a
>>>> while,
>>>> and the second is the introduction of Aether which is our second attempt
>>>> at
>>>> a stand-alone repository API. The PMC is aware of Aether as Brian
>>>> reported
>>>> it in our quarterly report to the Apache Board, but other developers who
>>>> are
>>>> not on the PMC and the community in general might not know much about
>>>> it.
>>>>
>>>> I just posted an entry giving a very high level description:
>>>>
>>>> http://www.sonatype.com/people/2010/08/introducing-aether/
>>>>
>>>> There is a resources section at the bottom of the post for those
>>>> interested in the sources, issue tracking, wiki and mailing lists. As
>>>> part
>>>> of some of the research we are about to embark on with Daniel Le Berre,
>>>> Aether will likely look more like p2 as time passes and as a final
>>>> resting
>>>> place the Eclipse Foundation is more likely then Apache. I know people
>>>> will
>>>> ask so I'm answering that now. Sonatype is just about to fully move
>>>> Tycho
>>>> over the Eclipse Foundation and we want to see how that goes. If that
>>>> works,
>>>> then M2Eclipse is next, and then Aether will follow.
>>>>
>>>> At any rate we would like to merge these changes in and make plans to
>>>> release 3.0-beta-2.
>>>>
>>>> So please let us know if you have any objections.
>>>>
>>>>
>>>
>>> There's too much in this thread that I this is a tad distracting from the
>>> important points, so I'm replying to the top post.
>>>
>>> I _really_ appreciate all the work done in getting M3 into a usable form,
>>> and in general I like the way Aether looks (I haven't had time to look
>>> into
>>> the guice shim yet). I realize there are newer thoughts on repository
>>> design
>>> since Maven took its swing at things, and we need to find a way to
>>> transition forward..."transition" because we have a large legacy of
>>> artifacts already under the Maven repository format. HOWEVER, there are a
>>> couple things here I'm pretty deeply concerned about.
>>>
>>>
>>> 1. The repository format is a Maven concept. I'd argue that it's one of
>>> Maven's two great contributions to the world of software (the other being
>>> a
>>> decent build tool). As such, the Maven community should have some role in
>>> guiding the future of that format.
>>>
>>> If Maven relinquishes all ownership of the API and implementation for the
>>> piece that resolves artifacts, then we have no say in the future design
>>> of
>>> the repository Maven uses as its lifeblood. Many people who aren't
>>> Sonatype
>>> people have spent 

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof]

Ivy Guys could be interested in such a "neutral" repository API, as they
also support both m2 and proprietary repo format.

2010/8/4 John Casey 

> On 8/3/10 2:21 PM, Jason van Zyl wrote:
>
>> Hi,
>>
>> We have two major pieces that we, Sonatype, would like to merge into Maven
>> 3.x trunk.
>>
>> The first are the Guice changes that we've been talking about for a while,
>> and the second is the introduction of Aether which is our second attempt at
>> a stand-alone repository API. The PMC is aware of Aether as Brian reported
>> it in our quarterly report to the Apache Board, but other developers who are
>> not on the PMC and the community in general might not know much about it.
>>
>> I just posted an entry giving a very high level description:
>>
>> http://www.sonatype.com/people/2010/08/introducing-aether/
>>
>> There is a resources section at the bottom of the post for those
>> interested in the sources, issue tracking, wiki and mailing lists. As part
>> of some of the research we are about to embark on with Daniel Le Berre,
>> Aether will likely look more like p2 as time passes and as a final resting
>> place the Eclipse Foundation is more likely then Apache. I know people will
>> ask so I'm answering that now. Sonatype is just about to fully move Tycho
>> over the Eclipse Foundation and we want to see how that goes. If that works,
>> then M2Eclipse is next, and then Aether will follow.
>>
>> At any rate we would like to merge these changes in and make plans to
>> release 3.0-beta-2.
>>
>> So please let us know if you have any objections.
>>
>
>
> There's too much in this thread that I this is a tad distracting from the
> important points, so I'm replying to the top post.
>
> I _really_ appreciate all the work done in getting M3 into a usable form,
> and in general I like the way Aether looks (I haven't had time to look into
> the guice shim yet). I realize there are newer thoughts on repository design
> since Maven took its swing at things, and we need to find a way to
> transition forward..."transition" because we have a large legacy of
> artifacts already under the Maven repository format. HOWEVER, there are a
> couple things here I'm pretty deeply concerned about.
>
>
> 1. The repository format is a Maven concept. I'd argue that it's one of
> Maven's two great contributions to the world of software (the other being a
> decent build tool). As such, the Maven community should have some role in
> guiding the future of that format.
>
> If Maven relinquishes all ownership of the API and implementation for the
> piece that resolves artifacts, then we have no say in the future design of
> the repository Maven uses as its lifeblood. Many people who aren't Sonatype
> people have spent time working on that de facto specification, and they've
> shown the merit to earn a voice in guiding this API...at least, if it's
> going to be billed as a Maven-compatible Repository API.
>
>
> 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype
> in the future to improve Aether. What effect is this likely to have on the
> aether-api module? My concern here is that we're talking about releasing
> Maven 3.0-beta-2 with a completely rewritten API / implementation for one of
> the most pivotal parts of Maven. It's not that I don't trust Benjamin and
> Kristian to produce high-quality code.
>
> What I'm actually worried about having Aether API drift AFTER we adopt it
> in Maven. This will hamper anyone wishing to integrate with the Maven 3
> core, whether that's Maven plugin development or Maven embedding.
>
>
> What I'd actually prefer to see is the Aether API published in some neutral
> location where we have an iron-clad guarantee that we won't be locked out of
> its design. Then, put the implementations wherever you think is best. IMO
> the key moving forward is to establish a standard API for resolving
> artifacts. IMO, this is our great failure with Plexus, that we depended
> directly on a container implementation, not on a container API.
>
> Having a stable set of specifications define their interaction with Maven
> would make plugin development and embedding MUCH better. In fact, I think
> establishing this practice might be the single best contribution we can make
> to Maven in the near term.
>
> Thanks,
>
> -john
>
>
>
>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>>
>>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>>
>>
>>
>>
>>
> -
> To unsubscribe, 

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof]

>
>
> > I have always had concerns about plexus being pretty much only adopted by
> > Maven as far as I can see, and essentially being a maven core component,
> > except it isn't
>
> +1
>
> Guice allready as its own large community of users and maintainers.
> It's a general 'purpose' API.
>
> Aether is new, Maven related and need to create its own community.
> Why not moving it to ASF as a Maven subproject ?
>
>
+1 for Guice

As discussed here [1], Guice would help a lot integrating nicelly Maven3
into Hudson. It also has a larger user base and doc than Plexus, and has
been proposed for a while on this ML as a replacement. The Git branch is
also avialable for testing for a while

+0 for Aether.
It looks technicaly nice according to the code sample [2]. I just share the
concern about a major component beeing outside Maven SCM.

[1]
http://maven.40175.n5.nabble.com/Maven3-with-guice-was-Re-Maven-3-tests-td219507.html#a219507

[2]
http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java

Nicolas

issue using properties in dependencies

[nicolas de loof]

Hi,

I just was warned about a strange behaviour in dependency resolution.

Having 3 projets A, B, C

C creates an artifact with a classifier, beeing configured as a user setting
"env" property (using jar-plugin classifier parameter). Running mvn install
on C creates C-1-.jar

B has a dependency on C, with classifier ${env}. Running mvn install on B
works fine, and resolve C-1-.jar

A has a dependency on B. Running mvn install on A fails with :
Missing:
--
1) test:c:jar:${env}:1


Is this a known bug ? (I can't find one in Jira)
or maybe just a bad practice :)


Nicolas

Re: [MDEP-269] please review

[nicolas de loof]

True,

I'll commit the REST-based code in maven-dependency-plugin, as it is easier
to configure for any other repository manager, and try to prepare a contrib
to nexus-maven-plugin

Cheers,
Nicolas



2010/6/21 Brian Fox 

> If you're using the nexus api, then this belongs in the
> nexus-maven-plugin, not the maven-dependency-plugin.
>
> On Mon, Jun 21, 2010 at 8:39 AM, nicolas de loof
>  wrote:
> > I tried to write an alternate implementation of MDEP-269 using nexus
> indexer
> > API, based on samples found on sonatype blog.
> >
> > I got some few issues :
> >
> > I had to add sonatype forge as repository to resolve dependencies, not
> > really pleasant as the maven plugin is expected to build using central
> repo.
> >
> > I had to stub the plexus Logger Component with SilentLoger - maven 2.2.1
> > doesn't provides such component
> >
> > I get an error when running the indexUpdater
> > : java.lang.ClassNotFoundException:
> > org.eclipse.jetty.client.security.Authorization - I can't find a
> dependency
> > to this eclipse plugin in nexus-indexer POM.xml
> >
> > Maybe you can help me on last issue, but the first one is a blocker AFAIK
> to
> > be used in Maven Dependency Plugin.
> >
> > Nicolas
> >
> > 2010/6/18 Tamás Cservenák 
> >
> >> Well, we had an issue:
> >>
> >> https://issues.sonatype.org/browse/NEXUS-644
> >>
> >> but it was fixed more then a year ago... maybe he suffered from that
> one?
> >>
> >> But index downloaded from central was never suffering from this issue
> (it
> >> is
> >> not a Nexus instance, and Central would not be a group anyway). Use the
> >> latest release of Nexus Indexer and please test it. If you find hashes
> >> usable, please close the issue.
> >>
> >> Note: In issue above MD5 hashes are mentioned, but MD5 is not supported
> >> anymore, not on index. Only SHA1 hashes are.
> >>
> >> Thanks,
> >> ~t~
> >>
> >> On Fri, Jun 18, 2010 at 10:35 PM, nicolas de loof
> >> wrote:
> >>
> >> > I discussed with the author of alf-maven-osecm (that suggested me this
> >> > feature) and he reported me he first tried to use the repo index but
> >> didn't
> >> > find the hash in it. I've not tried by myslef. If hash is included,
> >> please
> >> > close my Jira issue on Nexus and I'll double check this.
> >> >
> >> > 2010/6/18 Tamás Cservenák 
> >> >
> >> > > I don't get it, what do you mean by "repository index generated by
> >> Nexus
> >> > > ...
> >> > > doesn't include the artifact hash"?
> >> > >
> >> > > What makes you think hash is not on the index?
> >> > >
> >> > > Thanks,
> >> > > ~t~
> >> > >
> >> > > On Fri, Jun 18, 2010 at 11:52 AM, nicolas de loof
> >> > > wrote:
> >> > >
> >> > > > Hi folks,
> >> > > >
> >> > > > I'm working on MDEP-269 <http://jira.codehaus.org/browse/MDEP-269>
> -
> >> > > > convert
> >> > > > a legacy lib/*.jar to maven 
> >> > > > I've attached a patch to Jira as I'd like your opinion on the way
> to
> >> > > > support
> >> > > > this use case.
> >> > > >
> >> > > > My patch uses Nexus REST API to query the repository manager for
> >> > > artifacts
> >> > > > based on local files SHA1 hash.
> >> > > > The query URL is configurable, and the Xpath expression to extract
> >> data
> >> > > > should also, so that a non-nexus repository manager that provides
> >> > > > comparable
> >> > > > feature may be user.
> >> > > >
> >> > > > Maybe there is more performant/portable way to do this,
> >> > > > for example using repository index generated by Nexus (not sure if
> >> > other
> >> > > > repository manager do the same) but this one doesn't include the
> >> > > artifacts
> >> > > > hash yet (NEXUS-3596 <
> http://issues.sonatype.org/browse/NEXUS-3596>)
> >> > > >
> >> > > > WDYT ?
> >> > > >
> >> > > > Nicolas
> >> > > >
> >> > >
> >> >
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [MDEP-269] please review

[nicolas de loof]

>
> I get an error when running the indexUpdater
> : java.lang.ClassNotFoundException:
> org.eclipse.jetty.client.security.Authorization - I can't find a dependency
> to this eclipse plugin in nexus-indexer POM.xml
>
>
> This one is solved, I wasn't looking at the correct POM :-/
sory

Nicolas

Re: [MDEP-269] please review

[nicolas de loof]

I tried to write an alternate implementation of MDEP-269 using nexus indexer
API, based on samples found on sonatype blog.

I got some few issues :

I had to add sonatype forge as repository to resolve dependencies, not
really pleasant as the maven plugin is expected to build using central repo.

I had to stub the plexus Logger Component with SilentLoger - maven 2.2.1
doesn't provides such component

I get an error when running the indexUpdater
: java.lang.ClassNotFoundException:
org.eclipse.jetty.client.security.Authorization - I can't find a dependency
to this eclipse plugin in nexus-indexer POM.xml

Maybe you can help me on last issue, but the first one is a blocker AFAIK to
be used in Maven Dependency Plugin.

Nicolas

2010/6/18 Tamás Cservenák 

> Well, we had an issue:
>
> https://issues.sonatype.org/browse/NEXUS-644
>
> but it was fixed more then a year ago... maybe he suffered from that one?
>
> But index downloaded from central was never suffering from this issue (it
> is
> not a Nexus instance, and Central would not be a group anyway). Use the
> latest release of Nexus Indexer and please test it. If you find hashes
> usable, please close the issue.
>
> Note: In issue above MD5 hashes are mentioned, but MD5 is not supported
> anymore, not on index. Only SHA1 hashes are.
>
> Thanks,
> ~t~
>
> On Fri, Jun 18, 2010 at 10:35 PM, nicolas de loof
> wrote:
>
> > I discussed with the author of alf-maven-osecm (that suggested me this
> > feature) and he reported me he first tried to use the repo index but
> didn't
> > find the hash in it. I've not tried by myslef. If hash is included,
> please
> > close my Jira issue on Nexus and I'll double check this.
> >
> > 2010/6/18 Tamás Cservenák 
> >
> > > I don't get it, what do you mean by "repository index generated by
> Nexus
> > > ...
> > > doesn't include the artifact hash"?
> > >
> > > What makes you think hash is not on the index?
> > >
> > > Thanks,
> > > ~t~
> > >
> > > On Fri, Jun 18, 2010 at 11:52 AM, nicolas de loof
> > > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I'm working on MDEP-269 <http://jira.codehaus.org/browse/MDEP-269> -
> > > > convert
> > > > a legacy lib/*.jar to maven 
> > > > I've attached a patch to Jira as I'd like your opinion on the way to
> > > > support
> > > > this use case.
> > > >
> > > > My patch uses Nexus REST API to query the repository manager for
> > > artifacts
> > > > based on local files SHA1 hash.
> > > > The query URL is configurable, and the Xpath expression to extract
> data
> > > > should also, so that a non-nexus repository manager that provides
> > > > comparable
> > > > feature may be user.
> > > >
> > > > Maybe there is more performant/portable way to do this,
> > > > for example using repository index generated by Nexus (not sure if
> > other
> > > > repository manager do the same) but this one doesn't include the
> > > artifacts
> > > > hash yet (NEXUS-3596 <http://issues.sonatype.org/browse/NEXUS-3596>)
> > > >
> > > > WDYT ?
> > > >
> > > > Nicolas
> > > >
> > >
> >
>

Re: [MDEP-269] please review

[nicolas de loof]

I discussed with the author of alf-maven-osecm (that suggested me this
feature) and he reported me he first tried to use the repo index but didn't
find the hash in it. I've not tried by myslef. If hash is included, please
close my Jira issue on Nexus and I'll double check this.

2010/6/18 Tamás Cservenák 

> I don't get it, what do you mean by "repository index generated by Nexus
> ...
> doesn't include the artifact hash"?
>
> What makes you think hash is not on the index?
>
> Thanks,
> ~t~
>
> On Fri, Jun 18, 2010 at 11:52 AM, nicolas de loof
> wrote:
>
> > Hi folks,
> >
> > I'm working on MDEP-269 <http://jira.codehaus.org/browse/MDEP-269> -
> > convert
> > a legacy lib/*.jar to maven 
> > I've attached a patch to Jira as I'd like your opinion on the way to
> > support
> > this use case.
> >
> > My patch uses Nexus REST API to query the repository manager for
> artifacts
> > based on local files SHA1 hash.
> > The query URL is configurable, and the Xpath expression to extract data
> > should also, so that a non-nexus repository manager that provides
> > comparable
> > feature may be user.
> >
> > Maybe there is more performant/portable way to do this,
> > for example using repository index generated by Nexus (not sure if other
> > repository manager do the same) but this one doesn't include the
> artifacts
> > hash yet (NEXUS-3596 <http://issues.sonatype.org/browse/NEXUS-3596>)
> >
> > WDYT ?
> >
> > Nicolas
> >
>

[MDEP-269] please review

[nicolas de loof]

Hi folks,

I'm working on MDEP-269  - convert
a legacy lib/*.jar to maven 
I've attached a patch to Jira as I'd like your opinion on the way to support
this use case.

My patch uses Nexus REST API to query the repository manager for artifacts
based on local files SHA1 hash.
The query URL is configurable, and the Xpath expression to extract data
should also, so that a non-nexus repository manager that provides comparable
feature may be user.

Maybe there is more performant/portable way to do this,
for example using repository index generated by Nexus (not sure if other
repository manager do the same) but this one doesn't include the artifacts
hash yet (NEXUS-3596 )

WDYT ?

Nicolas

Re: Maven3 with guice was Re: Maven 3 tests

[nicolas de loof]

I built and used it also on few projects without any issue, including some
custom plugins

I'm +1 to switch to Guice,

just a note : as Spice uses a modified Guice release, with patch proposed to
Guice SVN, should we wait for a new Guice release with those changes
included ?

2010/6/9 Olivier Lamy 

> Hi,
> I have tested (
> http://code.google.com/p/maven-scm-provider-svnjava/wiki/UsingWithReleasePlugin
> )
> and it works nice !
> I have only changed a company plugin to made it works : so it was a
> bad maven usage !.
> regarding the cnfde there is the issue :
> https://issues.sonatype.org/browse/SPICE-26 (do you need a patch ?).
>
> For all : So now what is the next step ? Integrating this in the maven 3
> trunk ?
>
>
> 2010/6/7 Stuart McCulloch :
> > On 7 June 2010 07:25, Olivier Lamy  wrote:
> >
> >> Hi,
> >> I have tested some builds.
> >> Some notes.
> >> I have this issues currently :
> >>
> >> java.lang.UnsupportedOperationException
> >>at java.util.AbstractMap.put(AbstractMap.java:186)
> >>at
> >>
> org.apache.maven.scm.manager.AbstractScmManager.setScmProvider(AbstractScmManager.java:93)
> >>
> >> Now the Map is not any more writable ?
> >>
> >
> > correct - the new container is much more strict about
> > components monkeying around with internals, such as
> > directly modifying injected dynamic collections
> >
> > if you look at the old Plexus collections code it does
> > log a warning if you add components directly into the
> > injected maps / lists, because it makes the internal
> > book-keeping and synchronization very complicated
> >
> > there is a simple workaround which is to push the
> > contents of the injected map into your own mutable
> > map, for example by using a setter method like so:
> >
> >  private Map fooMap;
> >
> >  private void setFooMap( Map fooMap )
> >  {
> >this.fooMap = new HashMap( fooMap );
> >  }
> >
> > the new container would inject the setter method
> > instead of the field (ie. the setter hides the field)
> > and your code would still work with Plexus
> >
> > I'm not sure something like [1] will works now. (Not tested as I have
> >> to cut a release :-) )
> >>
> >> AN other issue using the old plugin
> >> org.codehaus.plexus:plexus-maven-plugin give me :
> >> -:
> >> NoClassDefFoundError:
> >> org.codehaus.plexus.personality.plexus.lifecycle.phase.Suspendable
> >>
> >> so upgrading to org.codehaus.plexus:plexus-component-metadata:1.5.4
> >> fix the issue.
> >>
> >
> > the new container may be missing some of the more
> > obscure parts of Plexus, because we took a minimal
> > approach to keep it lean - any missing pieces can be
> > reported at https://issues.sonatype.org/browse/SPICE
> >
> > I will tests it with some other build (@work).
> >>
> >
> > thanks
> >
> >
> >> [1]
> >>
> http://code.google.com/p/maven-scm-provider-svnjava/wiki/UsingWithReleasePlugin
> >>
> >>
> >> 2010/6/7 Jemos Infra :
> >> > Hi all,
> >> >
> >> > I'm working on the Maven 3 branch created today by Olivier Lamy
> >> >
> >> > [email quote]
> >> > stuff is here :
> >> > http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/
> >> >
> >> > Thanks !
> >> > [/email quote]
> >> >
> >> > This branch is supposed to have the Maven 3 version which uses Guice
> >> > instead of Plexus (actually still uses Plexus to startup but the
> wiring
> >> > is done by Guice).
> >> >
> >> > I noticed that from this branch the tests are still in Junit 3. Would
> it
> >> > be ok to move those to TestNG (preferred) or Junit 4? I could do some
> >> > work on these if you like.
> >> >
> >> > M.
> >> >
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Olivier
> >> http://twitter.com/olamy
> >> http://fr.linkedin.com/in/olamy
> >> http://www.viadeo.com/fr/profile/olivier.lamy7
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > --
> > Cheers, Stuart
> >
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: svn commit: r950989 - /maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java

[nicolas de loof]

+1 to remove this "feature".
A module is expected to build either with it's parent POM in parent
directory or by donwloading it from repo, so relying on such *
search-in-parent-folder* feature is a bad practice.

Nicolas

2010/6/3 Olivier Lamy 

> Hi,
> We are two who don't like this hack :-)
> So what's about don't support this ?
> Others ?
>
> 2010/6/3  :
> > Author: dkulp
> > Date: Thu Jun  3 13:28:57 2010
> > New Revision: 950989
> >
> > URL: http://svn.apache.org/viewvc?rev=950989&view=rev
> > Log:
> > Fix the checkstyle it tests.
> > This is really a complete hack to support MCHECKSTYLE-131 which, IMO,
> should not be supported.   Just because it worked at one point despite not
> falling into the documented and supported use cases does not, to me, mean we
> should really support it.
> >
> > Modified:
> >
>  
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
> >
> > Modified:
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
> > URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java?rev=950989&r1=950988&r2=950989&view=diff
> >
> ==
> > ---
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
> (original)
> > +++
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
> Thu Jun  3 13:28:57 2010
> > @@ -31,6 +31,7 @@ import java.util.List;
> >  import java.util.Properties;
> >
> >  import org.apache.maven.artifact.DependencyResolutionRequiredException;
> > +import org.apache.maven.project.MavenProject;
> >  import org.codehaus.plexus.logging.AbstractLogEnabled;
> >  import org.codehaus.plexus.resource.ResourceManager;
> >  import
> org.codehaus.plexus.resource.loader.FileResourceCreationException;
> > @@ -454,12 +455,16 @@ public class DefaultCheckstyleExecutor
> > {
> > getLogger().debug( "request.getConfigLocation() " +
> request.getConfigLocation() );
> > }
> > -File parent =
> request.getProject().getFile().getParentFile();
> > -if (parent != null)
> > -{
> > -// MCHECKSTYLE-131 ( olamy ) I don't like this hack.
> what's happened if this is defined in parent/parent pom
> > -// it will breaks
> > -locator.addSearchPath( FileResourceLoader.ID,
> request.getProject().getFile().getParentFile().getAbsolutePath() );
> > +
> > +MavenProject parent = request.getProject();
> > +while ( parent != null && parent.getFile() != null )
> > +{
> > +// MCHECKSTYLE-131 ( olamy ) I don't like this hack.
> > +// (dkulp) Me either.   It really pollutes the location
> stuff
> > +// by allowing searches of stuff outside the current
> module.
> > +File dir = parent.getFile().getParentFile();
> > +locator.addSearchPath( FileResourceLoader.ID,
> dir.getAbsolutePath() );
> > +parent = parent.getParent();
> > }
> > locator.addSearchPath( "url", "" );
> >
> >
> >
> >
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Site Plugin version 2.1.1

[nicolas de loof]

+1

Le 3 juin 2010 10:52, Arnaud Héritier  a écrit :

> +1
>
> Arnaud Héritier
> eXo - Software Factory Manager
>
>
>
> On Jun 3, 2010, at 9:59 AM, Olivier Lamy wrote:
>
> > +1
> >
> > 2010/5/31 Dennis Lundberg :
> >> Hi,
> >>
> >> We solved 7-8 issues (I'm not sure if MSITE-440 is resolved or not):
> >>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&version=15923
> >>
> >> There are still a couple of issues left in JIRA:
> >>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11146&status=1
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-025/
> >>
> >> Staging site:
> >> http://maven.apache.org/plugins/maven-site-plugin-2.1.1/
> >>
> >> Guide to testing staged releases:
> >> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> --
> >> Dennis Lundberg
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Olivier
> > http://twitter.com/olamy
> > http://fr.linkedin.com/in/olamy
> > http://www.viadeo.com/fr/profile/olivier.lamy7
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.3

[nicolas de loof]

+1

2010/5/25 Lukas Theussl 

>
> +1 *2!
>
> -Lukas
>
>
> Dennis Lundberg wrote:
>
>> Hi,
>>
>> To allow Maven Site Plugin 2.1.1 to be released, I'd like to release
>> Doxia 1.1.3.
>>
>> We solved 10+1 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&version=15924
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624&version=16452
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10780&status=1
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11624&status=1
>>
>> Staging repos:
>> https://repository.apache.org/content/repositories/maven-010/
>>
>> Staging sites (need to sync):
>> http://maven.apache.org/doxia/doxia-1.1.3
>> http://maven.apache.org/doxia/doxia-sitetools-1.1.3
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> --
>> Dennis Lundberg
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Antrun plugin version 1.4

[nicolas de loof]

+1

Le 25 mai 2010 10:11, Arnaud Héritier  a écrit :

> +1
>
> On May 25, 2010, at 4:20 AM, Paul Gier wrote:
>
> > Hi,
> >
> > We solved 13 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125&version=14641
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11125&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-013/
> >
> > Staging site:
> > http://maven.apache.org/plugins/maven-antrun-plugin-1.4/
> >
> > SCM Tag:
> >
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-antrun-plugin-1.4/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

dependency plugin vs dependency report

[nicolas de loof]

Hi,

I just noticed the dependency report has (at page end) a list of
dependencies with the repo ID they where retreived from

I wonder if the maven-dependency-plugin could also display such (usefull
IMHO) info using a new "outputRepository" parameter

Cheers,
Nicolas

Re: Concurrency in m3 - a status report

[nicolas de loof]

What about adding such concurrency metadata aside plugin artifact in local
repository, either by extending metadata.xml or using a new
concurrency-metadata.xml file ?

In such case users/repo maintainers could easily "tag" plugin as (not)
beeing thread-safe

2010/4/26 Stephen Connolly 

> On 26 April 2010 12:05, Benjamin Bentmann 
> wrote:
>
> > Stephen Connolly wrote:
> >
> >  ... but each release of m3
> >> would have it's own compatibility info and we would have another state:
> >> unknown
> >>
> >> e.g.
> >>
> >> 
> >>   
> >> message
> >> message
> >> 
> >> message
> >> message
> >>  versions="...">message
> >>   
> >> 
> >>
> >> Any plugins not in the list would be "unknown" and the user gets a big
> fat
> >> warning
> >>
> >
> > Did you also consider the maintainability aspect of such a list? No user
> > wants to see "big fat warnings" that are irrelevant for their builds so I
> > envision users will either bug the plugin author or us directly to add
> > plugin X to this list and ask us to roll a new release of this list such
> > that they get rid of that warning.
> >
> > Plugins should be self-describing, that's why mojo annotations and the
> > plugin descriptor exists. I definitively don't want to see us maintaining
> > the metadata for 3rd party plugins.
> >
> > For this reason, I prefer the original suggestion to introduce a new mojo
> > annotation. Apparently, whatever mojo annotation we come up with, it's
> not
> > present in any existing plugin release. Now, for plugins missing the
> > threading anno, what is the safer assumption with respect to proper build
> > results: That mojo X is thread-safe (when this was never before a
> concern)
> > or that it isn't?
> >
> > IMHO, there's only way to limit this "oh, I deliberately enabled nitro
> > injection and now my engine blew up, how am I supposed to know that this
> is
> > dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a
> > warning like
> >
> > "Goal X does not appear to support concurrent execution and might fail
> the
> > build, use parallel building at your own risk."
> >
> >
> Fair enough, but I would also like to be able to annotate a mojo such that
> I
> explicitly don't want it invoked in parallel and not warn the user (perhaps
> explain to the user why certain mojos cannot be executed in parallel)
>
> -Stephen
>
>
> >
> > Benjamin
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Concurrency in m3 - a status report

[nicolas de loof]

>
>
> The issue is http://jira.codehaus.org/browse/MNG-4642, and as an
> alternative solution we could
> simply make a list somewhere that blacklists/whitelists/greylists plugins,
> as long as there's a reasonable
> way to update such a list. Maybe something enforcer-like;
>
> org.codehaus.plexus:plexus-io:[,1.0), BAN:"Serious compromises of thread
> integrity"
> org.apache.maven:plugins:maven-era-plugin:*:WARN:"Can only run once per
> reactor"
> org.codehaus.modell:modello-maven-plugin:(,1.3]:BAN:"Does not work -period"
>
> If there was some place we could put such a list and update it we could
> probably provide the best
> possible information. How could we do this ?
>
>
We could maintain such compatibility matrix using a wiki page, but - to be
usable from the build by various enforcer/check plugins - it should be
deployed on central / downloaded to local repository in some
computer-compliant format.

Re: Concurrency in m3 - a status report

[nicolas de loof]

>
> Plugins
> =
> I have only managed to find "real" concurrency problems in the EAR
> plugin and modello as of yet. Modello is fixed in trunk, ear is
> not started AFIK.
>
> All the other stuff I've seen in the core plugins relate to the
> plexus-issues.
>
> Our jira issue is from a user who's complaining about plugins not
> working, and I think he's somewhat right in that we have to make some
> kind of system to indicate compatibility with the -T option.
>
> Although several strategies may be recommended, my personal favourite
> is to make a @threadsafe javadoc annotation and make M3 core
> COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
> requested (i.e. complain but still run threaded).
>
> The problem with these things is that thread safety is not necessarily a
> constant, and in the next 9 months there will be issues. So for some
> plugins @threadsafe might equally much express an intent as much as it
> reflects reality. So that makes me a bit sceptical to @threadsafe too.
>
>
+1, I can't see any way to ENSURE a plugin is threadsafe as it depends on
project and  (maybe overriden) plugin dependencies. We can just tag a plugin
to be expected to work fine in multithreaded context

I'd suggest to get a @NotThreadSafe annotation for plugins that are KNOWN to
not be thread safe, mostly due ti the embedded tools. I got
ConcurrentModification issues with aspectJ plugin, so I don't think any
AJC-based plugin could work fine with // build.

I don't know the way the weave mode is expected to work, but it could maybe
support such @NotThreadSafe plugins by locking concurrent execution of the
same plugin, but still runing other ones/othe phases in // modules.



> Aggressively displaying the link to the wiki page containing the
> most up-todate threading info may be an equally good solution; maybe
> even adding a WARNING: Experimental  or something to the build output.
>

+1
As we can't make the world thread safe, let the user know what's possible
and how to tweak the build.


>
>
> http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
> +Maven+3 (if it's up), should contain all the information needed on
> which plugins are known to have issues. But as we all know, it's an open
> ecosystem.
>
> Documentation
> 
> I will keep the wiki page updated, provided cwiki.a.o actually stays
> up ;)
> I will add a section on mojo threading models/threading concerns to the
> mojo api specification.
>
>
> I think we have to take some extra measures to keep users out of the
> issue trackers on this one, or at least make sure they go to the right
> place.
>
> What do you think ?
>
> Kristian
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Re : MNG-4483

[nicolas de loof]

+1 for .mvn and backward compatibility with .m2 if not found

2010/4/22 Julien HENRY 

> +1
>
>
>
> - Message d'origine 
> > De : Paul Benedict 
> > À : Maven Developers List 
> > Envoyé le : Jeu 22 avril 2010, 17 h 14 min 15 s
> > Objet : MNG-4483
> >
> > 3.0-beta-1 being a beta release, it's getting close to GA. I was
> wondering
> > can MNG-4483 be addressed? I don't think Maven can keep the
> .m2 user
> > directory exclusively -- it could be a good fallback for
> compatibility -- but
> > it should be looking for .m3 or
> > .mvn.
>
> Paul
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.0-beta-1

[nicolas de loof]

+1

works fine on my test-projects

2010/4/22 Igor Fedorenko 

> +1
>
> Works for Tycho (although I had to fix a couple of sloppy tests) and few
> our internal projects I work on.
>
> --
> Regards,
> Igor
>
> Benjamin Bentmann wrote:
>
>> Hi,
>>
>> We solved 39 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16089
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-042/
>>
>> Staged source and binary distros:
>>
>> https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.0-beta-1/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> +1 from me
>>
>>
>> Benjamin
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MRELEASE-261 - regression ?

[nicolas de loof]

done http://jira.codehaus.org/browse/MRELEASE-546

2010/4/13 Deng Ching 

> Hi Nicolas,
>
> Please open a new one, note it as a regression and link it to MRELEASE-261
> to avoid problems in the fix versions :)
>
> Thanks,
> Deng
>
> On Tue, Apr 13, 2010 at 5:04 PM, nicolas de loof
> wrote:
>
> > Hi
> >
> > I get some regressions with maven-release-plugin related to
> > http://jira.codehaus.org/browse/MRELEASE-261
> >
> >
> > Here is a testCase to demonstrate the issue. This is the same testCase as
> > the existing one BUT the parent project is not first one in the reactor
> > project list
> >
> >
> >public void
> > testGetCommonBasedirOfRegularMultiModuleRootNotBeeingFirstInReactor()
> >throws Exception
> >{
> >assertEquals( "/working/directory/flat-multi-module",
> > ReleaseUtil.getCommonBasedir( Arrays.asList(
> >new MavenProject[]{
> >createProject( "/working/directory/flat-multi-module/core"
> > ),
> >createProject( "/working/directory/flat-multi-module" ),
> >createProject(
> "/working/directory/flat-multi-module/webapp"
> > )} ), '/' ) );
> >}
> >
> > The result from getCommonBasedir is "/working/directory/"
> >
> >
> > Should I reopen the issue or create a new one ?
> >
>

MRELEASE-261 - regression ?

[nicolas de loof]

Hi

I get some regressions with maven-release-plugin related to
http://jira.codehaus.org/browse/MRELEASE-261


Here is a testCase to demonstrate the issue. This is the same testCase as
the existing one BUT the parent project is not first one in the reactor
project list


public void
testGetCommonBasedirOfRegularMultiModuleRootNotBeeingFirstInReactor()
throws Exception
{
assertEquals( "/working/directory/flat-multi-module",
ReleaseUtil.getCommonBasedir( Arrays.asList(
new MavenProject[]{
createProject( "/working/directory/flat-multi-module/core"
),
createProject( "/working/directory/flat-multi-module" ),
createProject( "/working/directory/flat-multi-module/webapp"
)} ), '/' ) );
}

The result from getCommonBasedir is "/working/directory/"


Should I reopen the issue or create a new one ?

Re: m3// and plugins with improper singleton handling

[nicolas de loof]

Do we have any top-level jira for thread-safety and // build issues ?
I myself got failures in // build with AspectJ plugin

2010/4/12 Kristian Rosenvold 

> I found the bug in the modello plugin that was breaking /any/ build using
> modello in multi-modules; and I'm fairly sure the same kind of issue will be
> found elsewhere:
>
> Quite simply the mojo's use plexus components that are singletons but the
> mojos themselves contain per-request mutable state (
> http://jira.codehaus.org/browse/MODELLO-239).
>
> Since we're only a very short time away from beta-1 I just wanted to know
> what you think should be done:
>
> A) Treat this as a documentation problem and do maybe just update some mojo
> guidelines regarding singleton usage, maybe keep a list of known good
> versions.
> B) Add some kind of "isThreadSafe" attribute to the mojo metadata that
> could be used to assert if the mojo can be run concurrently without warning,
> i.e.:
> if ( isParallel() && !isThreadSafe( mojo))
> {
>   logger.warn("Mojo " + mojo + " is not known to be thread safe and may
> have issues running concurrently");
> }
> C) Something else  ?
>
>
> Thoughts ? If B, how should it be done ?
>
> Kristian
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Compiler Plugin 2.3

[nicolas de loof]

Cool !

+1

2010/4/11 Jason van Zyl 

> On Apr 11, 2010, at 2:02 AM, nicolas de loof wrote:
>
> > Will this change be supported in m2eclipse ? I mean : will m2e detect the
> > maven-compiler-plugin 2.3+ version and set JRE1.5 classpath container ?
> >
>
> Configurators operate on the effective POM. So when we update M2Eclipse to
> use 3.0-beta-1 where the maven-compiler-plugin version 2.3 will be injected
> into the model then yes.
>
> > 2010/4/10 Stephen Connolly 
> >
> >> +1
> >>
> >> Sent from my [rhymes with tryPod] ;-)
> >>
> >> On 10 Apr 2010, at 12:40, Jason van Zyl  wrote:
> >>
> >> Hi,
> >>>
> >>> This was simply to bump the default source/target to 1.5. I don't want
> >>> 3.0-beta-1 released requiring people to set these as they should be
> defaults
> >>> now.
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-011
> >>>
> >>> All we fixed was this:
> >>> http://jira.codehaus.org/browse/MCOMPILER-80
> >>>
> >>> Guide to testing staged releases:
> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>> +1 from me.
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> --
> >>> Jason van Zyl
> >>> Founder,  Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> --
> >>>
> >>>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> --
>
>

Re: [VOTE] Release Maven Compiler Plugin 2.3

[nicolas de loof]

Will this change be supported in m2eclipse ? I mean : will m2e detect the
maven-compiler-plugin 2.3+ version and set JRE1.5 classpath container ?

2010/4/10 Stephen Connolly 

> +1
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 10 Apr 2010, at 12:40, Jason van Zyl  wrote:
>
>  Hi,
>>
>> This was simply to bump the default source/target to 1.5. I don't want
>> 3.0-beta-1 released requiring people to set these as they should be defaults
>> now.
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-011
>>
>> All we fixed was this:
>> http://jira.codehaus.org/browse/MCOMPILER-80
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> +1 from me.
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> --
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Compiler Plugin 2.2

[nicolas de loof]

+1

2010/4/1 

> +1
>
> > Hi,
> >
> > We solved 6 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130&version=16097
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-00<
> https://repository.apache.org/content/repositories/maven-008/>
> > 3
> >
> > Staging site (sync pending):
> > http://maven.apache.org/plugins/maven-compiler-plugin-<
> http://maven.apache.org/plugins/maven-shade-plugin-1.3.2/>
> > 2.2
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me
> >
> >
> > Milos
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.0-alpha-7

[nicolas de loof]

+1

Still partisant of a "milestone" naming convention to avoid assumptions on
code quality and stability.

2010/3/10 Olivier Lamy 

> +1 (IMHO we could change the name to at least beta as it works really
> fine :-) ).
>
> 2010/3/9 Benjamin Bentmann :
> > Hi,
> >
> > We solved 22 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16087
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-007/
> >
> > Staged source and binary distros:
> >
> https://repository.apache.org/content/repositories/maven-007/org/apache/maven/apache-maven/3.0-alpha-7/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me
> >
> >
> > Benjamin
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: annotations support in compiler mojo

[nicolas de loof]

Would such a dedicated plugin only apply annotation processing or replace
compiler plugin ? This may implies duplicate configuration for compiler +
annotation-processing plugins. Also consider slower build process as javac
will need to parse source code 2 times.

(late) +1 for annotations support in maven-compiler-plugin
Nicolas

2010/2/10 Brian Fox 

> Does it make sense to create a plugin specifically for annotation
> processing?
>
> On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint  wrote:
> > can I read silence as lazy consensus to add annotation processing to the
> > compiler plugin?
> >
> > Milos
> >
> > On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint  wrote:
> >
> >> Hello,
> >>
> >> I'd like to start a discussion about how annotations are supported in
> maven
> >> builds. I'm currently trying to use some NetBeans Platform based
> annotations
> >> in maven projects and I'm encountering some problems.
> >>
> >> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs to
> be
> >> always set to have the annotations processed. fixed in latest plexus
> >> compiler sources..
> >> 2. some annotation processors require resources to be present on the
> >> sourcepath eg. one that generates java beans from schema or another one
> that
> >> checks for property bundle key presence. I'm not sure how to make this
> >> generally available to the processor. resources themselves (in
> >> src/main/resources) are not to be referenced I guess (as they could be
> on
> >> wrong  or not filtered). So the only other option is to
> include
> >> the target/classes folder somehow with the correctly processed
> resources.
> >> Any other idea?
> >> 3. Some annotation processors generate xml files or META-INF/services
> >> content, some generate java files. the default output location for the
> >> processor is target/classes, which is fine for xml files, but it's
> >> inconvenient to generate java files there as they end up in the jar file
> >> then. I've tried to configure the compiler to use
> >> target/generated-sources/annotations as the output folder for sources
> (via
> >> -s  switch). Unfortunately there are problems associated with that
> >> approach.
> >>a. the folder needs to exist up front or the compiler chokes on it.
> >> Doable with some ant-run scripting, but ugly.
> >>b. what to do with the resources there that need to be copied to the
> >> target/classes folder? Doable with resources:copy-resources but again
> ugly.
> >> 4. reporting from the annotations processors is broken -
> >> http://jira.codehaus.org/browse/MCOMPILER-66
> >>
> >>
> >> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be
> dedicated
> >> to annotation support. Is anyone actively working on it? I'm
> volunteering to
> >> add some of the required switches as prameters for the compiler mojo,
> but
> >> I'm unsure how to proceed. Is it ok just to add the required stuff as
> mojo
> >> params, even if it will be unused by some of the other compilers? and
> even
> >> by the non 1.6 javac compilers? or have some new ways fo configuring the
> >> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14)?
> >>
> >> Thanks for any comments.
> >>
> >> Milos
> >>
> >> PS: I can provide a sample project with the above mentioned annotations
> >> being used if there is interest.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release MavenCheckstyle plugin version 2.5

[nicolas de loof]

+1

2010/2/8 Olivier Lamy 

> Hi,
> I'd like to release maven-checkstyle-plugin version 2.5.
> It's a small release to make it working with maven 3.
>
> We solved 1 issue:
>
> http://jira.codehaus.org/browse/MCHECKSTYLE-123
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-002/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.5
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 3 alpha status

[nicolas de loof]

could we use "milestone" as names in replacement for "alpha", so that we get
more early-adopter to test the (pre)release and detected regressions ?

I can understand the difficulty to suggest a build tool with "alpha" in
version name. Would you install Windows 8 alpha on your @work computer ? ;)

2010/1/29 Stephane Nicoll 

> Which bug are your talking about? Have you filled something in Jira?
>
> S.
>
> On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY  wrote:
>
> > Hi,
> >
> > Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and
> dependency
> > with type "xml.zip". This dependency was declared in another module of
> the
> > reactor, and was a dependency of a plugin (maven-andromda-plugin). So
> there
> > is no reason that the ear plugin "see" this dependency.
> > As I read Maven 3 is much more precise dealing with plugin classpath and
> > dependencies, I asked the project leader to try with Maven 3 alpha 6.
> > Hourra! It worked fine.
> >
> > So I told the project to migrate to Maven 3 but the project leader was
> > reluctant as it is flagged as "alpha".
> >
> > As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven
> > 2.2.1, could you please for next release use a version with a "higher"
> > qualifier that will not afraid corporate people. IMHO "beta" will face
> the
> > same issue, so I suggest "rc" or something like that.
> >
> > Best regards,
> >
> > Julien
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Large Systems Suck: This rule is 100% transitive. If you build one, you
> suck" -- S.Yegge
>

Re: [VOTE] Release Surefire 2.5 (take 3)

[nicolas de loof]

+1

Nicolas

2010/1/16 Hervé BOUTEMY 

> +1
>
> Hervé
>
> Le mercredi 13 janvier 2010, Stephen Connolly a écrit :
> > Hi,
> >
> > We solved 16 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=14
> > 119&styleName=Html
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10541&st
> > atus=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-034/
> >
> > Staging site(s):
> > http://maven.apache.org/plugins/maven-surefire-plugin-2.5/
> > http://maven.apache.org/plugins/maven-failsafe-plugin-2.5/
> > http://maven.apache.org/plugins/maven-surefire-report-plugin-2.5/
> > http://maven.apache.org/surefire/staging/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releasing maven-eclipse-plugin

[nicolas de loof]

Same issue on my project using m2eclipse <= 0.9.8

0.9.9 introduce many improvements that makes m2eclipse compliant with large
multi-modules projets

Nicolas

2010/1/14 Daniel Kulp 

>
>
> Can we at least get a snapshot staged with your changes so I can double
> check
> that it doesn't break the CXF instructions?
>
> Specifically, we tell people not to use m2eclipse as it generally takes a
> couple HOURS to import CXF into m2eclipse and then the normal edit/save/run
> unit test cycle in m2eclipse takes minutes, not seconds.With the normal
> maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the
> m2eclipse experience could match, I'd have no problems recommending it.
> But
> it's too painful right now.
>
> Dan
>
>
> On Thu January 14 2010 10:43:45 am Jason van Zyl wrote:
> > Hi,
> >
> > There are some issues left in the 2.8 for the maven-eclipse-plugin but if
> >  no one is going work on it then I'll just release it.
> >
> > I specifically want to release the addition I've made to the
> >  maven-eclipse-plugin which will stop the confusion among users where
> they
> >  think stuff generated by maven-eclipse-plugin is supported in M2Eclipse.
> >
> > There are projects like CXF that specifically tell users not to use
> >  M2Eclipse, which is fine, but I want support issues to fall back to
> those
> >  projects who want to support the maven-eclipse-plugin. More often then
> not
> >  they become the problem of the M2Eclipse developers. So this is really
> to
> >  partition the support where it belongs. It's a simple change, I just
> added
> >  a comment which we will detect in M2Eclipse and tell users what they are
> >  attempting are not supported.
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > --
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Clean Plugin 2.4

[nicolas de loof]

+1

Nicolas

2010/1/14 Vincent Siveton 

> +1
>
> Vincent
>
> 2010/1/10 Benjamin Bentmann :
> > Hi,
> >
> > We solved 2 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128&version=14882
> >
> > There are still a couple of issues left in JIRA:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11128&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-022/
> >
> > Staging site:
> > http://maven.apache.org/plugins/maven-clean-plugin-2.4/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > +1 from me.
> >
> >
> > Benjamin
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Surefire 2.5 (take 3)

[nicolas de loof]

+1

Nicolas

2010/1/13 Kristian Rosenvold 

> +1
>
> Nice work dealing with all the trouble yesterday.
>
> Kristian
>
>
> On Wed, Jan 13, 2010 at 7:34 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 16 issues:
> >
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=14119&styleName=Html
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10541&status=1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-034/
> >
> > Staging site(s):
> > http://maven.apache.org/plugins/maven-surefire-plugin-2.5/
> > http://maven.apache.org/plugins/maven-failsafe-plugin-2.5/
> > http://maven.apache.org/plugins/maven-surefire-report-plugin-2.5/
> > http://maven.apache.org/surefire/staging/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: maven-gwt-plugin 1.2 documentation

[nicolas de loof]

Oups, this sentence was used during SNAPSHOT developement and should have
been removed before release

Need some doc cleanup :)

2010/1/11 Henri Gomez 

> Thanks Nicolas :)
>
> I was not sure since I read the sentence :
>
> "version 1.2 includes a preview of gwt 2.0 support"
>
> Also :
>
>  mvn archetype:generate \
>   -DarchetypeGroupId=org.codehaus.mojo \
>   -DarchetypeArtifactId=gwt-maven-plugin \
>   -DarchetypeVersion=1.1 \
>   -DgroupId=myGroupId \
>   -DartifactId=myArtifactId
>
> but archetype version 1.2 is available.
>
> In the doc reference to the gwt-maven-plugin are still to 1.1.
>
>
>
> 2010/1/11 nicolas de loof :
> > This doc is up-to-date.
> >
> > the 1.2 version is not dedicated to gwt 2.0, it just support this version
> as
> > GWT >= 1.4
> >
> > 2010/1/11 Henri Gomez 
> >
> >> Hi to all,
> >>
> >> I'll do some GWT 2.0.x application and get a look at
> >>
> >> http://mojo.codehaus.org/gwt-maven-plugin/
> >>
> >> The documentation is still mainly for plugin 1.1 (gwt 1.7.x) with some
> >> notice for gwt 2.0 support.
> >>
> >> Did there is an up to date documentation available somewhere for best
> >> practices with gwt-maven-plugin 1.2 released in late December.
> >>
> >> Regards
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: maven-gwt-plugin 1.2 documentation

[nicolas de loof]

This doc is up-to-date.

the 1.2 version is not dedicated to gwt 2.0, it just support this version as
GWT >= 1.4

2010/1/11 Henri Gomez 

> Hi to all,
>
> I'll do some GWT 2.0.x application and get a look at
>
> http://mojo.codehaus.org/gwt-maven-plugin/
>
> The documentation is still mainly for plugin 1.1 (gwt 1.7.x) with some
> notice for gwt 2.0 support.
>
> Did there is an up to date documentation available somewhere for best
> practices with gwt-maven-plugin 1.2 released in late December.
>
> Regards
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Compiler plugin version 2.1

[nicolas de loof]

links in left menu are all broken, maybe this is just a staging issue

Cheers,
Nicolas

2009/12/30 Stephen Connolly 

> Hi,
>
> We solved 11 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130&version=12304&styleName=Html
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11130&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-011/
>
> Staging site:
> http://maven.apache.org/plugins/maven-compiler-plugin-2.1/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> This plugin has additionally been tested on the sonatype grid
> (https://grid.sonatype.org/ci/) against the following projects:
>
> * archetype
> * m3
> * scm
> * surefire
> * release
> * wagon
> * core-its
> * modello
> * shared
>
> -Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: m3 alpha 5 feedback

[nicolas de loof]

right, I'll setup a simplified demo project

2009/12/2 Benjamin Bentmann 

> nicolas de loof wrote:
>
>  Maven 2.2.1 deploys fine with same POM
>>
>
> Then please fill an issue with a demo project.
>
>
>
> Benjamin
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: m3 alpha 5 feedback

[nicolas de loof]

Maven 2.2.1 deploys fine with same POM

2009/12/2 Benjamin Bentmann 

> nicolas de loof wrote:
>
>  I'm using maven3-alpha-5 and get a deploy:deploy error on
>> people.apache.org (maybe related to MNG-4241 ?)
>>
>> [INFO] [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy (default-deploy)
>> on
>> project fonzie: Error deploying artifact: Authentication failed: Cannot
>> connect. Reason: Algorithm negotiation fail -> [Help 1]
>>
>
> It's important that we properly separate issues in the core and a plugin.
> So, is this error only showing up with Maven 3 or does Maven 2 (using the
> same version of the Deploy Plugin) fail the same?
>
>
> Benjamin
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

m3 alpha 5 feedback

[nicolas de loof]

Hi,

I'm using maven3-alpha-5 and get a deploy:deploy error on
people.apache.org (maybe
related to MNG-4241 ?)

[INFO] [INFO] --- maven-deploy-plugin:2.4:deploy (default-deploy) @ fonzie
---
[INFO] WAGON_VERSION: 1.0-beta-2
[INFO] [INFO]

[INFO] [INFO] BUILD FAILURE
[INFO] [INFO]

[INFO] [INFO] Total time: 9.938s
[INFO] [INFO] Finished at: Wed Dec 02 10:30:56 CET 2009
[INFO] [INFO] Final Memory: 5M/15M
[INFO] [INFO]

[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy (default-deploy) on
project fonzie: Error deploying artifact: Authentication failed: Cannot
connect. Reason: Algorithm negotiation fail -> [Help 1]

Just for info as I have no skills on SSH to investigate this ...

Cheers,
Nicolas

Re: [VOTE] Release Apache Maven 3.0-alpha-5

[nicolas de loof]

+1

2009/11/23 Arnaud HERITIER 

> +1
>
> Arnaud Héritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> On Mon, Nov 23, 2009 at 5:38 PM, Jason van Zyl  wrote:
>
> > +1
> >
> >
> > On 2009-11-23, at 11:33 AM, Benjamin Bentmann wrote:
> >
> >  Hi,
> >>
> >> We solved some more issues:
> >>
> >>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
> >>
> >> There are still a couple of issues left in JIRA:
> >>
> >>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-018/
> >>
> >> Staged source and binary distros:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
> >>
> >> Guide to testing staged releases:
> >> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> +1 from me
> >>
> >>
> >> Benjamim
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > --
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Maven Checkstyle plugin version 2.4

[nicolas de loof]

+1

2009/11/12 Mark Hobson 

> Hi,
>
> The big new feature in this release is an upgrade to Checkstyle 5.0,
> which brings Java 5 compatibility.
>
> We solved 6 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-001/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
> (Wait for sync, or use proxy)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: devoxx?

[nicolas de loof]

I do, 5 days
Nicolas

2009/11/3 Stephane Nicoll 

> Hey guys,
>
> Who's coming at the devoxx conference this year?
>
> _o/
>
> S.
>
> --
> Large Systems Suck: This rule is 100% transitive. If you build one, you
> suck" -- S.Yegge
>

Re: [VOTE] Release Maven Plugin Tools 2.5.1

[nicolas de loof]

+1
Welcome Qdox update needed for better Java5 support (some generics issues
...)

2009/10/4 Benjamin Bentmann 

> Hi,
>
> We solved 10 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=15018&styleName=Html&projectId=11139
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11139&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-staging-002/
>
> Staging site (sync pending):
> http://maven.apache.org/plugins/maven-plugin-plugin-2.5.1/
> http://maven.apache.org/plugin-tools-2.5.1/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me.
>
>
> Benjamin
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

schema for plugins and assisted POM edition

[nicolas de loof]

Just found this article
http://blog.springfuse.com/2009/09/better-way-to-handle-maven-plugin.html on
maven plugin configuration using a dedicated XML schema.
This could be a nice enhancement to plugin-tools to generate an XML schema
for mojos parameters as part of the plugin site, to help POM edition /
validation.

What do you thing about that ?
Nicolas

Re: [vote] Invite Stephen Connolly to join Maven committers

[nicolas de loof]

+1
Nicolas

2009/9/7 Hervé BOUTEMY 

> +1
>
> Hervé
>
> Le lundi 07 septembre 2009, Arnaud HERITIER a écrit :
> > Hi all,
> >   I'd like to propose giving commit access to Stephen Connolly.
> >   He is already a committer @ Mojo for many monthes and did a great work
> on
> > several plugins.
> >   He is the author of the very useful versions plugin. He is working on
> > several others plugins like animal-sniffer.
> >   He's doing a job of quality (with unit and integration tests) and
> follows
> > our best practices.
> >   He's participating on our mailing lists for a least 2 years.
> >   I helped him several time to apply some patches on our plugins and
> shared
> > components.
> >   Now he would like to help on toolchains and adding its support in
> > enforcer.
> >
> >   I think we need more people as involved as Stephen has been.
> >
> >   Please vote. 72h +1/+0/-1
> >
> >   Here is my +1.
> >
> > Cheers,
> >
> > Arnaud
> >
> > # Arnaud Héritier
> > # Software Factory Manager
> > # eXo Platform
> > # http://www.exoplatform.com
> > # http://blog.aheritier.net
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

deploy on apache.snapshots ?

[nicolas de loof]

Hi,

I'd like to migrate commons-monitoring to use the new plexus-based
apache.snapshots
I can login to this instance with my apache ID, but can't deploy with this
setup :



  apache.snapshots
  https://repository.apache.org/content/repositories/snapshots



Did I missed something ?

Cheers,
Nicolas

Re: [VOTE] Commit access for Igor Fedorenko

[nicolas de loof]

+1

2009/7/29 Brian Fox 

> +1
>
> On Tue, Jul 28, 2009 at 6:52 PM, Jason van Zyl
> wrote:
> > Hi,
> >
> > Igor has been submitting patches for over a year now and in the last 12
> > weeks he's been submitting some very substantive changes to 3.x.
> >
> > Igor has done things like create a performance framework for Maven 3.x to
> > make sure it doesn't regress, has created some APIs to make Maven Plugins
> > capable of working in an incremental environment like Eclipse, he's
> > implemented some lifecycle extension hooks, helped with the delegating
> local
> > repository infrastructure, and has generally become pretty handy with
> > Maven's core.
> >
> > I think he would be a great addition to the team.
> >
> > +1
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/SonatypeNexus
> > http://twitter.com/SonatypeM2E
> > --
> >
> > First, the taking in of scattered particulars under one Idea,
> > so that everyone understands what is being talked about ... Second,
> > the separation of the Idea into parts, by dividing it at the joints,
> > as nature directs, not breaking any limb in half as a bad carver might.
> >
> >  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Javadoc plugin version 2.6

[nicolas de loof]

+1

2009/7/26 Vincent Siveton 

> 2009/7/26, Karl Heinz Marbaise :
> > http://maven.apache.org/plugins/maven-javadoc-plugin-2.6/
> > >
> >  this links results in "Page not found"...
>
> You need to wait for the sync or to use the asf proxy.
>
> Cheers,
>
> Vincent
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Removal of old-school reactor mode from Maven 3.x

[nicolas de loof]

Sure, this sounds like a ugly hack now we have a far clever wat to select
modules to be built
+1 for deprecation

2009/7/24 Benjamin Bentmann 

> Hi,
>
> Maven 2.x supports a CLI like
>
>  mvn -r -D maven.reactor.includes=... -D maven.reactor.excludes=...
>
> to select sub directories of the current directory by glob patterns for the
> reactor.
>
> Now that the Make-like reactor mode is in-place [0], I wonder whether this
> old-school mode still serves interesting use cases that cannot be handled by
> the new reactor mode.
>
> WDYT?
>
>
> Benjamin
>
>
> [0] http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

URGENT spam on jira

[nicolas de loof]

Can a Jira guru disable "ouigon8423" account that is creating SPAM issues :
 [jira] Created: (MBUILDHELPER-13)

Re: [VOTE] Release Maven Remote Resources Plugin version 1.0.1

[nicolas de loof]

+1

2009/7/21 Arnaud HERITIER 

> +1
> Cheers,
>
> Arnaud
>
> # Arnaud Héritier
> # Software Factory Manager
> # eXo Platform
> # http://www.exoplatform.com
> # http://blog.aheritier.net
>
>
> On Tue, Jul 21, 2009 at 6:13 PM, Jason van Zyl 
> wrote:
>
> > Hi,
> >
> > This is a maintenance release of the maven-remote-resources-plugin.
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-staging-019/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > JIRA Roadmap:
> >
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11391&fixfor=15148
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/SonatypeNexus
> > http://twitter.com/SonatypeM2E
> > --
> >
> > Selfish deeds are the shortest path to self destruction.
> >
> >  -- The Seven Samuari, Akira Kurosawa
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Stop support for legacy repository layout in 3.x

[nicolas de loof]

Legacy layout is still used at http://download.java.net/maven/1/ by some
project, including some standard Java API (activation, mail, persistence...)
can we expect them to migrate to http://download.java.net/maven/2/ ? Maybe
some evangelism / lobbying could help ;)

A repo manager can safely convert such repo on the fly to default layout,
but this is an extra infrastructure setup that mostly target entreprises,
not considering standalone (laptop) use. For this reason I'm only +0 with
this proposal.

As the repository is hidden by Mercury abstraction (AFAIK), would this
really make Maven simplier ?

Cheers,
Nicolas



2009/7/20 Jason van Zyl 

> Hi,
>
> Maven 2.x has been out for quite some number of years now, and I wanted to
> float the idea of stopping support for the legacy repository format in 3.x?
>
> There are tools now that can convert repository formats, and I believe all
> of the three popular repository managers support dynamic mapping to legacy
> format for Maven 1.x clients.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> --
>
> What matters is not ideas, but the people who have them. Good people can
> fix bad ideas, but good ideas can't save bad people.
>
>  -- Paul Graham
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: proposal for cleaning up 2.x series releases / trees

[nicolas de loof]

I'm also fine with this, just would like to avoid some "EOL" tag on 2.0 that
may be considered as lack of support by some corporate users using (old)
maven releases


2009/6/30 Christian Gruber 

> No arguments with that statement.
>
> Christian.
>
>
> On Jun 30, 2009, at 10:49 AM, Brian Fox wrote:
>
>  That's all fine, I'm just saying that 2.0.10 has been out for a while
>> now without any serious show stoppers that I'm aware of. 2.0.9 and
>> 2.0.10 are very stable, I would rather see effort spent on the 2.2.x
>> line instead.
>>
>> On Tue, Jun 30, 2009 at 10:13 AM, Christian
>> Gruber wrote:
>>
>>> +1 to Nicholas' assessment.  Too many firms I've worked with won't be
>>> changing to 2.1/2.2 until it's been in production release for several
>>> months, and probably won't trust it.  They'll need critical bug support
>>> on
>>> 2.0.  We just need a window for migration, that's all.
>>>
>>> cheers,
>>> Christian.
>>>
>>> On Jun 30, 2009, at 9:52 AM, nicolas de loof wrote:
>>>
>>>  Brett Porter wrote:
>>>>
>>>> - remove the 2.1.1 version from JIRA and remove the 2.1.x SVN branch -
>>>>
>>>>>
>>>>>
>>>> +1
>>>>
>>>> - promote the 2.2.0 as the stable release on the site and push all
>>>> bugfix
>>>>
>>>>>
>>>>> work towards 2.2.x
>>>>>
>>>>>
>>>> +1
>>>>
>>>> - a 2.0.11 release to get those sticking to 2.0.x the 37 fixes already
>>>>
>>>>>
>>>>> committed there.
>>>>>
>>>>>
>>>> +1
>>>>
>>>> - declare 2.0.x EOL after that release and delete the branch
>>>>
>>>>>
>>>>>
>>>> non binding -1 : The 2.0 user base is still large, most of them just
>>>> don't
>>>> yet use the latest 2.0.10. We could just promote 2.2.x as the latest
>>>> stable
>>>> release BUT still consider a critical bug-fix branch for 2.0.x
>>>>
>>>> 2009/6/30 Paul Benedict 
>>>>
>>>>  Personally, I will not be upgrading to Maven 2.2 until the next patch
>>>>> release. I am skipping 2.1 because there is no 2.1.1. Being
>>>>> conservative in my approach, I find it just too risky inside an
>>>>> organization to bring in upgrades without at least one patch release.
>>>>>
>>>>> Will anyone yet document justification for upgrading to 2.2/2.1 from
>>>>> 2.0? JIRA notes are for the "geeks" but a general summary would be
>>>>> worthwhile.
>>>>>
>>>>> I disagree with deleting branches. I think that's extreme.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Tue, Jun 30, 2009 at 8:05 AM, Jason van Zyl
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On 29-Jun-09, at 7:54 PM, Brian Fox wrote:
>>>>>>
>>>>>>  Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I
>>>>>>> feel like it's EOL now.
>>>>>>>
>>>>>>>
>>>>>> I would guess the vast majority of users are still using the 2.0.x
>>>>>> line
>>>>>> because the 2.1.x and 2.2.x lines have come out very quickly and users
>>>>>>
>>>>>
>>>>> will
>>>>>
>>>>>>
>>>>>> probably let those bake awhile. I think there are still too many
>>>>>> inconsistencies between the lines and change between minor versions
>>>>>>
>>>>>
>>>>> happened
>>>>>
>>>>>>
>>>>>> a little too quickly for people to absorb. I think the 2.0.x line will
>>>>>>
>>>>>
>>>>> still
>>>>>
>>>>>>
>>>>>> be in widespread use for the next year.
>>>>>>
>>>>>>  On Mon, Jun 29, 2009 at 7:33 PM, Brett Porter
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Just a matter of clarity. If its not there, there will be no
>>>>>>>> questio

Re: proposal for cleaning up 2.x series releases / trees

[nicolas de loof]

Brett Porter wrote:

- remove the 2.1.1 version from JIRA and remove the 2.1.x SVN branch -
>

+1

- promote the 2.2.0 as the stable release on the site and push all bugfix
> work towards 2.2.x
>

+1

- a 2.0.11 release to get those sticking to 2.0.x the 37 fixes already
> committed there.
>

+1

- declare 2.0.x EOL after that release and delete the branch
>

non binding -1 : The 2.0 user base is still large, most of them just don't
yet use the latest 2.0.10. We could just promote 2.2.x as the latest stable
release BUT still consider a critical bug-fix branch for 2.0.x

2009/6/30 Paul Benedict 

> Personally, I will not be upgrading to Maven 2.2 until the next patch
> release. I am skipping 2.1 because there is no 2.1.1. Being
> conservative in my approach, I find it just too risky inside an
> organization to bring in upgrades without at least one patch release.
>
> Will anyone yet document justification for upgrading to 2.2/2.1 from
> 2.0? JIRA notes are for the "geeks" but a general summary would be
> worthwhile.
>
> I disagree with deleting branches. I think that's extreme.
>
> Paul
>
> On Tue, Jun 30, 2009 at 8:05 AM, Jason van Zyl
> wrote:
> > On 29-Jun-09, at 7:54 PM, Brian Fox wrote:
> >
> >> Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I
> >> feel like it's EOL now.
> >>
> >
> > I would guess the vast majority of users are still using the 2.0.x line
> > because the 2.1.x and 2.2.x lines have come out very quickly and users
> will
> > probably let those bake awhile. I think there are still too many
> > inconsistencies between the lines and change between minor versions
> happened
> > a little too quickly for people to absorb. I think the 2.0.x line will
> still
> > be in widespread use for the next year.
> >
> >> On Mon, Jun 29, 2009 at 7:33 PM, Brett Porter wrote:
> >>>
> >>> Just a matter of clarity. If its not there, there will be no question
> >>> about
> >>> whether to merge to it or not.
> >>>
> >>> - Brett
> >>>
> >>> On 30/06/2009, at 4:12 AM, Paul Benedict wrote:
> >>>
>  Hmm...
> 
> >> - declare 2.0.x EOL after that release and delete the branch
> 
>  What harm is there in keeping it around? Even if you never return to
>  it, it doesn't cost you anything to keep it.
> 
>  Paul
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> 
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/SonatypeNexus
> > http://twitter.com/SonatypeM2E
> > --
> >
> > Three may keep a secret if two of them are dead.
> >
> >  -- Benjamin Franklin
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven 2.2.0 (Fourth Attempt)

[nicolas de loof]

+1Nicolas

2009/6/29 Lukas Theussl 

>
> +1
>
> -Lukas
>
> John Casey wrote:
>
>> Hi,
>>
>> I've resolved the issue with plexus-interpolation, reverified the ITs, and
>> restaged the release. The URLs below have been updated. Let's see if we can
>> get through this vote without further interruption, I guess.
>>
>> See also the documentation improvements listing below for more
>> information on docs related to this issue.
>>
>> [NOTE] this release is contingent upon the successful release of Maven
>> Wagon 1.0-beta-6, which is taking place in a separate thread.
>>
>> ---
>>
>> Okay, it looks like there haven't been many problems with the latest RC
>> of Maven 2.2.0. So, I'd like to put it up for a vote.
>>
>> We've solved 28 issues for this release:
>>
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=15103
>>
>> You can download the source-release artifact which contains the
>> fully-buildable project structure, or the executable binaries from here:
>>
>> https://repository.apache.org/content/repositories/maven-staging-014/
>>
>> There will be a few of documentation improvements for this release as
>> well. I haven't deployed the site updates, but you can find the
>> documents here:
>>
>>
>> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/mini/guide-building-jdk14-on-jdk15.apt
>>
>> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/mini/guide-default-execution-ids.apt
>>
>> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
>>
>> This vote will be open for 72 hours:
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Here's my +1.
>>
>> Thanks,
>>
>> -john
>>
>> ---
>> John Casey
>> Developer and PMC Member, Apache Maven (http://maven.apache.org)
>> Member, Apache Software Foundation
>>
>> "What we have to learn to do, we learn by doing."
>>   -Aristotle
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven Wagon 1.0-beta-6

[nicolas de loof]

+1,
let's have (yet another) milestone before a 1.0 final if this is usefull to
release maven 2.2.0

2009/6/26 Benjamin Bentmann 

> John Casey wrote:
>
>  https://repository.apache.org/content/repositories/maven-staging-011/
>>
>
> +1
>
>
> Benjamin
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release maven-pdf-plugin version 1.0

[nicolas de loof]

Link to the staging site is wrong, it has been deployed on
http://maven.apache.org/plugins/maven-pdf-plugin/

Cheers,
Nicolas

2009/6/25 Lukas Theussl 

>
> Hi,
>
> We solved 11 issues since the plugin was promoted from the sandbox:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932&styleName=Html&version=15118
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11932&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-staging-009/
>
> Staging site:
> http://maven.apache.org/plugins/maven-pdf-plugin-1.0/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [x] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> -Lukas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release maven-pdf-plugin version 1.0

[nicolas de loof]

+1
nice work !

any chance you create a maven-msword-plugin now ? :)

2009/6/25 Lukas Theussl 

>
> Hi,
>
> We solved 11 issues since the plugin was promoted from the sandbox:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932&styleName=Html&version=15118
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11932&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-staging-009/
>
> Staging site:
> http://maven.apache.org/plugins/maven-pdf-plugin-1.0/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [x] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> -Lukas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven 2.2.0 (Second Attempt)

[nicolas de loof]

Just as a side note, I don't thing the wiki page
http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan is up to
date with current release candidate, is it ?
Nicolas

2009/6/22 John Casey 

> I've added this sort of configuration, but I need to document it. I've got
> a proposed next release of wagon staged, and as soon as I get the
> documentation for this configuration done, I'll call the vote.
>
> -john
>
>
> Brett Porter wrote:
>
>>
>> On 20/06/2009, at 2:29 AM, Brian Fox wrote:
>>
>>  This is probably a rare situation but does present itself like a
>>> regression. On the flip side, I would love to be able to enable
>>> pre-emptive authentication but I would want to do it per server. This
>>> would have the effect of halving the requests and upload data for
>>> authenticated servers, but we shouldn't do it by default.
>>>
>>
>> If this is added as a configuration parameter of the HTTP wagon in the
>> next release it'll be configurable per-server.
>>
>> - Brett
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven 2.2.0 (Second Attempt)

[nicolas de loof]

+1

2009/6/18 Daniel Kulp 

>
> +1
>
> Tested with CXF and some of the profiles that don't work correctly with
> 2.1.0
> work fine with 2.2.0.
>
> Dan
>
>
> On Wed June 17 2009 8:50:02 pm John Casey wrote:
> > Hi,
> >
> > I'm opening a new vote for Maven 2.2.0 after closing:
> >
> > http://jira.codehaus.org/browse/MNG-4169
> > http://jira.codehaus.org/browse/MNG-4207
> >
> > All URLs below have been updated where appropriate.
> >
> > ---
> >
> > Okay, it looks like there haven't been many problems with the latest RC
> > of Maven 2.2.0. So, I'd like to put it up for a vote.
> >
> > We've solved 25 issues for this release:
> >
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=
> >Html&version=15103
> >
> > You can download the source-release artifact which contains the
> > fully-buildable project structure, or the executable binaries from here:
> >
> > https://repository.apache.org/content/repositories/maven-staging-022/
> >
> > There will be a couple of documentation improvements for this release as
> > well. I haven't deployed the site updates, but you can find the
> > documents here:
> >
> >
> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/mini/g
> >uide-building-jdk14-on-jdk15.apt
> >
> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/mini/g
> >uide-default-execution-ids.apt
> >
> > This vote will be open for 72 hours:
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Here's my +1.
> >
> > Thanks,
> >
> > -john
> >
> > ---
> > John Casey
> > Developer and PMC Member, Apache Maven (http://maven.apache.org)
> > Member, Apache Software Foundation
> >
> > "What we have to learn to do, we learn by doing."
> > -Aristotle
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>