Re: pre maven 3.0 binaries available ?
Jason, not sure if you remember, but m2eclipse allows to install embedder updates separately from the core. So, can publish updated embedder for early adopters consumption and it will also help to catch incompatibilities in 3.0 earlier. +1, I'll be happy to check them - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
mercury-ant update
FYI - a new dev. snapshot.
After the first round of testing and discussions mercury-ant has had a
face lift:
* added simplified syntax and a system of defaults - examples in
http://people.apache.org/~ogusakov/sites/mercury-ant/mercury-ant-tasks/howto.html
In the simplest form it could be used as:
javac srcdir=src/main/java
destdir=target/classes
classpath
deps !-- Defaults (central, local) take care of repositories --
dependency name=asm:asm:3.0/
/deps
/classpath
/javac
* added reading dependencies from a POM file
classpath
deps
dependency name=t:t:1.0::pom pom=${basedir}/t-1.0.pom/
/deps
/classpath
* support for some of maven-ant syntax - in the howto doc
* added doc. site at
http://people.apache.org/~ogusakov/sites/mercury-ant - please treat as
work-in-progress, I am still writing it
Thanks,
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r730028 - /maven/components/trunk/maven-model/src/main/mdo/maven.mdo
Author: sisbell Date: Mon Dec 29 17:33:12 2008 New Revision: 730028 URL: http://svn.apache.org/viewvc?rev=730028view=rev Log: Fix: MNG-3927 Modified: maven/components/trunk/maven-model/src/main/mdo/maven.mdo Modified: maven/components/trunk/maven-model/src/main/mdo/maven.mdo URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-model/src/main/mdo/maven.mdo?rev=730028r1=730027r2=730028view=diff == --- maven/components/trunk/maven-model/src/main/mdo/maven.mdo (original) +++ maven/components/trunk/maven-model/src/main/mdo/maven.mdo Mon Dec 29 17:33:12 2008 @@ -2733,7 +2733,7 @@ nameid/name version4.0.0/version typeString/type - defaultValuedefault/defaultValue + defaultValuedefault-execution-id/defaultValue descriptionThe identifier of this execution for labelling the goals during the build, and for matching executions to merge during inheritance./description /field @@ -2759,7 +2759,7 @@ version4.0.0/version code ![CDATA[ -public static final String DEFAULT_EXECUTION_ID = default; +public static final String DEFAULT_EXECUTION_ID = default-execution-id; Hm, looks odd that the fix for a regression is to break backward-compat somewhere else. Was that really the best option available? What if we change the default value for the field executionId in o.a.m.l.m.MojoBinding from maven-lifecycle instead? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r730028 - /maven/components/trunk/maven-model/src/main/mdo/maven.mdo
On Tue, Dec 30, 2008 at 2:47 AM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Author: sisbell Date: Mon Dec 29 17:33:12 2008 New Revision: 730028 URL: http://svn.apache.org/viewvc?rev=730028view=rev Log: Fix: MNG-3927 Modified: maven/components/trunk/maven-model/src/main/mdo/maven.mdo Modified: maven/components/trunk/maven-model/src/main/mdo/maven.mdo URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-model/src/main/mdo/maven.mdo?rev=730028r1=730027r2=730028view=diff == --- maven/components/trunk/maven-model/src/main/mdo/maven.mdo (original) +++ maven/components/trunk/maven-model/src/main/mdo/maven.mdo Mon Dec 29 17:33:12 2008 @@ -2733,7 +2733,7 @@ nameid/name version4.0.0/version typeString/type - defaultValuedefault/defaultValue + defaultValuedefault-execution-id/defaultValue descriptionThe identifier of this execution for labelling the goals during the build, and for matching executions to merge during inheritance./description /field @@ -2759,7 +2759,7 @@ version4.0.0/version code ![CDATA[ -public static final String DEFAULT_EXECUTION_ID = default; +public static final String DEFAULT_EXECUTION_ID = default-execution-id; Hm, looks odd that the fix for a regression is to break backward-compat somewhere else. In what way? Where? Was that really the best option available? What if we change the default value for the field executionId in o.a.m.l.m.MojoBinding from maven-lifecycle instead? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r730028 - /maven/components/trunk/maven-model/src/main/mdo/maven.mdo
Shane Isbell wrote: Hm, looks odd that the fix for a regression is to break backward-compat somewhere else. In what way? Where? The IDs are used to merge execution's during inheritance and profile injection. So while the both executions execution !-- Note missing id here -- configuration ... /configuration /execution execution !-- Note explicit reference to default execution id here -- iddefault/id configuration ... /configuration /execution will merge with Maven 2.x, they will no longer merge in Maven 3.x due to your recent change. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Javadoc is back to it's old misbehaving (forking) ways
We had lots of problems with javadoc 2.3 that introduced forking behavior. This was reverted in 2.4 and apparently put back in 2.5: http://svn.apache.org/viewvc/maven/plugins/tags/maven-javadoc-plugin-2.5/sr c/main/java/org/apache/maven/plugin/javadoc/JavadocReport.java?r1=661429r2= 661899 This causes problems in some projects that are now forking for example during a release. Can we find a better way to fix this without making it fork? (btw this is exactly one of the issues we need to fix in maven 3, a plugin needs to declare that at least a given phase should be run and thus if bound to a phase it won¹t fork, but if run from the cli directly, it will) http://jira.codehaus.org/browse/MRELEASE-271 http://jira.codehaus.org/browse/MJAVADOC-104
broken plexus-maven-plugin starting at 1.3.6
Starting at version 1.3.6, plexus:descriptor has the following changes:
1. default outputDirectory is ${project.build.outputDirectory}
insteadd of ${project.build.directory}/generated-resources/plexus
2. default phase is process classes instead of
generate-resources. Note merge-descriptor default phase is still at
process-resoruces
Are the intentional?
The latest maven-parent pom is at version 10, and it includes
plexus-maven-plugin 1.3.8
And therefore Wagon build is broken.
I am going to revert wagon to use maven-parent-9 if there is no objection.
-Dan
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: broken plexus-maven-plugin starting at 1.3.6
There is a new plugin that works with annotations, javadoc comments,
and handles generation and merging of existing descriptors. Works for
application and test code:
Current GAV we're using:
org.codehaus.plexus:plexus-component-metadata:1.0-beta-3.01
We're using it everywhere in trunk but I've made it compatible with
2.0.9. I've completely overhauled it so use it, instead.
I haven't touched the maven-plexus-plugin in a long time and just left
it so that people could use it as is. I think Jason Dillon worked on
it a bit and then I just created the new plugin which generally just
does everything for you without you having to configure anything.
On 30-Dec-08, at 7:35 PM, Dan Tran wrote:
Starting at version 1.3.6, plexus:descriptor has the following
changes:
1. default outputDirectory is ${project.build.outputDirectory}
insteadd of ${project.build.directory}/generated-resources/plexus
2. default phase is process classes instead of
generate-resources. Note merge-descriptor default phase is still at
process-resoruces
Are the intentional?
The latest maven-parent pom is at version 10, and it includes
plexus-maven-plugin 1.3.8
And therefore Wagon build is broken.
I am going to revert wagon to use maven-parent-9 if there is no
objection.
-Dan
-
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
jason at sonatype dot com
--
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: broken plexus-maven-plugin starting at 1.3.6
for now, I am going to set the plugin version to the old one 1.3.5 to
get the build going
where is the site of the new plugin you are talking about?
-D
On Tue, Dec 30, 2008 at 5:21 PM, Jason van Zyl jvan...@sonatype.com wrote:
There is a new plugin that works with annotations, javadoc comments, and
handles generation and merging of existing descriptors. Works for
application and test code:
Current GAV we're using:
org.codehaus.plexus:plexus-component-metadata:1.0-beta-3.01
We're using it everywhere in trunk but I've made it compatible with 2.0.9.
I've completely overhauled it so use it, instead.
I haven't touched the maven-plexus-plugin in a long time and just left it so
that people could use it as is. I think Jason Dillon worked on it a bit and
then I just created the new plugin which generally just does everything for
you without you having to configure anything.
On 30-Dec-08, at 7:35 PM, Dan Tran wrote:
Starting at version 1.3.6, plexus:descriptor has the following changes:
1. default outputDirectory is ${project.build.outputDirectory}
insteadd of ${project.build.directory}/generated-resources/plexus
2. default phase is process classes instead of
generate-resources. Note merge-descriptor default phase is still at
process-resoruces
Are the intentional?
The latest maven-parent pom is at version 10, and it includes
plexus-maven-plugin 1.3.8
And therefore Wagon build is broken.
I am going to revert wagon to use maven-parent-9 if there is no objection.
-Dan
-
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
jason at sonatype dot com
--
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
-
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
Model Version: is it really useful?
Most of my POM files look like this: project xmlns=http://maven.apache.org/POM/4.0.0; ... xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion ... /project I have always found it strange that there is a modelVersion element. What purpose does it serve that the schema location can't? It seems like a redundancy to me. Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Model Version: is it really useful?
there is a feature in Modello since november 2006, released in 1.0-alpha-13, to read the model version from namespace instead of model field. But it is only available for StAX reader, not XPP3 nor Dom4J. i don't know if there is a precise reason why this has not been integrated into Maven models. See the unit-test model [1] for such a model configuration, and the reader generator code that does the trick [2]. FYI, the version detected in the namespace has to be 4.0.0, not v4_0_0: that's another reason to modify every pom schema location to http://maven.apache.org/xsd/maven-4.0.0.xsd regards, Hervé [1] http://fisheye.codehaus.org/browse/modello/trunk/modello-plugins/modello-plugin-stax/src/test/resources/version-in-namespace.mdo?r=trunk [2] http://modello.codehaus.org/modello-plugins/modello-plugin-stax/xref/org/codehaus/modello/plugin/stax/StaxReaderGenerator.html#563 Le mercredi 31 décembre 2008, Paul Benedict a écrit : Most of my POM files look like this: project xmlns=http://maven.apache.org/POM/4.0.0; ... xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion ... /project I have always found it strange that there is a modelVersion element. What purpose does it serve that the schema location can't? It seems like a redundancy to me. 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
