[ANN] Maven Compiler Plugin 2.4 Released
Hi, The Maven team is pleased to announce the release of the Maven Compiler Plugin, version 2.4 The Compiler Plugin is used to compile the sources of your project. The default compiler is javac and is used to compile Java sources. http://maven.apache.org/plugins/maven-compiler-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version /plugin Release Notes - Maven 2.x Compiler Plugin - Version 2.4 ** Improvement * [MCOMPILER-137] - Plugin documentation refers to Maven 2 * [MCOMPILER-147] - The usage page should use pluginManagement for configuring the plugin * [MCOMPILER-166] - Use plexus-compiler 1.8.6 for performance improvement ** Bug * [MCOMPILER-64] - mvn clean install crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04 * [MCOMPILER-94] - compiler sets artifact file to target/classes, even if nothing is compiled * [MCOMPILER-99] - Spaces in for external executable are not accepted * [MCOMPILER-120] - Javac compiler plugin doesn't support -Werror * [MCOMPILER-130] - compilerArgument option doesn't work with maxerrs option, compilerArguments does * [MCOMPILER-135] - Passing multiple parameters to Java 6 annotation processors with javac does not work * [MCOMPILER-136] - The description of the skip parameter of the testCompile mojo is incorrect * [MCOMPILER-148] - Misleading documentation on configurationencoding * [MCOMPILER-149] - Java compiler warning is masking a javac exception, which the compiler plugin doesn't know how to parse * [MCOMPILER-167] - Incorrect default for generatedTestSourcesDirectory Have Fun! -- The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Changes Plugin version 2.7
For the record: my vote is not binding. Thanks for the release anyway! :) -Lukas Benson Margulies wrote: Subject: Hi, The vote has passed with the following result : +1 (binding): hboutemy, bimargulies, olamy, ltheussl +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - 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: [RESULT][VOTE] Apache Maven Compiler Plugin 2.4
same here: my vote is not binding. same here: thanks for the release anyway! :) -Lukas Olivier Lamy wrote: Hi, The vote has passed with the following result: +1 (binding): Hervé Boutemy, Kristian Rosenvold, Stephane Nicoll, Mark Struberg, Lukas Theussl, Emmanuel Venisse, Olivier Lamy +1 (non binding): Mark Derricutt, Karl Heinz Marbaise, Tony Chemit, I will continue the release process. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Changes Plugin version 2.7
oops. Sorry. On Tue, May 1, 2012 at 1:11 PM, Lukas Theussl ltheu...@apache.org wrote: For the record: my vote is not binding. Thanks for the release anyway! :) -Lukas Benson Margulies wrote: Subject: Hi, The vote has passed with the following result : +1 (binding): hboutemy, bimargulies, olamy, ltheussl +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - 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: [RFC] Reimagining the artifact and repository-interaction APIs
Hervé BOUTEMY wrote: I'm a little late, but needed time to think more on my comments :) Le lundi 9 avril 2012 17:27:09 John Casey a écrit : Hi all, I finally have some cycles free to work on Maven, and I'd like to spend some time thinking about how we might tackle some of the bigger-picture things. Personally, the first thing I'd like to see tackled is Maven's relationship to both Artifacts and the Repository system. IMO, these should be separate API artifacts with each having its own release cycle. The reasoning is that the APIs should be a contract with third parties (plugin devs, repository connector devs, etc.). The reasoning for separating them is that I believe what we do with Artifacts in Maven is largely orthogonal to the ways in which we interact with the repository system. I think we need to reimagine the way Maven interacts with the repository system (currently, I'm thinking of calling this the maven-artifact-portal system, unless something less lame comes along...it's bidirectional, so -fetcher, -retriever, etc. are out). I'd like to go all the way to refactoring the verbs given to these interactions: - 'resolve' - 'resolve' (Ok, that one's intuitive IMO) - 'deploy' - 'publish' - 'install' - 'cache' +1 for the verbs and perhaps we should not have separate install and deploy plugins but a unique artifact plugin with these verbs: the plugin name probably needs more ideas This may not be relevant at all but it just struck me that this is actually how it used to be in the maven 1 artifact plugin [1]. Not sure what the reason was to separate the two, but there probably was a reason, maybe someone remembers. Otherwise I find this whole discussion pretty useful and forward going, thanks in advance to all those who contribute! -Lukas [1] http://maven.apache.org/maven-1.x/plugins/artifact/tags.html Then, I'd like to turn the notion of a LocalRepository into an on-disk cache, whose storage format doesn't matter to the user, and which is manageable as such (flushing the cache, both in targeted and global fashion for instance). I'd also like to refactor the design to allow wholesale swapping of the repository system to a completely different architecture, or just swapping out parts (like the caching component), or even just adding in new connectors the way we can now. That's one consequence of the new verbs: we won't install to a local repository, which is misleading but cache on disk. The repository term for the local cache has always been something misleading. This urge to refactor of the repository system is something I haven't been able to get out of my head since the last time I gave up working on the decentralized maven repository code. That routing code would work fine, EXCEPT there's no place to plug it in. Part of the reason is that Maven resolves from locations that are specified on the scale of entire repositories, not on the scale of individual artifacts. Switching to an artifact-centric routing mechanism requires modification of dozens of classes. We could change all this, EXCEPT the most of those classes now reside in Aether, and that means convincing the powers that be over there that this is a worthwhile effort...probably not an easy thing. This exercise has convinced me that Maven needs to insulate itself in order to remain flexible and able to adapt to its evolving needs. Beyond the issues related to resolving artifacts, I'd like to make the depgraph more of a first-class citizen, so Maven components can query it for paths to a given artifact, along with other information. +1 what about updating shared/maven-dependency-tree to have a Maven 3 compatible version? I'd also like to build better support for pluggable versioning schemes (even if it's just for sorting versions), then make sure those schemes are actually selectable in some way. I'm skeptical, even twice skeptical: 1. is it useful? what verison numbers comparison is not good actually? Do you have an example? 2. can it be usable? I can't imagine a place to configure the choice of scheme that would be usable. Something at groupId level? But certainly not at artifact level, which is the only place that we could do at the moment AFAIK. Sure, this is a lot of work. I don't expect it to be done anytime soon, particularly if I'm the only one working on it, and only when I'm not working $dayjob or tending to Henry. But these problems are part of what's been depressing my enthusiasm for Maven in recent months, and I'd like to see them fixed. +1 to try and fix things, and +1000 to not work alone I'm looking into the SCM stuff for this work; currently, I'm tentatively planning to work out on GitHub, but maybe there's a way to use Git @ASF for this, since it'll be a few new subprojects in Maven. I'm not sure yet. I'm going to try like hell to avoid having to work with SVN (directly, at least). Git support at ASF should be sufficient by now to ask for it instead of using not connected github
Re: svn commit: r1331837 - in /maven/plugin-tools/branches/MPLUGIN-189: ./ maven-plugin-tools-annotations/ maven-plugin-tools-annotations/src/ maven-plugin-tools-annotations/src/main/ maven-plugin-too
I don't know the numbers, but I'm assuming that 99 out of 100 times the expression is filled with a command line argument. I can imagine why the name 'expression' was used: it must contain exactly one expression. But that's from the technical perspective. We've all seen the threads where users try to use the name of the configuration-property name instead of the expression as argument for a plugin. The name 'expression' doesn't trigger the users. From that perspective I hope that 'argument' is clearer. I don't think that 'value' would be much better for users, but maybe it's also a matter of improving the goal docs generation. -Robert Op Mon, 30 Apr 2012 22:19:14 +0200 schreef Hervé BOUTEMY herve.bout...@free.fr: probably a good occasion to improve usability but I don't understand argument, even if I can't find any good proposition value? as opposed to default-value? any other idea around? Regards, Hervé Le lundi 30 avril 2012 09:31:27 Robert Scholte a écrit : Hi, expression has always caused a lot of confusion for plugin-users. Should this be a moment to rename it to something like argument? -Robert Op Sat, 28 Apr 2012 23:23:11 +0200 schreef ol...@apache.org: Author: olamy Date: Sat Apr 28 21:23:10 2012 New Revision: 1331837 URL: http://svn.apache.org/viewvc?rev=1331837view=rev Log: [MPLUGIN-189] add java 5 annotations support to mark Mojo sources - 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
[ANN] Maven Site Plugin 3 3.1 Released
The Maven team is pleased to announce the release of the Maven Site Plugin 3,
version 3.1
The Maven Site Plugin is a plugin that generates a site for the current project.
http://maven.apache.org/plugins/maven-site-plugin
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.1/version
/plugin
Release Notes - Maven Site Plugin 3 - Version 3.1
Bug
* [MSITE-638] site.xml custom parameter and template variables not documented
* [MSITE-633] Doco: reference to ${currentVersion} should be
${currentStableVersion} in creating-content.html#Filtering
* [MSITE-624] Usage page has incorrect information on the id used by
site:stage-deploy
* [MSITE-621] empty outputDirectory causes mvn clean to delete whole tree
* [MSITE-620] Fix documentation of attach-descriptor according to Maven3
Compatibility Notes
* [MSITE-610] No doc for reportPlugins in main goal docs
* [MSITE-609] site:deploy is broken
* [MSITE-607] no documentation for breadcrumbs in the doc of site.xml
* [MSITE-603] ClassNotFoundException on site:site when validating XML input
documents
* [MSITE-602] The staged site is deployed to the wrong place
* [MSITE-600] site plugin 3.0 does not permit a child to fully override parent
site deployment URL
* [MSITE-549] Not possible to easily customise footer
* [MSITE-402] Execution order of report plugins is arbitrary if inheritance is
involved
New Feature
* [MSITE-582] Make it possible to remove breadcrumbs in child projects again
Task
* [MSITE-641] Require Maven 2.2.1
* [MSITE-637] Upgrade to doxia-sitetools-1.3
* [MSITE-636] Upgrade to doxia-1.3
* [MSITE-627] Upgrade to reporting-exec 1.0.2
* [MSITE-625] Please add an 'archive' parameter to the 'jar' goal of the
'maven-site-plugin'.
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1331837 - in /maven/plugin-tools/branches/MPLUGIN-189: ./ maven-plugin-tools-annotations/ maven-plugin-tools-annotations/src/ maven-plugin-tools-annotations/src/main/ maven-plugin-too
+1 for your analysis
argument for command line argument: I understand the logic, I find it
better than expression effectively, but I'm not convinced that it is much
explicit.
I'm not convinced by value either: your analysis is perfectly right
property? system-property?
considering than when there is an expression that is not simply a reference to
a system property for command line definition, it's probably that it should
have been defined as default-value instead
has someone any experience of a real world use case where the value is not
simply ${a.system.property}?
And why not replace expression=${my.property} with system-
property=my.property? Which could generated the exact same plugin
descriptor, but would simply be a lot more explicit for developer writing his
annotation
Regards,
Hervé
Le mardi 1 mai 2012 19:53:37 Robert Scholte a écrit :
I don't know the numbers, but I'm assuming that 99 out of 100 times the
expression is filled with a command line argument.
I can imagine why the name 'expression' was used: it must contain exactly
one expression.
But that's from the technical perspective.
We've all seen the threads where users try to use the name of the
configuration-property name instead of the expression as argument for a
plugin.
The name 'expression' doesn't trigger the users.
From that perspective I hope that 'argument' is clearer.
I don't think that 'value' would be much better for users, but maybe it's
also a matter of improving the goal docs generation.
-Robert
Op Mon, 30 Apr 2012 22:19:14 +0200 schreef Hervé BOUTEMY
herve.bout...@free.fr:
probably a good occasion to improve usability
but I don't understand argument, even if I can't find any good
proposition
value? as opposed to default-value?
any other idea around?
Regards,
Hervé
Le lundi 30 avril 2012 09:31:27 Robert Scholte a écrit :
Hi,
expression has always caused a lot of confusion for plugin-users.
Should this be a moment to rename it to something like argument?
-Robert
Op Sat, 28 Apr 2012 23:23:11 +0200 schreef ol...@apache.org:
Author: olamy
Date: Sat Apr 28 21:23:10 2012
New Revision: 1331837
URL: http://svn.apache.org/viewvc?rev=1331837view=rev
Log:
[MPLUGIN-189] add java 5 annotations support to mark Mojo sources
-
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: svn commit: r1331837 - in /maven/plugin-tools/branches/MPLUGIN-189: ./ maven-plugin-tools-annotations/ maven-plugin-tools-annotations/src/ maven-plugin-tools-annotations/src/main/ maven-plugin-too
+1 if we could get rid of the ${ and }, because users are not interested
in the fact that this is resolved as an expression.
This should make it better to read too.
When I started with Maven I never had the feeling I was passing
system-properties, so I doubt that this is the right name.
I was passing something like goal-arguments...
-Robert
Op Tue, 01 May 2012 20:12:07 +0200 schreef Hervé BOUTEMY
herve.bout...@free.fr:
+1 for your analysis
argument for command line argument: I understand the logic, I find it
better than expression effectively, but I'm not convinced that it is
much
explicit.
I'm not convinced by value either: your analysis is perfectly right
property? system-property?
considering than when there is an expression that is not simply a
reference to
a system property for command line definition, it's probably that it
should
have been defined as default-value instead
has someone any experience of a real world use case where the value is
not
simply ${a.system.property}?
And why not replace expression=${my.property} with system-
property=my.property? Which could generated the exact same plugin
descriptor, but would simply be a lot more explicit for developer
writing his
annotation
Regards,
Hervé
Le mardi 1 mai 2012 19:53:37 Robert Scholte a écrit :
I don't know the numbers, but I'm assuming that 99 out of 100 times the
expression is filled with a command line argument.
I can imagine why the name 'expression' was used: it must contain
exactly
one expression.
But that's from the technical perspective.
We've all seen the threads where users try to use the name of the
configuration-property name instead of the expression as argument for a
plugin.
The name 'expression' doesn't trigger the users.
From that perspective I hope that 'argument' is clearer.
I don't think that 'value' would be much better for users, but maybe
it's
also a matter of improving the goal docs generation.
-Robert
Op Mon, 30 Apr 2012 22:19:14 +0200 schreef Hervé BOUTEMY
herve.bout...@free.fr:
probably a good occasion to improve usability
but I don't understand argument, even if I can't find any good
proposition
value? as opposed to default-value?
any other idea around?
Regards,
Hervé
Le lundi 30 avril 2012 09:31:27 Robert Scholte a écrit :
Hi,
expression has always caused a lot of confusion for plugin-users.
Should this be a moment to rename it to something like argument?
-Robert
Op Sat, 28 Apr 2012 23:23:11 +0200 schreef ol...@apache.org:
Author: olamy
Date: Sat Apr 28 21:23:10 2012
New Revision: 1331837
URL: http://svn.apache.org/viewvc?rev=1331837view=rev
Log:
[MPLUGIN-189] add java 5 annotations support to mark Mojo sources
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pushing plugin web site for release votes
today, I made great progress: as the scm commit may show, I updated m-scm- publish-p to import any content, and I just did such an import on existing content do m-doap-p versions 1.0 and 1.1 the result is an updated publish procedure [1], with some part still failing (I had to create the symlink manually through a Linux symlink: Windows users won't be able to do so). But the result is great, published in only a few seconds after the svn commit. It can be viewed at 4 places: - m-doap-p-latest [2] - m-doap-p-1.0 [3] - m-doap-p-1.1 [4] - m-doap-p [5] and tracked in svn [6] any feedback? Regards, Hervé [1] http://maventest.apache.org/developers/release/maven-plugin-release.html [2] http://maventest.apache.org/plugins/maven-doap-plugin-latest/ [3] http://maventest.apache.org/plugins/maven-doap-plugin1.0/ [4] http://maventest.apache.org/plugins/maven-doap-plugin-1.1/ [5] http://maventest.apache.org/plugins/maven-doap-plugin/ [6] https://svn.apache.org/repos/infra/websites/production/maventest/content/plugins/ Le samedi 28 avril 2012 03:41:16 Hervé BOUTEMY a écrit : for the moment, we didn't come to something yet what is missing is: 1. feedback about proposed procedure [1] 2. parent pom modification with m-site-scm-publish-p to match previous procedure 3. initial import help on 1 2 would be greatly appreciated And I'm looking into 3. Regards, Hervé [1] http://maventest.apache.org/developers/release/maven-plugin-release.html Le vendredi 27 avril 2012 09:27:12 Benson Margulies a écrit : I confess that I've been reading Hervé's emails with only half of an eye. Do I need to do anything CMS-y when staging a release of a plugin? - 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: svn commit: r1331837 - in /maven/plugin-tools/branches/MPLUGIN-189: ./ maven-plugin-tools-annotations/ maven-plugin-tools-annotations/src/ maven-plugin-tools-annotations/src/main/ maven-plugin-too
On Wed, May 2, 2012 at 7:40 AM, Robert Scholte apa...@sourcegrounds.comwrote:
+1 if we could get rid of the ${ and }, because users are not interested
in the fact that this is resolved as an expression.
This should make it better to read too.
When I started with Maven I never had the feeling I was passing
system-properties, so I doubt that this is the right name.
I was passing something like goal-arguments...
If a variable is not resolved from a pom, then settings, does it not then
come from (if available) from the system properties?
Is this not the order of preecedence?
-Chris
