Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
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 herve.bout...@free.fr:
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 herve.bout...@free.fr
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 herve.bout...@free.fr:
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
big
difference IMHO
Regards,
Hervé
Kristian
2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
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
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
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 kristian.rosenv...@gmail.com
:
IDE support for multiple source trees seems quite far off ?
Kristian
2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
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
Here's a quote from Rory O'Donnels e-mail:
---
It's goal is to extend the JAR file format to allow multiple, JDK
release-specific versions of class
files to coexist in a single file. An additional goal is to backport
the
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing
list. [1]
Please keep in mind that a JEP in the Candidate state is merely an
idea
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment
that
it will be delivered in
any particular release.
Comments, questions, and suggestions are welcome
Re: fix wagon http lightweight
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 strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 nicolas.del...@gmail.com 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
lightweight-http-wagon http-wagon could replace it 2011/8/28 Mark Struberg strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 nicolas.del...@gmail.com 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
except for getting volunteers, why shouldn't we be able to release pretty quickly ? jenkins releases every week :P 2011/8/28 Mark Struberg strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org Date: Sunday, August 28, 2011, 8:04 AM lightweight-http-wagon http-wagon could replace it 2011/8/28 Mark Struberg strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 nicolas.del...@gmail.com 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
can't we use slf4j to redirect such log to whatever logging system ? 2011/8/28 Olivier Lamy ol...@apache.org 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 nicolas.del...@gmail.com a écrit : lightweight-http-wagon http-wagon could replace it 2011/8/28 Mark Struberg strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 strub...@yahoo.de 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 nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: fix wagon http lightweight To: Maven Developers List dev@maven.apache.org 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 nicolas.del...@gmail.com 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
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 strub...@yahoo.de
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 nicolas.del...@gmail.com wrote:
From: nicolas de loof nicolas.del...@gmail.com
Subject: Re: fix wagon http lightweight
To: Maven Developers List dev@maven.apache.org
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 ol...@apache.org
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 nicolas.del...@gmail.com
a
écrit :
lightweight-http-wagon
http-wagon could replace it
2011/8/28 Mark Struberg strub...@yahoo.de
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 nicolas.del...@gmail.com
wrote:
From: nicolas de loof nicolas.del...@gmail.com
Subject: Re: fix wagon http lightweight
To: Maven Developers List dev@maven.apache.org
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 strub...@yahoo.de
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 nicolas.del...@gmail.com
wrote:
From: nicolas de loof nicolas.del...@gmail.com
Subject: Re: fix wagon http
lightweight
To: Maven Developers List
dev@maven.apache.org
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
nicolas.del...@gmail.com
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
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 nicolas.del...@gmail.com I'm testing a fix for WAGON-346http://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
Re: Improvement in wagon-http (use http connection pooling from ASF httpclient)
+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 ol...@apache.org 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
fix wagon http lightweight
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
Re: svn commit: r1127427 - /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/Base64Test.java
Fun to know we will have to hack commons-io to backport plexus-utils bugs ;) 2011/5/25 Stephen Connolly stephen.alan.conno...@gmail.com 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 herve.bout...@free.fr 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: Anyone want to help?
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 stephen.alan.conno...@gmail.com
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: Anyone want to help?
+1 and Nike it: Just do it(tm) http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
Re: Anyone want to help?
Oups, moved to https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement 2011/5/24 Olivier Lamy ol...@apache.org 2011/5/24 nicolas de loof nicolas.del...@gmail.com: +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: POM 4+ was Re: Moving forward with mixins
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: 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
+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
+1, simple and efficient 2011/5/24 Stephen Connolly stephen.alan.conno...@gmail.com 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 aherit...@gmail.com: 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 jdca...@commonjava.org wrote: On 5/24/11 8:25 AM, Brian Fox wrote: 2011/5/24 Arnaud Héritieraherit...@gmail.com: 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 Porterbr...@apache.org 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 thanparent,groupId,artifactId, version,templates,modules - 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.name 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 that this happens before inheritance, so templates in parents are already applied. - profiles are selected and injected - project inheritance is applied - interpolation is applied Templates would be referenced as follows: project parent ... /parent templates template groupIdorg.apache.maven.templates/groupId artifactIdmaven-release-profile-template/artifactId version1.0/version
Re: [VOTE] Release Maven Surefire Plugin version 2.8
+1 2011/3/10 Olivier Lamy ol...@apache.org +1 Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/9 Kristian Rosenvold kristian.rosenv...@gmail.com: Hi, We solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=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=truemode=hidejqlQuery=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
+1 Le 1 mars 2011 09:28, Arnaud Héritier arnaud.herit...@exoplatform.com a écrit : +1 Arnaud On Tue, Mar 1, 2011 at 2:40 PM, Mark Derricutt m...@talios.com 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 ta...@cservenak.net +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=10500version=17061 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=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
+1 2011/2/26 Hervé BOUTEMY herve.bout...@free.fr +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=11145styleName= Htmlversion=16232 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11145st 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
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 amol.fuke...@nielsen.com 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; *** project xmlns=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; modelVersion4.0.0/modelVersion groupIdcom.nielsen.outbound/groupId artifactIdoutbound/artifactId packagingwar/packaging version1.0-SNAPSHOT/version nameoutbound/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration sourcesrc/com/nielsen/outbound/*.java/source targettarget/classes/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration webXmlconf/web.xml/webXml webappDirectorytarget/work/outbound.war/webappDirectory /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution phasecompile/phase configuration tasks echoDeleting deployment../echo delete includeEmptyDirs=true dir=C:/Tomcat6/webapps/outbound / mkdir dir=C:/Tomcat6/webapps/outbound / /tasks /configuration goals goalrun/goal /goals /execution execution phasecompile/phase idcopy-resources2classes/id configuration tasks echoCopying resources to WEB-INF/classes../echo copy todir=src fileset dir=target/classes include name=**/*.properties / include name=**/*.* / /fileset /copy /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin /plugins /build /project ** Can you please help me ? Thanks, Amol Fuke
Re: [PROPOSAL] Auto-Mirror Selection for Maven 3.x
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 stephen.alan.conno...@gmail.com Yep On 18 February 2011 22:39, John Casey jdca...@commonjava.org 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 Caseyjdca...@commonjava.org 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
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: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml
2011/2/11 Jesse Farinacci jie...@gmail.com Hi, On Fri, Feb 11, 2011 at 7:58 AM, nicolas de loof nicolas.del...@gmail.com 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: Create a enforcer-incubator-rules project (was:Re: MENFORCER-19 (enforce dependencyManagement))
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 m...@batmat.net 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 sharecentralize their rules. I personnally have already written rules that I think are not very specific to my organization (forbid putting skiptrue/skip 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 bri...@infinity.nu 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 nicolas.del...@gmail.com 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 Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
MENFORCER-19 (enforce dependencyManagement)
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: Invite Evgeny Mandrikov to join Maven committers
+1 Le 26 janv. 2011 09:40, Arnaud Héritier arnaud.herit...@exoplatform.com a écrit : +1 Arnaud On Wed, Jan 26, 2011 at 9:23 AM, Lukas Theussl ltheu...@apache.org 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: '+1' vs 'I agree'
2011/1/26 John Casey jdca...@commonjava.org 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
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 ja...@maven.org On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: On 25 January 2011 15:47, Jason van Zyl ja...@maven.org 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: Use of standards in the Maven core
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 l...@jguru.se
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
aren't software and late some sort of synonyms ? 2010/10/8 Jason van Zyl ja...@sonatype.com 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
+1, works fine for me Nicolas 2010/10/4 Greg Akins angryg...@gmail.com +1 Ran against all my projects successfully On Mon, Oct 4, 2010 at 8:16 AM, Benjamin Bentmann benjamin.bentm...@udo.edu 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=10500version=13142 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=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 Compiler Plugin 2.3.2
+1 Nicolas 2010/9/5 Tony Chemit che...@codelutin.com +1 Le Sat, 04 Sep 2010 16:21:50 +0200, Benjamin Bentmann benjamin.bentm...@udo.edu a écrit : Hi, We solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=16731 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11130status=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 Maven Site Plugin 3.0-beta-2 for maven 3
Link to migration doc on index page is wrong /#migrate.html, should be /migrate.html) 2010/9/5 Tony Chemit che...@codelutin.com +1 Le Sat, 4 Sep 2010 23:06:51 +0200, Olivier Lamy ol...@apache.org a écrit : Hi, We solved 2 issues : http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146version=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 Apache Maven 3.0-beta-3 (take 2)
+1 (non binding) works fine with gwt-maven plugin 2010/9/2 Hervé BOUTEMY herve.bout...@free.fr +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=10500version=16 681 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st 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
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 kont...@stundzig.de 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
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 ja...@sonatype.com 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
+1 (non binding) Nicolas 2010/8/7 Olivier Lamy ol...@apache.org 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=11146version=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
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
Re: Merging in our Aether and Guice changes to Maven 3.x
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 jdca...@commonjava.org 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, 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
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 jdca...@commonjava.org 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 Caseyjdca...@commonjava.org 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
issue using properties in dependencies
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-env.jar
B has a dependency on C, with classifier ${env}. Running mvn install on B
works fine, and resolve C-1-env.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
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 ta...@cservenak.net 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 nicolas.del...@gmail.comwrote: 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 ta...@cservenak.net 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 nicolas.del...@gmail.comwrote: Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies 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
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
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 bri...@infinity.nu 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 nicolas.del...@gmail.com 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 ta...@cservenak.net 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 nicolas.del...@gmail.comwrote: 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 ta...@cservenak.net 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 nicolas.del...@gmail.comwrote: Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies 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
[MDEP-269] please review
Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies 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
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 ta...@cservenak.net 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 nicolas.del...@gmail.comwrote: Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies 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: Maven3 with guice was Re: Maven 3 tests
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 ol...@apache.org
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 mccu...@gmail.com:
On 7 June 2010 07:25, Olivier Lamy ol...@apache.org 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 MapFoo fooMap;
private void setFooMap( MapFoo fooMap )
{
this.fooMap = new HashMapFoo( 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 jemos.in...@googlemail.com:
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: [VOTE] Release Maven Site Plugin version 2.1.1
+1 Le 3 juin 2010 10:52, Arnaud Héritier aherit...@gmail.com 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 denn...@apache.org: 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=11146version=15923 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=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: svn commit: r950989 - /maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
+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 ol...@apache.org
Hi,
We are two who don't like this hack :-)
So what's about don't support this ?
Others ?
2010/6/3 dk...@apache.org:
Author: dkulp
Date: Thu Jun 3 13:28:57 2010
New Revision: 950989
URL: http://svn.apache.org/viewvc?rev=950989view=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=950989r1=950988r2=950989view=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 Antrun plugin version 1.4
+1 Le 25 mai 2010 10:11, Arnaud Héritier aherit...@gmail.com 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=11125version=14641 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11125status=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
Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.3
+1 2010/5/25 Lukas Theussl ltheu...@apache.org +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=10780version=15924 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624version=16452 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=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
dependency plugin vs dependency report
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
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: Concurrency in m3 - a status report
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
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 stephen.alan.conno...@gmail.com On 26 April 2010 12:05, Benjamin Bentmann benjamin.bentm...@udo.edu 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. thread-safety plugin groupId=... artifactId=... wieve-mode action=ban versions=...message/wieve-mode wieve-mode action=warn versions=...message/wieve-mode wieve-mode action=checked versions=.../ parallel-mode action=ban versions=...message/paralle-mode parallel-mode action=warn versions=...message/paralle-mode parallel-mode action=checked versions=...message/paralle-mode /plugin /thread-safety 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: [VOTE] Release Apache Maven 3.0-beta-1
+1 works fine on my test-projects 2010/4/22 Igor Fedorenko i...@ifedorenko.com +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=10500version=16089 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=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: Re : MNG-4483
+1 for .mvn and backward compatibility with .m2 if not found 2010/4/22 Julien HENRY henr...@yahoo.fr +1 - Message d'origine De : Paul Benedict pbened...@apache.org À : Maven Developers List dev@maven.apache.org 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
MRELEASE-261 - regression ?
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: MRELEASE-261 - regression ?
done http://jira.codehaus.org/browse/MRELEASE-546
2010/4/13 Deng Ching och...@apache.org
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
nicolas.del...@gmail.comwrote:
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
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 kristian.rosenv...@gmail.com
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
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 stephen.alan.conno...@gmail.com +1 Sent from my [rhymes with tryPod] ;-) On 10 Apr 2010, at 12:40, Jason van Zyl ja...@sonatype.com 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.3
Cool ! +1 2010/4/11 Jason van Zyl ja...@sonatype.com 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 stephen.alan.conno...@gmail.com +1 Sent from my [rhymes with tryPod] ;-) On 10 Apr 2010, at 12:40, Jason van Zyl ja...@sonatype.com 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.2
+1 2010/4/1 jdca...@mail.commonjava.org +1 Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=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
+1 Still partisant of a milestone naming convention to avoid assumptions on code quality and stability. 2010/3/10 Olivier Lamy ol...@apache.org +1 (IMHO we could change the name to at least beta as it works really fine :-) ). 2010/3/9 Benjamin Bentmann benjamin.bentm...@udo.edu: Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16087 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=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
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 bri...@infinity.nu Does it make sense to create a plugin specifically for annotation processing? On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint mkle...@gmail.com 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 mkle...@gmail.com 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 targetPath 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 dir 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
+1 2010/2/8 Olivier Lamy ol...@apache.org 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
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 stephane.nic...@gmail.com Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr 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)
+1 Nicolas 2010/1/16 Hervé BOUTEMY herve.bout...@free.fr +1 Hervé Le mercredi 13 janvier 2010, Stephen Connolly a écrit : Hi, We solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=14 119styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541st 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: [VOTE] Release Maven Clean Plugin 2.4
+1 Nicolas 2010/1/14 Vincent Siveton vsive...@apache.org +1 Vincent 2010/1/10 Benjamin Bentmann benjamin.bentm...@udo.edu: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=14882 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128status=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: Releasing maven-eclipse-plugin
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 dk...@apache.org 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 Surefire 2.5 (take 3)
+1 Nicolas 2010/1/13 Kristian Rosenvold kristian.rosenv...@gmail.com +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=10541version=14119styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541status=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
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 henri.go...@gmail.com 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: maven-gwt-plugin 1.2 documentation
Oups, this sentence was used during SNAPSHOT developement and should have been removed before release Need some doc cleanup :) 2010/1/11 Henri Gomez henri.go...@gmail.com 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 nicolas.del...@gmail.com: 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 henri.go...@gmail.com 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: [VOTE] Release Maven Compiler plugin version 2.1
links in left menu are all broken, maybe this is just a staging issue Cheers, Nicolas 2009/12/30 Stephen Connolly stephen.alan.conno...@gmail.com Hi, We solved 11 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=12304styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11130status=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
m3 alpha 5 feedback
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: m3 alpha 5 feedback
Maven 2.2.1 deploys fine with same POM 2009/12/2 Benjamin Bentmann benjamin.bentm...@udo.edu 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
Re: [VOTE] Release Apache Maven 3.0-alpha-5
+1 2009/11/23 Arnaud HERITIER aherit...@gmail.com +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 ja...@maven.org 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=10500version=14952 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=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
+1 2009/11/12 Mark Hobson markhob...@gmail.com 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=11127version=15336 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=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?
I do, 5 days Nicolas 2009/11/3 Stephane Nicoll stephane.nic...@gmail.com 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
+1 Welcome Qdox update needed for better Java5 support (some generics issues ...) 2009/10/4 Benjamin Bentmann benjamin.bentm...@udo.edu Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=15018styleName=HtmlprojectId=11139 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=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
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
+1 Nicolas 2009/9/7 Hervé BOUTEMY herve.bout...@free.fr +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 ?
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 : distributionManagement snapshotRepository idapache.snapshots/id urlhttps://repository.apache.org/content/repositories/snapshots/url /snapshotRepository /distributionManagement Did I missed something ? Cheers, Nicolas
Re: [VOTE] Commit access for Igor Fedorenko
+1 2009/7/29 Brian Fox bri...@infinity.nu +1 On Tue, Jul 28, 2009 at 6:52 PM, Jason van Zyljvan...@sonatype.com 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
+1 2009/7/26 Vincent Siveton vsive...@apache.org 2009/7/26, Karl Heinz Marbaise khmarba...@gmx.de: 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
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 benjamin.bentm...@udo.edu 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
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
+1 2009/7/21 Arnaud HERITIER aherit...@gmail.com +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 jvan...@sonatype.com 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=truepid=11391fixfor=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
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 jvan...@sonatype.com 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
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 pbened...@apache.org 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 Zyljvan...@sonatype.com 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 Porterbr...@apache.org 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: proposal for cleaning up 2.x series releases / trees
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 christianedwardgru...@gmail.com 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 Gruberchristianedwardgru...@gmail.com 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 pbened...@apache.org 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 Zyljvan...@sonatype.com 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 Porterbr...@apache.org 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 Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ - 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)
+1Nicolas 2009/6/29 Lukas Theussl ltheu...@apache.org +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=10500styleName=Htmlversion=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
+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 benjamin.bentm...@udo.edu 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
Link to the staging site is wrong, it has been deployed on http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/Cheers, Nicolas 2009/6/25 Lukas Theussl ltheu...@apache.org Hi, We solved 11 issues since the plugin was promoted from the sandbox: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932styleName=Htmlversion=15118 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11932status=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)
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 jdca...@commonjava.org 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] Release Doxia-1.1.1 and Doxia-Sitetools-1.1.1 (take two)
+1 Tested with the PDF plugin to generate gwt-maven-plugin doc - works fine ;) 2009/6/18 Lukas Theussl ltheu...@apache.org Hi again, We have cranked some more 23 issues into this release since the last failed attempt, so now we're at 47 (Doxia) and 6 (Sitetools) solved issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=15073 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=15075 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repos: https://repository.apache.org/content/repositories/maven-staging-019/ https://repository.apache.org/content/repositories/maven-staging-020/ Staging sites: http://maven.apache.org/doxia/doxia/ http://maven.apache.org/doxia/doxia-sitetools/ (I have deployed to the main sites as nothing major has changed wrt 1.1 and I can't use site:stage because of MSITE-404) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Note: the most convenient way to test (I think) is to use site-plugin-2.1-SNAPSHOT and/or pdf-plugin-1.0-SNAPSHOT, which both use the latest doxia snaps. Vote is 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)
+1 2009/6/18 Daniel Kulp dk...@apache.org +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=10500styleName= Htmlversion=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
Re: [VOTE] Maven 2.2.0
+1 [non-binding] works fine for me, Nicolas 2009/6/16 Reinhard Nägele reinhard.naeg...@mgm-tp.com +1 [non-binding] John Casey schrieb: Hi, 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 23 issues for this release: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=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-017/ 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/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 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] Release Maven Eclipse plugin version 2.7 (take 3)
+1 Could we move the assembly plugin configuration to the plugins parent / apache-release profile for future plugin releases to conform ASF rules ? 2009/6/8 Arnaud HERITIER aherit...@gmail.com +1Thanks a lot for your help Arnaud On Mon, Jun 8, 2009 at 10:30 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Barrie Treloar wrote: Staging repo: https://repository.apache.org/content/repositories/maven-staging-008/ +1 Staging site: http://maven.apache.org/plugins/maven-eclipse-plugin-2.7/ The staging site refers to plugin version 2.8-SNAPSHOT. Just keep in mind to deploy the final site from the tag. Thanks for your endurance during this release! Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
