Re: Assembly plugin duplicate file resolution
Wouldn't it make sense to fail the build in case of this instead? As I see it, there's something wrong in the descriptor and it should be fixed. Also, doing this change (intead of just altering the algorithm) would make the plugin upgrade better (no suprises in the result). A failed build with a good message instead. /Anders On Thu, Oct 30, 2014 at 12:57 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: There's a truckload of jira issues related to the inclusion algorithm, and there just seems to be so many simpler ways of handling this ? filesets/dependencysets/files processed in descriptor order (or reverse descriptor) order, first file wins. Reversing descriptor order would make last file win. Within a single set, first file always wins. What is the use case being solved by the existing algorithm ?? And why does it try to block based on input rather than assembly-output name ? Kristian 2014-10-30 12:54 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com: Reading the instructions on http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html makes me wonder, why on earth has this precedence been chosen for the assembly plugin ??? Especially case 2 is odd. There' - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Get hold of MavenProject object of a module in a multi-module build
I'm trying to create a unit test for MSHARED-361, but I can't figure out how I get hold of the MavenProject object of one of the modules in a multi-module build. Anyone with a pointer or a hint on where this is done in some other unit test? /Anders
Re: Get hold of MavenProject object of a module in a multi-module build
Well, I want a simple way to get a MavenProject object with artifact dependencies which consist of folder(s) instead of a jar. I probably could mock this, but I was thinking having a multimodule project on disk and then build it and get hold of one of the modules (which has a dependency to one of the other modules) would be the easiest way. Unfortunately, maven-plugin-testing-harness v3.1.0 (where readMavenProject was added) is too high of a Java version for the shared liv I'm working on. :-( But I could probably borrow the code... /Anders On Wed, Oct 29, 2014 at 3:49 PM, Igor Fedorenko i...@ifedorenko.com wrote: You can also use MojoRule#readMavenProject from maven-plugin-testing-harness [1]. You'd have to inject any cross-module dependencies manually. You can also see how we do this in Tycho [2], where we delegate to DefaultMaven to read and resolve multimodule project. And, of course, you can just create MavenProject instance and populate it with relevant data. Really depends on what you actually need to do. [1] https://git-wip-us.apache.org/repos/asf?p=maven-plugin- testing.git;a=blob;f=maven-plugin-testing-harness/src/ main/java/org/apache/maven/plugin/testing/MojoRule.java;h= d4d57f0ca2295a60032984d31680815364c8f805;hb=5f2f3a23b62bf1cc2465c94b173700 ee557edc5a [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-testing-harness/src/main/java/org/eclipse/tycho/testing/ AbstractTychoMojoTestCase.java -- Regards, Igor On 2014-10-29, 10:09, Anders Hammar wrote: I'm trying to create a unit test for MSHARED-361, but I can't figure out how I get hold of the MavenProject object of one of the modules in a multi-module build. Anyone with a pointer or a hint on where this is done in some other unit test? /Anders - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get hold of MavenProject object of a module in a multi-module build
Unfortunately, maven-plugin-testing-harness v3.1.0 (where readMavenProject was added) is too high of a Java version for the shared liv I'm working on. :-( But I could probably borrow the code... Turns out I can't do that. That code uses the ProjectBuilder class which is not available in Maven 2.x. /Anders /Anders On Wed, Oct 29, 2014 at 3:49 PM, Igor Fedorenko i...@ifedorenko.com wrote: You can also use MojoRule#readMavenProject from maven-plugin-testing-harness [1]. You'd have to inject any cross-module dependencies manually. You can also see how we do this in Tycho [2], where we delegate to DefaultMaven to read and resolve multimodule project. And, of course, you can just create MavenProject instance and populate it with relevant data. Really depends on what you actually need to do. [1] https://git-wip-us.apache.org/repos/asf?p=maven-plugin- testing.git;a=blob;f=maven-plugin-testing-harness/src/ main/java/org/apache/maven/plugin/testing/MojoRule.java;h= d4d57f0ca2295a60032984d31680815364c8f805;hb= 5f2f3a23b62bf1cc2465c94b173700ee557edc5a [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-testing-harness/src/main/java/org/eclipse/tycho/testing/ AbstractTychoMojoTestCase.java -- Regards, Igor On 2014-10-29, 10:09, Anders Hammar wrote: I'm trying to create a unit test for MSHARED-361, but I can't figure out how I get hold of the MavenProject object of one of the modules in a multi-module build. Anyone with a pointer or a hint on where this is done in some other unit test? /Anders - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get hold of MavenProject object of a module in a multi-module build
I would conclude not to use Maven 2 from that ;-) Well, not an option for maven-shared libs. (at least not yet) /Anders Anders Hammar wrote on 29.10.2014 08:18: Unfortunately, maven-plugin-testing-harness v3.1.0 (where readMavenProject was added) is too high of a Java version for the shared liv I'm working on. :-( But I could probably borrow the code... Turns out I can't do that. That code uses the ProjectBuilder class which is not available in Maven 2.x. /Anders /Anders On Wed, Oct 29, 2014 at 3:49 PM, Igor Fedorenko i...@ifedorenko.com wrote: You can also use MojoRule#readMavenProject from maven-plugin-testing-harness [1]. You'd have to inject any cross-module dependencies manually. You can also see how we do this in Tycho [2], where we delegate to DefaultMaven to read and resolve multimodule project. And, of course, you can just create MavenProject instance and populate it with relevant data. Really depends on what you actually need to do. [1] https://git-wip-us.apache.org/repos/asf?p=maven-plugin- testing.git;a=blob;f=maven-plugin-testing-harness/src/ main/java/org/apache/maven/plugin/testing/MojoRule.java;h= d4d57f0ca2295a60032984d31680815364c8f805;hb= 5f2f3a23b62bf1cc2465c94b173700ee557edc5a [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-testing-harness/src/main/java/org/eclipse/tycho/testing/ AbstractTychoMojoTestCase.java -- Regards, Igor On 2014-10-29, 10:09, Anders Hammar wrote: I'm trying to create a unit test for MSHARED-361, but I can't figure out how I get hold of the MavenProject object of one of the modules in a multi-module build. Anyone with a pointer or a hint on where this is done in some other unit test? /Anders - 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 Archiver version 2.6
+1 non-binding Regression testing performed by upgrading dependency and executing ITs of * maven-assembly-plugin * maven-ear-plugin * maven-jar-plugin * maven-war-plugin /Anders /Anders On Wed, Oct 29, 2014 at 8:16 PM, Michael Osipov micha...@apache.org wrote: Am 2014-10-26 um 22:06 schrieb Michael Osipov: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa? version=18325projectId=11761 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql= project%20%3D%20MSHARED%20AND%20resolution%20%3D% 20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven- 1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2. 6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. I'll keep the vote another day open because of the interruption in service of RAO. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: Ease the usage of Failsafe
The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: I have always used surefire for integration tests with a Maven profile (to activate them on demand since they are time consuming). What benefit am I missing not using failsafe? Cheers, Paul On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer mails...@swe-blog.net wrote: Hi, I see a lot of people using *Surefire for intergation tests instead of Failsafe*. I think the reason for this is that *Failsafe* is from my perspective is *not integrated* in Maven *as is possible*. While unittest (*Test.java) are executed if we place them in |src/test/java| for integrationtests we have to add |build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution phaseintegration-test/phase goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build | Why is is not possible to integrate Failsafe in the same convenient way as Surefire. I prepared a small example project you can checkout via Git |git clone https://bitbucket.org/obfischer/bugreport-maven-failsafe.git | Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. Oliver
Re: [ANN] Apache Maven Assembly Plugin 2.5 Released
Kristian, The plugin's site says v2.6-SNAPSHOT. /Anders On Mon, Oct 27, 2014 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: The Apache Maven team is pleased to announce the release of the long-awaited Apache Maven Assembly Plugin, version 2.5. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Notable in this release is improved file attribute support and full symlink support for java7+ users. Users of filtering/line ending selection should also notice a nice performance improvement. A large number of bugs have also been fixed. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5 ** Bug * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file mode nor uid/gid * [MASSEMBLY-458] - Directory name resolution ignores $ and beyond * [MASSEMBLY-495] - Assembly changes timestamps when extracting dependency sets * [MASSEMBLY-523] - Filtering causes a loss of original unix file permissions * [MASSEMBLY-543] - japanese filenames cannot be correctly assembled by maven-assembly-plugin * [MASSEMBLY-557] - Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted * [MASSEMBLY-563] - JAR entry not found when including jar dependencies with # in classname * [MASSEMBLY-576] - addClasspath broken in new single goal * [MASSEMBLY-605] - Filtering does not work on files which are symlinks * [MASSEMBLY-615] - assembly:single fails with odd resource file name * [MASSEMBLY-622] - Unable to create TAR artifacts * [MASSEMBLY-641] - Assembly fails on resource name with a percent character * [MASSEMBLY-661] - Assembly plugin looses permissions when using fileSets * [MASSEMBLY-670] - Specifying lineEnding option of fileSet causes timestamps not to be preserved * [MASSEMBLY-684] - Parallel Execution w Custom Assembly Descriptor Fails * [MASSEMBLY-692] - Assembly ID is global * [MASSEMBLY-709] - When assembling a zip on windows duplicate files are added to the assembly * [MASSEMBLY-721] - Failing ITs for Maven 2.2.1 ** Improvement * [MASSEMBLY-479] - Add option to generate Posix tar files. * [MASSEMBLY-530] - Allow configuration of encoding * [MASSEMBLY-638] - [PATCH] Support tgz and tbz2 formats in assemblies * [MASSEMBLY-673] - Add support for delimiters and useDefaultDelimiters like the maven-resources-plugin 2.4 has * [MASSEMBLY-688] - Use maven-invoker-plugin 1.9 * [MASSEMBLY-705] - Removed compatibility with Maven 2.0.X * [MASSEMBLY-706] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MASSEMBLY-707] - Remove unnecessary excludes / Cleaning up console output * [MASSEMBLY-710] - Fix RAT Report * [MASSEMBLY-712] - Update version of plexus-archiver to 2.5 * [MASSEMBLY-714] - Update version of plexus-archiver to 2.7.1 * [MASSEMBLY-716] - Update plexus-io from 2.0.9 to 2.3.2 * [MASSEMBLY-719] - Ugrade to plexus-interpolation 1.21 ** New Feature * [MASSEMBLY-717] - Add an option to turn off project filters ** Wish * [MASSEMBLY-343] - add symbolic links managment (java7+ only supported) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Apache Maven Assembly Plugin 2.5 Released
Also, the plugins index page is not updated with the new version. /Anders On Mon, Oct 27, 2014 at 7:34 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Yeah I just saw that, I'm working on it... ;) K 2014-10-27 7:31 GMT+01:00 Anders Hammar and...@hammar.net: Kristian, The plugin's site says v2.6-SNAPSHOT. /Anders On Mon, Oct 27, 2014 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: The Apache Maven team is pleased to announce the release of the long-awaited Apache Maven Assembly Plugin, version 2.5. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Notable in this release is improved file attribute support and full symlink support for java7+ users. Users of filtering/line ending selection should also notice a nice performance improvement. A large number of bugs have also been fixed. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5 ** Bug * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file mode nor uid/gid * [MASSEMBLY-458] - Directory name resolution ignores $ and beyond * [MASSEMBLY-495] - Assembly changes timestamps when extracting dependency sets * [MASSEMBLY-523] - Filtering causes a loss of original unix file permissions * [MASSEMBLY-543] - japanese filenames cannot be correctly assembled by maven-assembly-plugin * [MASSEMBLY-557] - Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted * [MASSEMBLY-563] - JAR entry not found when including jar dependencies with # in classname * [MASSEMBLY-576] - addClasspath broken in new single goal * [MASSEMBLY-605] - Filtering does not work on files which are symlinks * [MASSEMBLY-615] - assembly:single fails with odd resource file name * [MASSEMBLY-622] - Unable to create TAR artifacts * [MASSEMBLY-641] - Assembly fails on resource name with a percent character * [MASSEMBLY-661] - Assembly plugin looses permissions when using fileSets * [MASSEMBLY-670] - Specifying lineEnding option of fileSet causes timestamps not to be preserved * [MASSEMBLY-684] - Parallel Execution w Custom Assembly Descriptor Fails * [MASSEMBLY-692] - Assembly ID is global * [MASSEMBLY-709] - When assembling a zip on windows duplicate files are added to the assembly * [MASSEMBLY-721] - Failing ITs for Maven 2.2.1 ** Improvement * [MASSEMBLY-479] - Add option to generate Posix tar files. * [MASSEMBLY-530] - Allow configuration of encoding * [MASSEMBLY-638] - [PATCH] Support tgz and tbz2 formats in assemblies * [MASSEMBLY-673] - Add support for delimiters and useDefaultDelimiters like the maven-resources-plugin 2.4 has * [MASSEMBLY-688] - Use maven-invoker-plugin 1.9 * [MASSEMBLY-705] - Removed compatibility with Maven 2.0.X * [MASSEMBLY-706] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MASSEMBLY-707] - Remove unnecessary excludes / Cleaning up console output * [MASSEMBLY-710] - Fix RAT Report * [MASSEMBLY-712] - Update version of plexus-archiver to 2.5 * [MASSEMBLY-714] - Update version of plexus-archiver to 2.7.1 * [MASSEMBLY-716] - Update plexus-io from 2.0.9 to 2.3.2 * [MASSEMBLY-719] - Ugrade to plexus-interpolation 1.21 ** New Feature * [MASSEMBLY-717] - Add an option to turn off project filters ** Wish * [MASSEMBLY-343] - add symbolic links managment (java7+ only supported) Enjoy, -The Apache Maven team - 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: Next Maven prerequisite for Maven Plugins
this is the only change for 3.0.5: http://maven.apache.org/security.html bottom line: certificates are not checked. It's a serious security issue and for that reason I'd prefer 3.0.5 over 3.0.4 Security issue or not, there are commercial IDEs out there (used by larger companies) that include m2e 1.4.x or earlier, which is based on Maven 3.0.4. Do we really want to disqualify those users? /Anders thanks, Robert Op Mon, 13 Oct 2014 07:48:11 +0200 schreef Anders Hammar and...@hammar.net: Personally I have a problem with a Maven 3.0.5 requirement. The reason is that there are IDEs out there that is based on Maven 3.0.4. Also, IIRC there was just a very minor (code wise) difference between Maven 3.0.5 and 3.0.4, so requiring 3.0.5 (instead of 3.0.4) wouldn't give us much. Having said that, I'm in favor of moving to a Maven 3.0 requirement. And making that a 3.0.4 requirement is fine with me. /Anders On Sun, Oct 12, 2014 at 3:25 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Robert, from my point of view minimum to 3.0.5 ...nothing below...afterwards 3.1.1.and then 3.2.1...the latest releases from the appropriate release lines 3.0.X, 3.1.X, 3.2.X, I wouldn't go to 3.1.0 at the moment cause that could be confusingfrom user point of view...than there is a gap... 2.2.1 3.1.1 From my side... Kind regards Karl Heinz Marbaise Hi, Right now we change the Maven prerequisite to 2.2.1 and I noticed some new issues which already want to move it forward to 3.0.4. I wonder why to move to this version. Most (API-)changes have been introduced with the 3.0 alpha and beta releases. I don't think that the other 3.0.x releases provide that much more changes. So I would say that changing the required Maven version would be 3.0. *If* we want to force users not to use 3.0.4 due to the CVE-2013-0253, we should say that 3.0.5 is the next required version of Maven. And I could go one step further: if we want to get rid of the compatibility overhead for Aether (Sonatype versus Eclipse) we should change it to 3.1.0 So I'd prefer to move forward to 3.0, maybe even to 3.1.0, but not to 3.0.4 unless there are better reasons then I mentioned above. Any other opinions? thanks, Robert Kind regards Karl Heinz Marbaise - 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: Next Maven prerequisite for Maven Plugins
Personally I have a problem with a Maven 3.0.5 requirement. The reason is that there are IDEs out there that is based on Maven 3.0.4. Also, IIRC there was just a very minor (code wise) difference between Maven 3.0.5 and 3.0.4, so requiring 3.0.5 (instead of 3.0.4) wouldn't give us much. Having said that, I'm in favor of moving to a Maven 3.0 requirement. And making that a 3.0.4 requirement is fine with me. /Anders On Sun, Oct 12, 2014 at 3:25 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Robert, from my point of view minimum to 3.0.5 ...nothing below...afterwards 3.1.1.and then 3.2.1...the latest releases from the appropriate release lines 3.0.X, 3.1.X, 3.2.X, I wouldn't go to 3.1.0 at the moment cause that could be confusingfrom user point of view...than there is a gap... 2.2.1 3.1.1 From my side... Kind regards Karl Heinz Marbaise Hi, Right now we change the Maven prerequisite to 2.2.1 and I noticed some new issues which already want to move it forward to 3.0.4. I wonder why to move to this version. Most (API-)changes have been introduced with the 3.0 alpha and beta releases. I don't think that the other 3.0.x releases provide that much more changes. So I would say that changing the required Maven version would be 3.0. *If* we want to force users not to use 3.0.4 due to the CVE-2013-0253, we should say that 3.0.5 is the next required version of Maven. And I could go one step further: if we want to get rid of the compatibility overhead for Aether (Sonatype versus Eclipse) we should change it to 3.1.0 So I'd prefer to move forward to 3.0, maybe even to 3.1.0, but not to 3.0.4 unless there are better reasons then I mentioned above. Any other opinions? thanks, Robert Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Zip file default encoding
As this is a step towards reproducable builds I see this as a good thing. Depending on platform defaults should be punished...:-) /Anders On Fri, Oct 10, 2014 at 8:26 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Currently plexus-archiver uses platform encoding for zip file names if none is specified. This is compliant with traditional Zip history. But zip understood this is a problem and introduced a LEF flag, which basically means all entries must be UTF-8. I would like to switch defaults in plexus zip archiver; make it *disregard* platform encoding and always output utf8 + LEF, unless a different encoding has been explicitly specified. In consequence this would make zip behave like jar does; always default to the well-defined UTF-8 + LEF standard. This will break builds for people that actually *want* archives in file.encoding; they will need to explicitly specify encoding to get that encoding. To my understanding this is not really an issue, LEF support is ancient history. Opinions ? Kristian - 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.10.1
me too. :-) /Anders On Mon, Sep 29, 2014 at 8:55 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I moved the fix to 2.11. Kristian 2014-09-29 8:50 GMT+02:00 Mikolaj Izdebski mizde...@redhat.com: On 09/27/2014 04:34 PM, Michael Osipov wrote: We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11138version=20644 MJAVADOC-415 is not fixed. POM still seems to declare versions 2.5 of both maven-archiver and plexus-archiver. Plexus-utils is at 3.0.15, not 3.0.18. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk - 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: [DISCUSS] Move everything to 1.6
1.6 is fine by me. Working actively with a customer using IBM's JDK 1.6, which is still supported by IBM, will make me vote -1 on a move to 1.7 currently. /Anders On Sat, Sep 27, 2014 at 8:01 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Kristian, On 9/27/14 7:23 PM, Kristian Rosenvold wrote: We moved core to 1.6 some time ago. As far as i know starting with Maven 3.2.1...was the first one... Time to move everything else as well ? We have at the moment a large number of plugins which have minimum Maven 2.2.1 (JDK 1.5)...and few are currently at Maven 2.0.6 (that's only for a limited amount of time) The next round should be to lift up to Maven 3.0.5 at minimum which implies to left Maven 2 finally behind. Making it visible to people by using 3.X versions for the plugins or something similar... ...afterwards i see the next round to lift up to Maven 3.1.1... and after that i see the next lift up to Maven 3.2.1 which implies Java 1.6...and so on It's a longer way...which takes time... Kristian (Who's ready to say 1.7 but we stop by 1.6 first :) If we go the above path it's of course longer but more consistence from the user point of view...using Maven 3.0.5 which works with Java 1.5 ...and the plugins as well...etc... Of course from the technical point of view it's not that good ;-(... So from my site i would vote with +0 ... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Parent POM version 15
Is it safe/good to upgrade to m-javadoc-p v2.10, as there has been several reported issues [1] [2] [3]? We don't want to cause a lot of issues for apache projects. [1] http://jira.codehaus.org/i#browse/MJAVADOC-407 [2] http://jira.codehaus.org/i#browse/MJAVADOC-408 [3] http://stackoverflow.com/questions/25983852/maven-javadoc-plugin-breaks-mvn-releaseperform/25986409#25986409 /Anders On Mon, Sep 22, 2014 at 11:27 PM, Benson Margulies bimargul...@gmail.com wrote: Hi, Here is release 15 of the POM we maintain for the entire ASF. The changes since release 14 can be seen here: http://svn.apache.org/viewvc/maven/pom/tags/apache-15/pom.xml?r1=HEADr2=1575044diff_format=h Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1001 Source Release: http://repository.apache.org/content/repositories/orgapacheapache-1001/org/apache/apache/15/apache-15-source-release.zip Source release checksum(s): apache-15-source-release.zip sha1: 22df76d47cdfdb7ec26ffa5d7b1bd9337e2b77e9 Staging site: http://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Parent POM version 15
My view is that we should soak plugin updates in the Maven project pom for at least 5 releases or 1 month (whichever is sooner) before promoting up to the ASF parent. I agree and that's why I asked about m-javadoc-p v2.10 which was just recently released and it seems as it has cause some issues for people. Should we really include that one? I state my -1 here, non-binding. I'd be happy to revert that if someone explains that the issues are purely due to user misconfiguration or similar. /Anders In the case of GIT I am happy to make an exception as it can block others from releasing... On 23 September 2014 11:25, Benson Margulies bimargul...@gmail.com wrote: I guess I am conservative about this pom; it's not very hard for anyone who wants a newer version of something to configure it, and if I start respinning some other plugin will go release itself in the middle. If folks really want things in here, perhaps the plugin release procedure should include a note to update this pom with the new version. On Tue, Sep 23, 2014 at 6:04 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 on these changes... you could go further... but if you are only prepared to bite off that much right now it is better than nothing! On 22 September 2014 22:27, Benson Margulies bimargul...@gmail.com wrote: Hi, Here is release 15 of the POM we maintain for the entire ASF. The changes since release 14 can be seen here: http://svn.apache.org/viewvc/maven/pom/tags/apache-15/pom.xml?r1=HEADr2=1575044diff_format=h Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1001 Source Release: http://repository.apache.org/content/repositories/orgapacheapache-1001/org/apache/apache/15/apache-15-source-release.zip Source release checksum(s): apache-15-source-release.zip sha1: 22df76d47cdfdb7ec26ffa5d7b1bd9337e2b77e9 Staging site: http://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +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: java_home detection bug in maven 3.2.3
To file a ticket at jira.c.o, you first need to create an account at http://xircles.codehaus.org/. Please file this bug report to make sure it gets handled. /Anders On Thu, Sep 18, 2014 at 9:31 AM, Ye Xianjin advance...@gmail.com wrote: Hi, Developers: I found this bug today on Mac OS X 10.10. Maven version: 3.2.3 File path: apache-maven-3.2.3/apache-maven/src/bin/mvn line86 Code snippet: if [[ -z $JAVA_HOME -x /usr/libexec/java_home ]] ; then # # Apple JDKs # export JAVA_HOME=/usr/libexec/java_home fi It should be : if [[ -z $JAVA_HOME -x /usr/libexec/java_home ]] ; then # # Apple JDKs # export JAVA_HOME=`/usr/libexec/java_home` fi I wanted to file a jira to http://jira.codehaus.org ( http://jira.codehaus.org/). But it seems it's not open for registration. So I think maybe it's a good idea to send an email here. -- Ye Xianjin Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
Re: Plexus Archiver / Plexus Components
When/if we move these components I assume they will get a new groupId? Will that not cause issues with duplicated plexus libraries (due to two different sets of GA) until everything has moved over to the new dependencies? /Anders On Thu, Sep 11, 2014 at 8:10 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: to me, it's clear we need some formal attribution to ASF from each major contributor, since the code was committed to Codehaus, not ASF, and Codehaus is not an antity that can transfer the result to ASF for the formal part, without being a lawyer, I suppose each constributor has to confirm he is the author of the code and that he gives the code to ASF: I'll start a new thread on the ML, asking for every contributor to reply. I need your help, my frenglish comes short for the invitation, please send me proposals in private so I can add every good idea without polluting the ML :) for the notion of major contributor, we have 13 components each with its own contributor list: we'll see which components are fully covered, then can be moved easily immediately, and which ones will need more legal advice Let's keep up the good work together: not sure we'll get 100% success, but we can't completely fail and the situation will be improved even if not perfect. Regards, Hervé Le lundi 8 septembre 2014 20:38:27 Benson Margulies a écrit : On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: here is the new version with csv files and committers deduplicate http://people.apache.org/~hboutemy/codehaus/summary.html now we need to ask for everybody's attribution of his contributions, and we'll see how much we cover from each component some components should be easy to cover fully, like plexus-cli some will be harder... to start, I'm ready to give ASF all my contributions: how should I proceed? some formal e-mail on this ML? Yes, mail to this list contributing your contributions to that repo to the project. Regards, Hervé Le dimanche 7 septembre 2014 23:22:39 Hervé BOUTEMY a écrit : improved the automatic summary http://people.apache.org/~hboutemy/codehaus/summary.html I suppose the next step will be to create a csv to be able to work on figures with a spreadsheet I have no time at the moment, will try tomorrow if nobody beats me Regards, Hervé Le dimanche 7 septembre 2014 15:01:58 Benson Margulies a écrit : On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: But I still assume we need to get some kind of idea of how good is good enough. At some point there's going to be a significant contributor we won't be able to get hold of. We might be able to work around this by removing code or similar, but I don't think there is any point in starting a massive search for people if 100% is the only permitted result. Is there any way we could get some idea of what kind of requirement we'd be facing ? Can we acceptably simply delete contributions from people we can't get hold of (that may work in some cases) ? We usually operate on a 200 line quota for requiring a CLA; can we disregard people with smaller contributions ? (And if so, would that be *total* 200 lines or per submission ...?) Yes, you can open a JIRA at LEGAL, and/or communicate with the board. I recommend completing the survey first. No one there likes to answer hypothetical questions; having an actual set of facts will grossly improve the conversation. Kristian 2014-09-07 1:01 GMT+02:00 Jason van Zyl ja...@takari.io: Cool, with your tool can you aggregate that into a single list of userIds/Names and then remove us. I recognize most of the non-us and with that list we can contact them all at once if we want. On Sep 6, 2014, at 5:05 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: here are more accurate statistics: http://people.apache.org/~hboutemy/codehaus Le samedi 6 septembre 2014 09:39:20 Hervé BOUTEMY a écrit : I satrted to write down the count of contributors done by github, with link, on https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies I'm not sure figures are relevant: - missing contributions? it seems so, I looked at plexus-velocity and older commits are not counted... - every contribution has to be taken into account? we'll probably need to do more manual work: will need to dispatch components to avoid one to do the work for everything then we'll need to figure out the process details: I read http://incubator.apache.org/ip-clearance/index.html, I suppose I'll have as Maven
Re: [VOTE] Release Apache Maven Invoker Plugin version 1.8.1
Sounds more as a version 1.9 to me than a bug fix. It contains new features and improvements. /Anders (mobile) Den 27 jun 2014 22:57 skrev Karl Heinz Marbaise khmarba...@gmx.de: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11441version=18996 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D% 20MINVOKER%20AND%20status%20%3D%20Open%20ORDER%20BY%20key% 20DESC%2C%20priority%20DESC Staging repo: ttps://repository.apache.org/content/repositories/maven-1029 ttps://repository.apache.org/content/repositories/maven- 1029/org/apache/maven/plugins/maven-invoker-plugin/1.8.1/ maven-invoker-plugin-1.8.1-source-release.zip Source release checksum(s): maven-invoker-plugin-1.8.1-source-release.zip sha1: ff92ff4ff07264f6dfd67810ec6edb955962d2b1 Staging site: http://maven.apache.org/plugins-archives/maven-invoker-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven site - Page Not Found
Please remember that there are links in the Readme file of the distro as well! Those should continue to work for released releases. /Anders (mobile) Den 28 jun 2014 04:26 skrev Jason van Zyl ja...@takari.io: I'll fix the rest of it tonight/tomorrow. Most of the release notes are not really release notes. It's all boiler plate cut/paste with some more more cut/paste from JIRA inside. Where there is no real content in the release notes I'll erase the file completely and provide the link to JIRA for the issue summary. For the releases that have actual release notes I'll extract them into their respective files and link them all together in one page. I'm tired of touching and fiddling with 10 files in conjunction with cutting a core release. On Jun 27, 2014, at 9:51 PM, Jason van Zyl ja...@takari.io wrote: I had two changes here locally I just committed. On Jun 27, 2014, at 5:46 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, i've detected that the current Maven site (http://maven.apache.org/) is broken at several areas like: http://maven.apache.org/docs/3.0.5/release-notes.html http://maven.apache.org/docs/3.1.1/release-notes.html http://maven.apache.org/docs/3.1.0/release-notes.html ... http://maven.apache.org/release-notes-all.html ... I will undo the change of Jason which deleted several pages r1605754 | jvanzyl | 2014-06-26 14:11:58 +0200 (Thu, 26 Jun 2014) | 1 line to restore the earlier stage to get a working pageback... cause currently the page has many Page not founds which is not really good sign... This is only a temporarily solution afterwards we should clean up the pages step by step... Kind regards Karl-Heinz Marbaise - 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/takari_io - 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) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: [VOTE] Release Apache Maven Invoker Plugin version 1.8.1
It's up to you as the release manager. But I would prefer it to be v1.9. /Anders (mobile) Den 28 jun 2014 10:46 skrev Karl Heinz Marbaise khmarba...@gmx.de: Hi Anders, Sounds more as a version 1.9 to me than a bug fix. It contains new features and improvements. Unfortunately you are right... So should i drop the vote and restart as 1.9 ... Kind regards Karl-Heinz Den 27 jun 2014 22:57 skrev Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de: Hi, We solved 6 issues: http://jira.codehaus.org/__secure/ReleaseNote.jspa?__ projectId=11441version=18996 http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11441version=18996 There are still a couple of issues left in JIRA: http://jira.codehaus.org/__issues/?jql=project%20%3D%__ 20MINVOKER%20AND%20status%20%__3D%20Open%20ORDER%20BY%20key% __20DESC%2C%20priority%20DESC http://jira.codehaus.org/issues/?jql=project%20%3D% 20MINVOKER%20AND%20status%20%3D%20Open%20ORDER%20BY%20key% 20DESC%2C%20priority%20DESC Staging repo: ttps://repository.apache.org/__content/repositories/maven-__1029 http://repository.apache.org/content/repositories/maven-1029 ttps://repository.apache.org/__content/repositories/maven-__ 1029/org/apache/maven/plugins/__maven-invoker-plugin/1.8.1/_ _maven-invoker-plugin-1.8.1-__source-release.zip http://repository.apache.org/content/repositories/maven- 1029/org/apache/maven/plugins/maven-invoker-plugin/1.8.1/ maven-invoker-plugin-1.8.1-source-release.zip Source release checksum(s): maven-invoker-plugin-1.8.1-__source-release.zip sha1: ff92ff4ff07264f6dfd67810ec6edb__955962d2b1 Staging site: http://maven.apache.org/__plugins-archives/maven-__ invoker-plugin-LATEST/ http://maven.apache.org/plugins-archives/maven- invoker-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/__guides/development/guide-__ testing-releases.html http://maven.apache.org/guides/development/guide- testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1
Re: Thoughts on MNG-3522
Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - 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: Thoughts on MNG-3522
Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Sorry, my bad. I meant the binding in the child to be BEFORE the one on the parent. I can't alter the declaration in the parent in my scenario as I'm not on control of it. /Anders (mobile) Den 12 jun 2014 22:19 skrev Anders Hammar and...@hammar.net: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Not able to download artifact java-ee-apis from com.ibm.websphere
This type of question should be addressed to the user mailing list. This dev list is for the development of Maven itself. /Anders On Mon, Apr 28, 2014 at 10:22 AM, suhaslonarkar suhaslonar...@gmail.comwrote: Hi Team, I am having trouble to download artifact java-ee-apis from from com.ibm.websphere. Current dependency I have added dependency groupIdcom.ibm.websphere/groupId artifactIdjava-ee-apis/artifactId /dependency Then to resolve this issue I have added below dependency. dependency groupIdjavax/groupId artifactIdjavaee-api/artifactId version6.0/version /dependency After adding above dependencies build was successfully created and EAR also but its my feeling that like I have replaced com.ibm.websphere dependency with javax ...will it make difference in prod? will it conflict? What is recommended fix for this ? Please help me on this :) -- View this message in context: http://maven.40175.n5.nabble.com/Not-able-to-download-artifact-java-ee-apis-from-com-ibm-websphere-tp5792082.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
I believe he's talking about what's mentioned here (see the asterix): http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope /Anders On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid lennart.jore...@gmail.comwrote: I don't understand the difference between what you suggest here, Mark, and simply disabling transitive dependencies. Could you elaborate somewhat? 2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com: On 7 Apr 2014, at 12:32, Benson Margulies wrote: We then have other logical classpaths. . Something like javadoc should be able to define another named classpath structure; combining the dependencies of the plugin's implementation with dynamic code (doclets, whatever) seems like a category confusion to me. If we change/break this - can we PLEASE make the compilation path IGNORE transitive dependencies of 'compile' dependencies - if I -need- it to compile, -I- should depend on it up front. Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | 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 +==+
Re: Mixins as an aspect-oriented DRY tool
Here's the wiki page covering Maven 4: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 /Anders On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch alexan...@kriegisch.name wrote: Dear developers, I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable. Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority. With kind regards -- Alexander Kriegisch - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mixins as an aspect-oriented DRY tool
It's discussion right now and I don't think there has been any actaul work (other than possibly some private PoC). And it will be done when it's done. :-) /Anders On Tue, Apr 1, 2014 at 11:51 AM, Alexander Kriegisch alexan...@kriegisch.name wrote: Thanks Anders, so part of my question is answered: prio is major (like most other tickets on that target version) and there is a ticket for it. I have a few remaining issues though: - All links to related tickets are broken, they just point back to the wiki page itself. - There is no release schedule (e.g. a rough date estimate for version 4). Should I assume that it's done when it's done? - Is v4 being worked on already or is in the conceptual stage? - If I want to offer help testing mixin prototypes/betas, how do I learn when/how to contribute? Regards -- Alexander Kriegisch Anders Hammar schrieb am 01.04.2014 10:53: Here's the wiki page covering Maven 4: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 /Anders On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch alexan...@kriegisch.name wrote: Dear developers, I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable. Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority. With kind regards -- Alexander Kriegisch - 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: Operating system requirement
Handled in ticket MNG-5610. /Anders On Fri, Mar 28, 2014 at 4:47 PM, sebb seb...@gmail.com wrote: On 28 March 2014 12:09, Anders Hammar and...@hammar.net wrote: The requirements also says: Disk No minimum requirement. Approximately 100MB will be used for your local repository, however this will vary depending on usage ... AFAICT there _is_ a minimum requirement which is needed to store a basic set of plugins. And of course there is the Maven application itself, though that is tiny (under 6Mb for 3.0.5) 100MB is quite a small repository; they can easily grow to 1GB or more. So you think we should change to for example: Approximately 10MB is required for the Maven installation itself. In addition to that, additional disk space will be used for your local Maven repository. The size of your local repository will vary depending on usage but calculate for at least 500MB. Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is even smaller. Stating approx 10MB will give us some space. My local repo is 1.5GB so I'm guessing an average dev would need at least 500MB. ok? +1 /Anders /Anders [1] http://maven.apache.org/download.cgi#Requirements - 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: retirement of maven-reactor-plugin
Remove it from the Apache repo before it is synced to central? Not sure who has the privs to do that though. /Anders (mobile) Den 30 mar 2014 16:59 skrev Karl Heinz Marbaise khmarba...@gmx.de: Hi i made mistake during the retiring of the plugin, i have created a final release of that plugin, deployed it into the staging repository and CLOSED and RELEASED the staging repository without a vote here on the list ? which means something is going into Maven Central without a valid vote... Is there something i can do? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Operating system requirement
This is what I ended up writing in there: Approximately 10MB is required for the Maven installation itself. In addition to that, additional disk space will be used for your local Maven repository. The size of your local repository will vary depending on usage but expect at least 500MB. If you think it should be worded differently, please add that to the ticket! /Anders On Sun, Mar 30, 2014 at 7:54 PM, Fred Cooke fred.co...@gmail.com wrote: A minimum is just that, a minimum! My repo is 600 meg, but I have a stack of *dependencies* in there... A minimum should not include *user* dependency guesswork, it should only include what a default hello-world project with NO deps outside the default near-empty pom produces when run through most or all of the phases and goals. Someone start with nothing and build such a project in N ways until there are none left, then du -hs ~/.m2 and see what you get. Calling it the 500 because that's what an average dev might have (with or without snapshots?) is silly, however warning in appropriate words that in real-world use it will probably reach half a gig, and often reach as much as 2 gig, is useful. Maven by nature and by design is incomplete, calling the minimum 5 is an equal sin. Only once maven has downloaded itself is it reasonable to state a minimum. Additionally, all of the above is misleading, it's actually more like this: min usable/used size = maven + (numUsers * pluginsAndTheirDeps)... which for a single user simplifies out to maven + pluginsAndTheirDeps ~= 100? Too much said, but the inaccuracy in this thread was too much, also. On Sun, Mar 30, 2014 at 10:31 PM, Anders Hammar and...@hammar.net wrote: Handled in ticket MNG-5610. /Anders On Fri, Mar 28, 2014 at 4:47 PM, sebb seb...@gmail.com wrote: On 28 March 2014 12:09, Anders Hammar and...@hammar.net wrote: The requirements also says: Disk No minimum requirement. Approximately 100MB will be used for your local repository, however this will vary depending on usage ... AFAICT there _is_ a minimum requirement which is needed to store a basic set of plugins. And of course there is the Maven application itself, though that is tiny (under 6Mb for 3.0.5) 100MB is quite a small repository; they can easily grow to 1GB or more. So you think we should change to for example: Approximately 10MB is required for the Maven installation itself. In addition to that, additional disk space will be used for your local Maven repository. The size of your local repository will vary depending on usage but calculate for at least 500MB. Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is even smaller. Stating approx 10MB will give us some space. My local repo is 1.5GB so I'm guessing an average dev would need at least 500MB. ok? +1 /Anders /Anders [1] http://maven.apache.org/download.cgi#Requirements - 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: Jenkins job stability: was Re: [MNG-5551] Java 8 + Maven status
Well, the Windows IT build [1] has failed constantly for over a month. :-( /Anders [1] https://builds.apache.org/view/M-R/view/Maven/job/core-it-maven-3-win/ On Fri, Mar 28, 2014 at 12:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, as a fresh subscriber to notifications I really wonder how often the jobs have failed in the last two weeks. - One reason seems to be, that during staging of plugins and especially shared components the jobs are failing because of staged dependencies are not available in central. I proposed to include all of maven-staging to the settings of Jenkins for IT and shared, but there were some concerns by Karl-Heinz(?) Same goes for the pom staging. - Yesterday maven-dependency-analyzer was not able to compile it's tests, because the TestCase symbol from junit was missing, my guess would be a defect local repository because of concurrent downloads. - All in all right now the jobs do irritate me more than help me. - IMO once a Jenkins job fails oftenly out of the blue it rapidly starts to become useless :-) So I have two proposals: - Include maven-staging in a special settings file included in maven-shared and maven-plugin only to be used in Jenkins. - Configure jobs to use a private repository in the Jenkins workspace and purge it beforehand. What do you think? Regards Mirko -- Sent from my mobile On Mar 28, 2014 8:12 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: why didn't we detect the failure when building the plugin and running ITs with JDK 8 = somthing we did a long time ago and that I was conviced would give us more accurate results than what we finally have? I had a quick look at ITs, and it seems that the compiler plugin is configured to generate 1.5 bytecode IMHO, we need to add an IT generating 1.8 bytecode to make tests and show the failure before fixing and being sure the fix is complete. I didn't have time to really test, but I hope such discussion can help us improve JDK8 support more rapidly And find every other place where JDK8 compatibility won't be automatic: looking for asm is one way, but I suppose there may be problems for tools not using asm Regards, Hervé Le vendredi 28 mars 2014 07:40:53 Kristian Rosenvold a écrit : I have updated dependency (maven shade) to use asm 5.0.1, and I hope to get version 0.8 of dependency released RealSoon (tm). Kristian 2014-03-27 21:16 GMT+01:00 Mirko Friedenhagen mfriedenha...@gmail.com: Steven, thanks, I now could reproduce this. Installing a local SNAPSHOT of the shared library and plugin did resolve this. So I guess we have to release both pretty soon :-). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 27, 2014 at 8:37 PM, Steven Schlansker stevenschlans...@gmail.com wrote: Here is a reproduction case: https://github.com/stevenschlansker/mdep-439-analyze-java8 On Mar 27, 2014, at 10:26 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Steven, I can not reproduce that maven-dependency-plugin:analyze:2.8 fails with JDK8. I have created a small library with a Lambda (call it L) and ran dependency:analyze without probems. I installed this library and made a new component depend on L and ran dependency:analyze successfully again. As stated in MDEP-439[1], can you or someone else provide a sample? Otherwise I will close this bug. [1] http://jira.codehaus.org/browse/MDEP-439 Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen ) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 27, 2014 at 1:28 PM, Matt Benson gudnabr...@gmail.com wrote: Oh, good news on the dependency plugin bit--I almost forgot that you had mentioned its underlying library having already upgraded its trunk to version 4. I was thinking more about jdependency, which supports the shade plugin. Matt On Mar 27, 2014 7:22 AM, Matt Benson gudnabr...@gmail.com wrote: Oh, well... It's no secret that ASM 3, being interface-based, is wholly incompatible with ASM 4, which took the approach of using abstract classes to significantly reduce the amount of code needed to accomplish a given task. ASM 5 claims to be compatible with 4, which is why I, not realizing that the plugins in question were based on ASM 3, suggested that simply dropping in the new jar should suffice. The good news is that the upgrade process is not terribly onerous, if only someone steps to do it. Matt On Mar 27, 2014 5:25 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Mark, the analyze goal
Re: Operating system requirement
The requirements also says: Disk No minimum requirement. Approximately 100MB will be used for your local repository, however this will vary depending on usage ... AFAICT there _is_ a minimum requirement which is needed to store a basic set of plugins. And of course there is the Maven application itself, though that is tiny (under 6Mb for 3.0.5) 100MB is quite a small repository; they can easily grow to 1GB or more. So you think we should change to for example: Approximately 10MB is required for the Maven installation itself. In addition to that, additional disk space will be used for your local Maven repository. The size of your local repository will vary depending on usage but calculate for at least 500MB. Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is even smaller. Stating approx 10MB will give us some space. My local repo is 1.5GB so I'm guessing an average dev would need at least 500MB. ok? /Anders /Anders [1] http://maven.apache.org/download.cgi#Requirements - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.2.1 release notes
Make sure to use the existing URL of http://maven.apache.org/release-notes.html to get to the starting point of this. This URL is found in our distros as well as on the site. /Anders On Tue, Mar 25, 2014 at 5:13 AM, Jason van Zyl ja...@takari.io wrote: If no one else minds I'll convert it all to single markdown document. On Mar 24, 2014, at 7:50 PM, Olivier Lamy ol...@apache.org wrote: sounds good go for that On 25 March 2014 10:13, Jason van Zyl ja...@takari.io wrote: Fat fingers. I meant to say a single curated set of release notes. On Mar 24, 2014, at 3:49 PM, Olivier Lamy ol...@apache.org wrote: so need some work. The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 release notes has been made using markdown. If someone has idea go for it (ATM I don't have enough time for that). Cheers Olivier On 25 March 2014 09:27, Olivier Lamy ol...@apache.org wrote: working on fixing that. As the format has changed (apt - md) the velocity script cannot see it. On 25 March 2014 08:45, Andrew Holland aholl...@a1dutch.co.uk wrote: Hi, Maven 3.2.1 release notes seem to be missing from http://maven.apache.org/release-notes-all.html Regards Andy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - 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/takari_io - 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) -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - 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/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe
Re: Operating system requirement
Well, I was not aiming att create more work. Just make sure the stated info is correct (and understandable). As it is right now I don't understand what we're trying to say. /Anders On Wed, Mar 26, 2014 at 9:07 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: What about collecting data from users via a Google form? Maven version, OS and JDKs as checkboxes come to my mind :-) I would guess Windows NT is not used that often nowadays (at least for Java development). Regards Mirko -- Sent from my mobile On Mar 25, 2014 10:42 PM, Anders Hammar and...@hammar.net wrote: Under requirements [1], we're stating the following: No minimum requirement. On Windows, Windows NT and above or Cygwin is required for the startup scripts. Tested on Windows XP, Fedora Core and Mac OS X. What exactly are we trying to say with the On Windows, Windows NT and above or Cygwin is required for the startup scripts. sentence? is it just me or is the English weird? Also, what is tested on WinXP, Fedora and Mac? Is it Maven which is tested on these platforms, or the startup scripts? AFAIK we have no CI IT builds on Fedora. But we have it on Ubuntu. Also, should we state Mac even though we don't have CI IT builds on Mac? I know we're several devs on Mac though. /Anders [1] http://maven.apache.org/download.cgi#Requirements
Operating system requirement
Under requirements [1], we're stating the following: No minimum requirement. On Windows, Windows NT and above or Cygwin is required for the startup scripts. Tested on Windows XP, Fedora Core and Mac OS X. What exactly are we trying to say with the On Windows, Windows NT and above or Cygwin is required for the startup scripts. sentence? is it just me or is the English weird? Also, what is tested on WinXP, Fedora and Mac? Is it Maven which is tested on these platforms, or the startup scripts? AFAIK we have no CI IT builds on Fedora. But we have it on Ubuntu. Also, should we state Mac even though we don't have CI IT builds on Mac? I know we're several devs on Mac though. /Anders [1] http://maven.apache.org/download.cgi#Requirements
Re: [VOTE] Retire Maven Reactor Plugin
+1 /Anders On Sat, Mar 22, 2014 at 10:52 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote: Hi, based on the decision we have made on the 18. february 2014 to define End Of Life of Maven 2 http://maven.apache.org/maven-2.x-eol.html I would suggest to retire the Maven Reactor Plugin. The last release has been made on 23rd of september 2008 version 1.0. Apart from that the complete functionality is now part of Maven 3. I therefor propose that we retire maven-foo-plugin. If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the retired area in Subversion. The process for retiring a plugin is described here: http://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing maven-buildnumber-plugin as-is?
It's a Codehaus Mojo plugin so you should post to that dev list instead. /Anders Den 18 mar 2014 15:30 skrev Baptiste Mathus bmat...@batmat.net: Hi, There seems to be a need for a release for buildnumber with @threadSafe added. https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups. I can act as RM if nobody objects against this release now. That'll help users. If anyone wants to try and tackle some more things on this plugin, just let me know we can obviously wait. Cheers -- Baptiste
Re: Releasing maven-buildnumber-plugin as-is?
Attach a patch to the ticket and I'm sure Baptiste, or someone else, can apply it before release. /Anders On Tue, Mar 18, 2014 at 8:17 PM, Michael Osipov micha...@apache.org wrote: Am 2014-03-18 15:29, schrieb Baptiste Mathus: Hi, There seems to be a need for a release for buildnumber with @threadSafe added. https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups. I can act as RM if nobody objects against this release now. That'll help users. If anyone wants to try and tackle some more things on this plugin, just let me know we can obviously wait. Actually, I would want to fix one issue but I do not have the permission in JIRA nor do I have write access to that repo. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome Mirko! /Anders On Mon, Mar 17, 2014 at 8:53 PM, Robert Scholte rfscho...@apache.orgwrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin / Maven default folder layout
Sounds good to me. /Anders On Sun, Mar 9, 2014 at 9:02 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote: So based on the discussion could we go with the following: /src/main * are files required during compile time (production) /src/test * are files required during test time (unit testing; based on naming schema we could also have integration tests here) /src/it * are files required during integration tests (primarily for plugins) /src/assembly * for assembly descriptors and appropriate filter property files. The /src/it/ should be added to the default folder layout page. Should we start a VOTE for this ? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Apache Org Download Pages
There are instructions on the dev page. I'm on a phone right now so can't provide link. /Anders (mobile) Den 26 feb 2014 08:00 skrev Karl Heinz Marbaise khmarba...@gmx.de: Hi, I have fixed it in the SVN ..can someone roll out this ? Or can i do this myself ? If yes how? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release notes for 3.2.1 lost on the Maven homepage
I had a look at the Download page and the JDK requirements incorrectly states 1.5. It should be 1.6 for Maven 3.2.x. I've fixed this now. /Anders /Anders On Mon, Feb 24, 2014 at 5:53 AM, Jason van Zyl ja...@takari.io wrote: I just published the site with the ref docs and the updated release notes. I don't know how long it takes to sync but you can check anything in SVN. I'll leave them there until the morning, if you want to make any changes feel free. If there are no issues I'll send out the announcement in the morning. On Feb 23, 2014, at 1:03 PM, Jason van Zyl ja...@takari.io wrote: I haven't announced it yet because trying to make all the pertinent changes to the site is tedious. Take a look at the end of the day. On Feb 23, 2014, at 12:52 PM, Michael Osipov micha...@apache.org wrote: Hi folks, did anyone already check http://maven.apache.org/docs/3.2.1/release-notes.html? The link See complete release notes for all versions links to http://maven.apache.org/ and is missing a period. Release notes not available. http://maven.apache.org/ref/3.2.1/ is a 404. http://maven.apache.org/release-notes-all.html does not include 3.2.x, neither does http://maven.apache.org/release-notes-3.x.html. http://maven.apache.org/download.cgi says: Maven 3.1.1 This is a stable version 3.0.x of Maven for projects that can't upgrade to Maven 3.1 yet. This is obviously, incorrect. AND Windows 2000/XP + C:\Program Files\Java\jdk1.5.0_02, seriously? Who has a good overview over that content to fix it? Michael - 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/takari_io - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
First, thanks Stephen (and others) for working on this. I think it's very important that we use version numbers consistently and also communicate what they mean to our users. We should also be very clear with what to expect. I agree with Dennis and Brett here, I think we could simplify by just stating what we promise to do. Not what could possibly happen. This will set up the right expectations for the users. Wrt to the 18 months for security maintenance lines for core, I think that could be to start out with. If we see that it's too short of a windows we could extend it. Either as just a one time thing or extend the general policy. For plugins (including the parent pom) and components/wagon, I think we should go with just one line. We should set the right expectations and not promise too much. And yes, let's bring out the JDK requirement policy to a separate document. It's a separate topic I think. /Anders On Mon, Feb 24, 2014 at 12:07 AM, Brett Porter br...@apache.org wrote: On 24 Feb 2014, at 2:48 am, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I guess we need to clear up what I mean by a maintenance line... We *can/may* cut releases on maintenance / security line... Does not mean we *will* more that for non-security/maintenance lines there is ZERO possibility of us cutting a release... As another data point, my reaction was the same as as Dennis' on first reading. I think the doc could be simplified - perhaps it is more helpful to describe what will be done, not what can/may be done, but then have avenues to add those when possible. Say, start with the last stable release as a the maintenance/security line, but add others where there are willing volunteers to continue maintaining it. IIUC, if a security issue came in the next few weeks, it'd probably be fixed in 3.2.x and 3.0.x (not upgrading due to some plugin incompatibilities), but not 3.1.x (expected to be a smooth upgrade to 3.2.x). Is that what would realistically happen? On the components/plugins/wagon side, I don't think there's much need for older lines, since there are unlikely to be downstream users that can't upgrade to the latest. The only exception I could think of historically was when Site was maintained for Maven 2. - Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Branch the parent pom hierarchy for Java 1.6 + Maven 3
+1 (possibly set the deps to 3.0.4 instead, and not 3.0.5) I don't think we need to branch the parent poms. That will just create unnecessary complexity. As you pointed out, plugins can continue to use the Q-1 version of the parent if the want to go with 2.x-compat (and add/override plugin upgrades/configs if needed). I'm also very positive to avoid a disorganized process of individual plugins! /Anders On Sun, Feb 23, 2014 at 10:15 PM, Benson Margulies bimargul...@gmail.comwrote: I think that Michael might be over-reading my intentions. I am not trying to start a short-term avalanche of moving components to require 3.0.5. My idea is: 1. We release parents that set up the 3.0.5 dependencies. Call that version Q. 2. Any maintainer who feels inclined to release a 2.2.x-compatible component or plugin is welcome to continue to use parent Q-1. 3. Any maintainer who feels inclined to move a component to the new regime changes the parent version to Q. As far as I am concerned, it might take _years_ before everything under the auspices of this project moves to require 3. On Sun, Feb 23, 2014 at 3:38 PM, Michael Osipov micha...@apache.org wrote: Am 2014-02-23 21:20, schrieb Stephen Connolly: On Sunday, 23 February 2014, Michael Osipov micha...@apache.org wrote: Am 2014-02-23 19:06, schrieb Benson Margulies: I propose to make releases of our parent stack that are suitable for components and plugins that are making the leap to Java 1.6 and Maven 3 as their base requirements. What do people think is the right approach in terms of what stays on trunk and what goes on a branch, and whether to do anything distinctive to the version numbers? Finally, someone's stepping up for such a good change. Though, I think some important stuff needs to be considered first: 1. Announce 2.x EOL and give people at least 3 months to switch. Already done and site updated Just had a hard time to find this information on the (front) page. I think a mere: 2014-02-18 End of Life EoL notes, announce is not enough. I would have expected something like this on the front page: Looking for Maven 2? // Either some text // or the link to the EoL announcement. 2. If you align plugins with a 3.0 baseline, I would bump at least a minor version, maybe even a major one. I think bumping a major version would be fair and proper... But we don't have a formal policy yet, and a minor version bump might be valid too. Beside the general draft [1] we do already have two good policies. Even one at Apache APR [2], and semver.org. Micahel [1] https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy [2] https://apr.apache.org/versioning.html#strategy - 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: Release notes for 3.2.1 lost on the Maven homepage
I had a look at the Download page and the JDK requirements incorrectly states 1.5. It should be 1.6 for Maven 3.2.x. /Anders On Mon, Feb 24, 2014 at 5:53 AM, Jason van Zyl ja...@takari.io wrote: I just published the site with the ref docs and the updated release notes. I don't know how long it takes to sync but you can check anything in SVN. I'll leave them there until the morning, if you want to make any changes feel free. If there are no issues I'll send out the announcement in the morning. On Feb 23, 2014, at 1:03 PM, Jason van Zyl ja...@takari.io wrote: I haven't announced it yet because trying to make all the pertinent changes to the site is tedious. Take a look at the end of the day. On Feb 23, 2014, at 12:52 PM, Michael Osipov micha...@apache.org wrote: Hi folks, did anyone already check http://maven.apache.org/docs/3.2.1/release-notes.html? The link See complete release notes for all versions links to http://maven.apache.org/ and is missing a period. Release notes not available. http://maven.apache.org/ref/3.2.1/ is a 404. http://maven.apache.org/release-notes-all.html does not include 3.2.x, neither does http://maven.apache.org/release-notes-3.x.html. http://maven.apache.org/download.cgi says: Maven 3.1.1 This is a stable version 3.0.x of Maven for projects that can't upgrade to Maven 3.1 yet. This is obviously, incorrect. AND Windows 2000/XP + C:\Program Files\Java\jdk1.5.0_02, seriously? Who has a good overview over that content to fix it? Michael - 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/takari_io - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: What is in a version? (was Towards faster releases)
Thanks for bringing this up, Stephen! My +1 goes to backwards-compatible bug fixes (only) in a bugfix/patch release. If we could decide (whatever we decide) what changes goes into what sort of release, I think that would help the community a lot. I personally think that re-using somehting like semver would be very good and in the spirit of Maven's theme of best-practices. However, I fully appreciate that opinions on best-practice in this case could be different than mine. I also fully agree with Jason on how things work with larger companies, where upgrading something like Maven is a big process. So if we have bugfix releases where we carefully introduce on fixed for known bugs, I think this would be very good and simplify that process. Also, out of a PR perspective, I think that increasing the minor version when we add new functionality (doesn't have to be from a user perspective but could be technical) is good. It shows that Maven is moving forward. /Anders On Wed, Feb 19, 2014 at 10:22 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think we have a bit of a disagreement about what changes should be going into different version numbers. To my mind, we should be using the convention that most people expect, i.e. semver[1]-ish. I am not saying that we need to be super-strict in following the exact semver specification, but I do think that we should be following the semver spirit: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. So with the above principle, the only changes that should be going into the 3.2.x line should be backwards compatible bug fixes. Adding functionality should be going towards 3.3.x And the modelVersion 5.0.0 stuff should be going towards 4.0.x If I look at the issue tracker for 3.2.2: http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG I currently see 9 issues: Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958 Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559 If we accept the principle that only bug fixes should be going into patch/incremental releases then those 5 improvements are out of scope for 3.2.x If we dig a bit further: * MNG-5552's fix involves extending the API, so that would be 3.3.x * MNG-5474 may introduce regressions if there is anyone depending on the current behaviour, so that could be seen as 3.3.x So my aim of faster releases becomes as soon as we get a fix for either MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we should consider cutting a release of that line. That is the context in which I am suggesting that we could move to faster releases... Now there is a big *if* that I ack was my implicit unstated understanding when I started the Towards faster releases thread... namely that: A Patch/Incremental version is backwards compatible bug fixes only. No additional functionality. Additional functionality goes in a new minor version. I think the resistance to my suggestion from Jason is either from a different world view on what should go into a patch/incremental version... or perhaps just forgetting that the scope of patch/incremental versions is what I suggest it is. So my question to the Maven developers is this: What types of things should be eligible for a patch/incremental release of Maven? Is it backwards-compatible bug fixes only? Is it backwards-compatible bug fixes and api improvements? Is it any bug fix and backwards-compatible api improvements? Is it something else? Keep in mind that users out there could well be expecting something semver-ish... as that is a meme that seems to me to be catching on... FYI: If the consensus view is different from `backwards-compatible bug fixes only` then there is no point in pursuing my plan of weekly checks for a new patch release and cutting such a release if it is releasable, and I will drop them (we can keep the tooling I have put in place as it will help improve our quality... and I intend improving that tooling anyway). But if the consensus is that patch/incremental versions should be `backwards-compatible bug fixes only` then I see no good reason why we should hold onto those fixes any longer than a week after they have been committed. New features can go straight into the 3.3.x branch and I (and others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and cut those releases when they are ready. (Which was what I thought my proposal was... but re-reading I ack that it was not as obvious to the reader as it was to the writer ;-) ) -Stephen [1]: http://semver.org/
Re: Q: Maven Toolchain
One thing it can be used for is to define a different JDK to be used (than the one used for executing Maven itself). More info here: http://maven.apache.org/guides/mini/guide-using-toolchains.html /Anders On Wed, Feb 19, 2014 at 7:12 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote: Hi, maybe i didn't see a thing, but can someone explain me the intention of the maven toolchain in relationship with a plugin ... Currently i only see that it can find some kind of executable which is configured in somekind of buildcontext...which i currently don't understand how to configure (I've taken a look into the maven-toolchains-plugin which didn't enlighten me)... But what are the advantages / disadvantages of that ? May be i just be blockhead ...;-( Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Issue - pluginManagement - build Area Plugin
Right. It seems no one knows where the source is.
I think this is better to discuss in the JIRA ticket. It's not for this
list.
I'm sure that e.g. the Mojo team could take responsibility of
codehaus-parent. Just need Ben to set up a repo.
/Anders
On Fri, Feb 14, 2014 at 9:09 AM, Baptiste Mathus m...@batmat.net wrote:
Seems like this super pom is versioned at github under the sonatype
organization (?).
Cf. scm tag in
http://repo1.maven.org/maven2/org/codehaus/codehaus-parent/4/codehaus-parent-4.pom
But https://github.com/sonatype/codehaus-parent gives a 404...
Anyone?
2014-02-14 9:01 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de:
Hi Anders,
I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
Good to know...
Unfortunately the codehaus-parent seems to be in a unmaintained state.
Who is responsible for the codehaus-parent ? Can we (or i) take the issue
and fix it ?
/Anders
[1] http://jira.codehaus.org/i#browse/HAUS-2245
On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:
Hi,
i have a question. The following situation. Pom file which uses the
following parent:
parent
groupIdorg.codehaus/groupId
artifactIdcodehaus-parent/artifactId
version4/version
/parent
prerequisites
maven${mavenVersion}/maven
/prerequisites
and the following part in my pom file:
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
/plugin
/plugins
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
executions
execution
idenforce-maven/id
goals
... The rule does not matter..
So if i call (Maven 2.2.1)
mvn clean package I got the following error:
[INFO] [clean:clean {execution: default-clean}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:
maven-enforcer-plugin:1.0
Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot
be
instantiated
So if i call with Maven 3.0.5:
[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-enforcer-plugin:1.0:enforce (enforce-maven) on project
test-enforcer: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for
parameter
requireSameVersions: Abstract class or interface
'org.apache.maven.enforcer.rule.api.EnforcerRule'
cannot be instantiated - [Help 1]
Maven 3.1.X and Maven 3.2.X tested as well...
So this looks to me that the pluginManagement does not overwrite the
version 1.0 which is defined in the codehaus-parent. To be honest the
codehaus-parent does not define it via pluginManagement it just uses
the
following:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0/version
executions
execution
idenforce-maven/id
goals
goalenforce/goal
/goals
configuration
rules
requireMavenVersion
version(,2.1.0),(2.1.0,2.2.0),(2.2.0,)/version
messageMaven 2.1.0 and 2.2.0
produce
incorrect GPG signatures and checksums respectively./message
/requireMavenVersion
/rules
/configuration
/execution
/executions
/plugin
/plugins
First the codehaus-parent seemed to be wrong...so i can't overwrite the
version of the plugin by using a pluginManagement block in inherited
project which forces me to define the version explicitly in my pom in
the
build block to get that working like this:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
executions
WDYT ? Bug ? Right behaviour ?
Kind regards
Karl-Heinz Marbaise
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
You should use the Maven users mailing list. This list is for developing Maven itself. Info here: http://maven.apache.org/mail-lists.html /Anders On Thu, Feb 13, 2014 at 10:30 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote: Hi Apologies for posting in a too general mailing list but I could not find a better one. I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: [VOTE] Maven 2.x is end of life
+1 /Anders On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
Re: Respinned releases and versions Re: [VOTE] Release Maven 3.2.0
Clarification to 2): Sonatype uses the x.y.z-b version scheme (dash, not underscore) which works with Maven's suggsted version syntax. This is also the syntax I use for all customers I work with and that use staging. The 'b' is the release build, which starts on '1' and is incremented for each new release. Earlier we used to do RC builds (or at least Benjamin did so) which I found very good to test new core versions early. The drawback was that we had to respin to get rid of the 'RC' in the version. In any case, we've discussed this earlier and even voted on it I believe. Regardless of what one individual thinks is the right way, I don't think it's cool to just ignore what has already been decided on. Personally I don't even see the problem re-using version numbers for Maven core releases. For plugin releases there is a much more likely to be some confusion though. /Anders On Wed, Feb 12, 2014 at 9:35 AM, Arnaud Héritier aherit...@gmail.comwrote: Hi, I'm in favor to not reuse the version. Like many others I'm often lost between intermediate and final versions (but we can see it also as a maven dev and advanced users privilege/constraint too - thus applying to very few people). We discussed about it many times and AFAIK we have 2 solutions to achieve this : 1/ We just pass some minor versions like Apache Tomcat is doing ( http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many not released versions). We announce only releases considered stable (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and versions in Jira. Users will have to take care to append all release notes of none stable version to know what we changed between two stables versions (or we have to do it for them). 2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it is like Sonatype Nexus team is doing. We have distinct tags in our SCM (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable version we publicly announce. In Jira we only have a 3.2.0 version and we just reopen or add issues in it to track the release landing. For users we'll just announce a 3.2.0 but the binary they'll have will be called 3.2.0_2 for example. In both cases we will throw in the bin unstable releases. I like both approaches and prefer them compared to our current one. Between both of them I would prefer the second one (transparent for users and not difficult for us). WDYT ? Note : Even If I'm in favor of this change I really don't want to hold up the current release which such debate/vote thus I think it may be better to apply this change only for the next release depending of how many time all active developers think they need to finalize the 3.2.0 release and launch another vote. Arnaud On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt m...@talios.com wrote: On 12 Feb 2014, at 13:57, Benson Margulies wrote: 3.2.0.1 :-) 3.2.0-patchlevel-1-GA. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: Maven Issue - pluginManagement - build Area Plugin
I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
Unfortunately the codehaus-parent seems to be in a unmaintained state.
/Anders
[1] http://jira.codehaus.org/i#browse/HAUS-2245
On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote:
Hi,
i have a question. The following situation. Pom file which uses the
following parent:
parent
groupIdorg.codehaus/groupId
artifactIdcodehaus-parent/artifactId
version4/version
/parent
prerequisites
maven${mavenVersion}/maven
/prerequisites
and the following part in my pom file:
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
/plugin
/plugins
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
executions
execution
idenforce-maven/id
goals
... The rule does not matter..
So if i call (Maven 2.2.1)
mvn clean package I got the following error:
[INFO] [clean:clean {execution: default-clean}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:
maven-enforcer-plugin:1.0
Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be
instantiated
So if i call with Maven 3.0.5:
[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-enforcer-plugin:1.0:enforce (enforce-maven) on project
test-enforcer: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for parameter
requireSameVersions: Abstract class or interface
'org.apache.maven.enforcer.rule.api.EnforcerRule'
cannot be instantiated - [Help 1]
Maven 3.1.X and Maven 3.2.X tested as well...
So this looks to me that the pluginManagement does not overwrite the
version 1.0 which is defined in the codehaus-parent. To be honest the
codehaus-parent does not define it via pluginManagement it just uses the
following:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0/version
executions
execution
idenforce-maven/id
goals
goalenforce/goal
/goals
configuration
rules
requireMavenVersion
version(,2.1.0),(2.1.0,2.2.0),(2.2.0,)/version
messageMaven 2.1.0 and 2.2.0 produce
incorrect GPG signatures and checksums respectively./message
/requireMavenVersion
/rules
/configuration
/execution
/executions
/plugin
/plugins
First the codehaus-parent seemed to be wrong...so i can't overwrite the
version of the plugin by using a pluginManagement block in inherited
project which forces me to define the version explicitly in my pom in the
build block to get that working like this:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
executions
WDYT ? Bug ? Right behaviour ?
Kind regards
Karl-Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas
It would be great if you could file a JIRA ticket so that the docs can be fixed, see [1]! Use the website JIRA project. /Anders [1] http://maven.apache.org/issue-tracking.html On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian ian.barn...@lmco.com wrote: I develop behind a proxy. Some of our servers sit behind that proxy as well, including our Nexus Repository. I have configured my settings.xml to point to our proxy but to ignore the hosts that are behind that proxy. If I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore that list and apply the proxy to those hosts as well. If I use a pipe-delimited list in my nonProxyHosts, everything works great and Maven does NOT try to apply the proxy to those hosts. According to this document only pipes are acceptable as delimiters, which is what I observed: https://maven.apache.org/guides/mini/guide-proxies.html According to this document either pipes or commas are acceptable as delimiters which is incorrect according to my observation: https://maven.apache.org/settings.html (Proxies header) This is an example of the proxies block in my settings.xml file that does not work. When Maven needs to hit 123.456.789.111 or my.nexus.host, it applies the proxy to it. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost,123.456.789.*,my.nexus.host/nonProxyHosts /proxy /proxies This example WORKS. Proxy is ignored for any requests to 123.456.789.111 or my.nexus.host, etc. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost|123.456.789.*|my.nexus.host/nonProxyHosts /proxy /proxies Environment: Maven 3.1.1 Mac OS-X 10.9 Also reproduced this issue on: Apache Maven 3.0.4 Ubuntu 11.04 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PATCH] Allow spaces in javadoc exclude list
I think this also calls for an request for improvement to Atlassian. That text should be configurable. /Anders On Wed, Jan 29, 2014 at 10:51 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI, when you go to jira.codehaus.org, the System Dashboard has two boxes at the top... On the Right Hand Side: Login... with the text Not a member? To request an account, please contact your JIRA administrators On the Left Hand Side: Introduction... with the text Sign-up for a JIRA account You will need to create an account in Xircles - https://xircles.codehaus.org/signup/ - this became necessary to combat spammers who had automated JIRA signups. So the signup link is actually *right there* but only on the front page of JIRA... and in a box you probably skip reading... Ben recons it needs some jQuery to change the Login box... because most people will actually be on the login screen when they need to create an account and that doesn't have any message about xircles... and seemingly the templates don't really let you change the text on the login screen... so jQuery will have to hack the text... Ben's jquery skills are a league above mine... so we'll see how he gets on! On 29 January 2014 09:42, Stephen Connolly stephen.alan.conno...@gmail.comwrote: You go to xircles.codehaus.org to get an account... I'll ask Ben@codehausto see if the JIRA signup message can be changed to point people at xircles... On 28 January 2014 20:52, Paul Benedict pbened...@apache.org wrote: Good point. It seems JIRA is setup not to allow public signup. Who in Maven Land can help him? On Tue, Jan 28, 2014 at 2:37 PM, Omair Majid oma...@redhat.com wrote: * Paul Benedict pbened...@apache.org [2014-01-28 15:34]: Your best course is to create a new ticket for the Maven Javadoc plugin, and then attach your patch to the ticket: http://jira.codehaus.org/browse/MJAVADOC Thanks for the pointer. Filing a bug was my first thought too, but I don't have an account on jira.codehaus.org and I don't see a way of signing up for one. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Cheers, Paul
Re: [PATCH] Allow spaces in javadoc exclude list
Found this: https://confluence.atlassian.com/display/JIRAKB/How+to+Customise+the+Login+Gadget Seems as with 6.0 you alter install/atlassian-jira/includes/loginform.jsp Possibly needs to be re-applied when upgrading though. /Anders On Wed, Jan 29, 2014 at 12:50 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ben seems confident he can use jquery to fix it... On 29 January 2014 09:55, Anders Hammar and...@hammar.net wrote: I think this also calls for an request for improvement to Atlassian. That text should be configurable. /Anders On Wed, Jan 29, 2014 at 10:51 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI, when you go to jira.codehaus.org, the System Dashboard has two boxes at the top... On the Right Hand Side: Login... with the text Not a member? To request an account, please contact your JIRA administrators On the Left Hand Side: Introduction... with the text Sign-up for a JIRA account You will need to create an account in Xircles - https://xircles.codehaus.org/signup/ - this became necessary to combat spammers who had automated JIRA signups. So the signup link is actually *right there* but only on the front page of JIRA... and in a box you probably skip reading... Ben recons it needs some jQuery to change the Login box... because most people will actually be on the login screen when they need to create an account and that doesn't have any message about xircles... and seemingly the templates don't really let you change the text on the login screen... so jQuery will have to hack the text... Ben's jquery skills are a league above mine... so we'll see how he gets on! On 29 January 2014 09:42, Stephen Connolly stephen.alan.conno...@gmail.comwrote: You go to xircles.codehaus.org to get an account... I'll ask Ben@codehausto see if the JIRA signup message can be changed to point people at xircles... On 28 January 2014 20:52, Paul Benedict pbened...@apache.org wrote: Good point. It seems JIRA is setup not to allow public signup. Who in Maven Land can help him? On Tue, Jan 28, 2014 at 2:37 PM, Omair Majid oma...@redhat.com wrote: * Paul Benedict pbened...@apache.org [2014-01-28 15:34]: Your best course is to create a new ticket for the Maven Javadoc plugin, and then attach your patch to the ticket: http://jira.codehaus.org/browse/MJAVADOC Thanks for the pointer. Filing a bug was my first thought too, but I don't have an account on jira.codehaus.org and I don't see a way of signing up for one. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Cheers, Paul
Re: Closing as Won't Fix and Fix Version combo
I agree. /Anders (mobile) Den 29 jan 2014 18:24 skrev Paul Benedict pbened...@apache.org: At times, we close issues as Won't Fix but leave the version number on it. I can understand why someone might do that, but I think it creates more confusion than good. For example, we publish the JIRA ticket on the Maven site for each new version -- but without status, I think it's normal for people to believe all these tickets were fixed. What do you all think of agreeing to remove the version if it is Won't Fix? If it's not being fixed, the Fix Version really loses its meaning. Don't forget we always have the Affects Version to track what version it was reported against. -- Cheers, Paul
Re: JIRA Cleanup
+1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.0 Bug Scrub
Sounds good to me. /Anders On Tue, Jan 7, 2014 at 1:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: AFAIU this is the current list of bugs: http://jira.codehaus.org/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%20%223.2%22%20AND%20(status%20%3D%20Open%20OR%20status%20%3D%20%22In%20Progress%22%20or%20status%3DReopened)%20ORDER%20BY%20priority%20DESC I propose that the following issues all require a change to the model version, and thus should be pushed back to 4.0.0 (or later) http://jira.codehaus.org/browse/MNG-1977 Global dependency exclusionshttp://jira.codehaus.org/browse/MNG-1977 http://jira.codehaus.org/browse/MNG-2297 Change the POM to use attributeshttp://jira.codehaus.org/browse/MNG-3397 http://jira.codehaus.org/browse/MNG-5102 Mixin POM fragmentshttp://jira.codehaus.org/browse/MNG-5102 http://jira.codehaus.org/browse/MNG-2199 Version ranges not supported for parent artifacts http://jira.codehaus.org/browse/MNG-2199 http://jira.codehaus.org/browse/MNG-2216 Add default encodings section to POM http://jira.codehaus.org/browse/MNG-2216 http://jira.codehaus.org/browse/MNG-3826 Add profile activation when project version matches a regex http://jira.codehaus.org/browse/MNG-3826 http://jira.codehaus.org/browse/MNG-2316 Add info to the poms for dependencies that implement an API or provide other dependencies http://jira.codehaus.org/browse/MNG-3326 Profile Deactivation Configuration http://jira.codehaus.org/browse/MNG-2557 Various enhancements to profiles http://jira.codehaus.org/browse/MNG-2598 Profile element in POM should support overriding project.build.directory (WONTFIX candidate?) http://jira.codehaus.org/browse/MNG-3726 Extend POM model to support declaration of IRC channels The following issues require that the deployed pom be different from the on-disk pom, i.e. the same problem we had with 2.1.0 and 2.2.0... again I think these should be pushed back to 4.0.0 (or later) http://jira.codehaus.org/browse/MNG-624 Automatic parent versioninghttp://jira.codehaus.org/browse/MNG-624 I would propose that we move these issues into a 4.0 bucket... that will bring us down to 31 issues open for 3.2.0 Thoughts?
Re: 3.2.0 Bug Scrub
I stepped up big time and moved MNG-5356 (Make encrypt/decrypt logic pluggable) to the 4.x list. :-) /Anders On Tue, Jan 7, 2014 at 4:25 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: OK we are now at 38 open issues anyone else feel like scrubbing some more? On 7 January 2014 15:25, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Done On 7 January 2014 14:43, Jason van Zyl ja...@tesla.io wrote: Seems reasonable. Go for it. On Jan 7, 2014, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: AFAIU this is the current list of bugs: http://jira.codehaus.org/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%20%223.2%22%20AND%20(status%20%3D%20Open%20OR%20status%20%3D%20%22In%20Progress%22%20or%20status%3DReopened)%20ORDER%20BY%20priority%20DESC I propose that the following issues all require a change to the model version, and thus should be pushed back to 4.0.0 (or later) http://jira.codehaus.org/browse/MNG-1977 Global dependency exclusionshttp://jira.codehaus.org/browse/MNG-1977 http://jira.codehaus.org/browse/MNG-2297 Change the POM to use attributeshttp://jira.codehaus.org/browse/MNG-3397 http://jira.codehaus.org/browse/MNG-5102 Mixin POM fragmentshttp://jira.codehaus.org/browse/MNG-5102 http://jira.codehaus.org/browse/MNG-2199 Version ranges not supported for parent artifacts http://jira.codehaus.org/browse/MNG-2199 http://jira.codehaus.org/browse/MNG-2216 Add default encodings section to POM http://jira.codehaus.org/browse/MNG-2216 http://jira.codehaus.org/browse/MNG-3826 Add profile activation when project version matches a regex http://jira.codehaus.org/browse/MNG-3826 http://jira.codehaus.org/browse/MNG-2316 Add info to the poms for dependencies that implement an API or provide other dependencies http://jira.codehaus.org/browse/MNG-3326 Profile Deactivation Configuration http://jira.codehaus.org/browse/MNG-2557 Various enhancements to profiles http://jira.codehaus.org/browse/MNG-2598 Profile element in POM should support overriding project.build.directory (WONTFIX candidate?) http://jira.codehaus.org/browse/MNG-3726 Extend POM model to support declaration of IRC channels The following issues require that the deployed pom be different from the on-disk pom, i.e. the same problem we had with 2.1.0 and 2.2.0... again I think these should be pushed back to 4.0.0 (or later) http://jira.codehaus.org/browse/MNG-624 Automatic parent versioninghttp://jira.codehaus.org/browse/MNG-624 I would propose that we move these issues into a 4.0 bucket... that will bring us down to 31 issues open for 3.2.0 Thoughts? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: 3.2.0 Bug Scrub
* http://jira.codehaus.org/browse/MNG-5356 Make encrypt/decrypt logic pluggable Seems like something that could be in scope. Any takers? We already have a (I think) working fix for this in the git repo linked to in the comments. However, jvz suggested moving this to a separate component which would be some extra work/thinking. I did move this to the 4.x line as I'm not sure how much time I have to put into this the near future. But it could always be moved back to 3.2. It would be very good to get in there. /Anders * http://jira.codehaus.org/browse/MNG-5389AbstractMavenLifecycleParticipant need a afterSessionEnd ACTION: jvzyl to provide status update * http://jira.codehaus.org/browse/MNG-3092 Version ranges with non-snapshot bounds can contain snapshot versions Do we have a decision as to what we will do with this one? It is one of the longest discussions we have... On 7 January 2014 15:55, Stephen Connolly stephen.alan.conno...@gmail.comwrote: * http://jira.codehaus.org/browse/MNG-3695 Allow dependencies' scopes to be managed without explicit versions This does not affect the pom schema, but potentially affects other POM parsers. My instinct is that this is for 4.x not 3.2 * http://jira.codehaus.org/browse/MNG-3321 Skip plugin and/or execution After reading more closely, this seems to be changing the POM schema, at least with the current patch, move to 4.x? * http://jira.codehaus.org/browse/MNG-3124 Inherit mailing lists from parent POM Sounds like an issue building the internal model. Additionally this would not be a change that affects other consumers and their processing of dependencies, so this looks like a valid candidate to me. * http://jira.codehaus.org/browse/MNG-2807 ciManagement from parent is not merging with children Same as MNG-3124. Both issues are related it would seem * http://jira.codehaus.org/browse/MNG-3825 Dependencies with classifier should not always require a version. Same as MNG-3695 * http://jira.codehaus.org/browse/MNG-4173 Remove automatic version resolution for POM plugins This is somewhat reasonable, but we have already kicked this can down the road and it may hinder adoption. I would be happy to kick this one to 4.x on the basis that most existing poms were written with the assumption that you could avoid specifying the plugin version... and we even omit the plugin version in the asf parent pom for some stuff... On 7 January 2014 15:45, Stephen Connolly stephen.alan.conno...@gmail.com wrote: * http://jira.codehaus.org/browse/MNG-2478 add filtered resource directories to super POM Moved to 4.x bucket as requires pom model change * http://jira.codehaus.org/browse/MNG-426 create maxmem setting for all plugins to refer to I think this is now out of scope for core... but I would be interested in what others think * http://jira.codehaus.org/browse/MNG-683 Lifecycle mappings should specify phase bindings in terms of general functionality type This issue seems DOA at present... do we want to push it out again? * http://jira.codehaus.org/browse/MNG-841 Support customization of default excludes The issue as currently written seems to imply a pom format change... OTOH this could be handled by a standard property name. Probably more an issue for plugins that slurp directories or for the plexus utils that do this. * http://jira.codehaus.org/browse/MNG-193 symmetry for outputs of a plugin Sounds like this is a Move to 4.x issue On 7 January 2014 15:39, Stephen Connolly stephen.alan.conno...@gmail.com wrote: * http://jira.codehaus.org/browse/MNG-2381 Improved control over the repositories in the POM Unsure what the ask is here * http://jira.codehaus.org/browse/MNG-4506 Split site deployment URLs into release vs. snapshot, just like artifacts Moved to 4.x bucket as requires pom model change * http://jira.codehaus.org/browse/MNG-3474 Add parameter --internet to test Internet access with and without using proxy defined in settings.xml Any takers... looks like a nice small feature to add * http://jira.codehaus.org/browse/MNG-3879 Dependency map and documentation Moved to 4.x bucket as requires a pom model change ACTION: bmargulies - split the issue and rename existing issue so that the pom change is the title * http://jira.codehaus.org/browse/MNG-4171 The XML resulting from a property of java.util.Properties is a lot more clumsy than that for Map Unsure what the ask is here... seems like it's really a plexus compatibility layer issue * http://jira.codehaus.org/browse/MNG-4622 Throw Validation Error if pom contains a dependency with two different versions. I think we risk breaking too much with this one, we already emit the warning, and my view is that we should
Re: [VOTE] Release Maven JarSigner 1.3 and Apache Maven Jarsigner plugin 1.3
Maven shared JarSigner 1.3 -- The version 1.3 just fix an important bug while unsigning jar. We solved 1 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=19857styleName=Html For future releases, I think a bug fix release should only increment the third digit. Increasing the minor version indicates a new feature or similar. No need to re-roll this one though. /Anders There is no more issues in JIRA left :) Staging repo: https://repository.apache.org/content/repositories/maven-027 https://repository.apache.org/content/repositories/maven-027/org/apache/maven/shared/maven-jarsigner/1.3/maven-jarsigner-1.3-source-release.zip Source release checksum(s): maven-jarsigner-1.3-source-release.zip sha1: 40694567b1f57b490b7511b7e71bb51a435e0d3e Staging site: http://maven.apache.org/shared-archives/maven-jarsigner-LATEST Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 my +1 Apache Maven Jarsigner plugin 1.3 - Last release was on 30/Sep/09! We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11990version=18656styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=MJARSIGNERstatus=1 Staging repo: https://repository.apache.org/content/repositories/maven-027/ https://repository.apache.org/content/repositories/maven-027/org/apache/maven/plugins/maven-jarsigner-plugin/1.3/maven-jarsigner-plugin-1.3-source-release.zip Source release checksum(s): maven-jarsigner-plugin-1.3-source-release.zip sha1: 94389bb3b0896dec153b9bc2a70dd8f537af9f6f Staging site: http://maven.apache.org/plugins-archives/maven-jarsigner-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 my +1 tony. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New logo?
Oh and if anyone asks why I thought of a moose? Well he's friendly... as long as you do things his way... if you try to do things your way... well let's just see who wins, you or the angry moose! I'm really starting to like this moose guy! :-) /Anders On 18 December 2013 11:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Here is a more serious suggestion... A moose... why not Maven the moose! http://people.apache.org/~stephenc/maven-logo-contest/maven-3.png May need a tweaking... Here's a larger version http://people.apache.org/~stephenc/maven-logo-contest/maven-3-big.png On 17 December 2013 16:00, Stephen Connolly stephen.alan.conno...@gmail.com wrote: well if we do with Fred's McDonalds, the Apache feather needs some better integration with the globe as there is a shadow mismatch in my mashup! On 17 December 2013 15:48, Tamás Cservenák ta...@cservenak.net wrote: Ok, then let me try to find some imagery... hm, google for maven, mkay, click Images WOW http://screencast.com/t/tfc20w9RA I'd rather go to Fred's McDonalds... :D On Tue, Dec 17, 2013 at 4:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yes I know... this is not a serious suggestion... To understand my logic... When people cannot decide what restaurant to go to, the easy way to get a suggestion is to point out that if no agreement can be found we will just go to McDonalds... and not the good McDonalds either, but the dodgy one on *that* street, the one Fred said to avoid... Somebody must have a better suggestion (and the Anteater was the animal on the front of the O'Reilly book, hence my picking it... it being the only thing associated with Maven image wise) On 17 December 2013 15:28, Paul Benedict pbened...@apache.org wrote: I think the picture of an AntEater can feed into the which is better: ant vs maven? debate. I would opt not to possibly offend the Ant team. On Tue, Dec 17, 2013 at 9:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: A better looking anteater... http://people.apache.org/~stephenc/maven-logo-contest/maven-2.png http://people.apache.org/~stephenc/maven-logo-contest/screenshot-2.png I think that may exhaust the AntEater and downloading all the internet joke as far as my artistic ability can take it though I may try to rework the apache feather to fit better... and I could move off the tango colour palette that I have as my default in inkscape (it's default so that I can keep with the tango theme that Jenkins uses for icons) On 17 December 2013 13:45, Kristian Rosenvold kristian.rosenv...@gmail.comwrote: I'm speechless. Kristian 2013/12/17 Stephen Connolly stephen.alan.conno...@gmail.com the anteater sucking down the interwebs from apache using Tamás's text http://people.apache.org/~stephenc/maven-logo-contest/maven.png And a screenshot with it http://people.apache.org/~stephenc/maven-logo-contest/screenshot.png On 17 December 2013 13:38, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Meh! I was just trying to get something that would stir objections... hence the strange kerning! On 17 December 2013 12:46, Tamás Cservenák ta...@cservenak.net wrote: Don't want to stir too much here, but the http://oi41.tinypic.com/33bctw2.jpg is typographically incorrect (odd kerning and odd/different typeface). Long time ago I made vector based Maven logo (for Proximity site) that I thought I donated to Maven project... That one could serve as a great starting point for experiments, just get some vector drawing app (I used http://inkscape.org/en/to draw it long time ago). If not in ASF SVN, you can still access it from here (maven-logo.svg) https://github.com/cstamas/proximity1/tree/master/proximity-site-stuff/srcs HTH, ~t~ On Tue, Dec 17, 2013 at 12:24 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I came up with a silly logo just to kick things off: http://oi41.tinypic.com/33bctw2.jpg Here's how it looks with the fluido skin http://i39.tinypic.com/1zoz3v9.jpg And I am not suggesting that an Ant Eater standing on an Apache feather and slurping down the internet is the logo we should run with... it is a Worst
Re: New logo?
As a visual goes, I'd look for something like a beaver (who builds things) wearing geek eye-glasses (indicating 'it's a maven'). Maybe a Doozer (remember the Fraggles?): http://kaelajael.files.wordpress.com/2011/11/doozer2.jpg?w=350h=507 /Anders On Wed, Dec 18, 2013 at 10:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Tomcat... well they have a cat... fair enough Hadoop... has an elephant Hama has a hippo Solr has a sunrise Jackrabbit has a rabbit Chemistry has a test tube Openoffice has some abstract flying birds on a blue sky Karaf has a beaker with a feather on top ODE has a conductor with a feather instead of a batton Ant has the ant Flex has some strange abstract flexy thing Marmotta has a gopher Hive has an elephant-bee hybrid ... There is a limit to how many visually distinct animals you can render for a 75px tall image placeholder... But seriously, we just want something that is more than just our name in a fancy font. I think we need a mascot to help drive us onwards... -Stephen On 18 December 2013 13:27, Benson Margulies bimargul...@gmail.com wrote: A large, not very bright, species of deer that wears giant antlers and attacks what it doesn't understand. If that's what strikes you all as a great metaphor for us, Maven, or both, go right ahead. - 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: New logo?
I believe Sun set him free with a use with care sort of free license. /Anders On Wed, Dec 18, 2013 at 4:27 PM, Benson Margulies bimargul...@gmail.comwrote: who owns the copyright on Duke? On Dec 18, 2013, at 10:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Another option might be Duke, e.g. http://cs.anu.edu.au/student/comp6700/icons/DukeWithHelmet.png wearing a builders hat and replacing the helmet underarm with a Internet globe On 18 December 2013 15:20, Benson Margulies bimargul...@gmail.com wrote: Personally, I think we need a new POM version to drive us forward. As a visual goes, I'd look for something like a beaver (who builds things) wearing geek eye-glasses (indicating 'it's a maven'). On Wed, Dec 18, 2013 at 10:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Tomcat... well they have a cat... fair enough Hadoop... has an elephant Hama has a hippo Solr has a sunrise Jackrabbit has a rabbit Chemistry has a test tube Openoffice has some abstract flying birds on a blue sky Karaf has a beaker with a feather on top ODE has a conductor with a feather instead of a batton Ant has the ant Flex has some strange abstract flexy thing Marmotta has a gopher Hive has an elephant-bee hybrid ... There is a limit to how many visually distinct animals you can render for a 75px tall image placeholder... But seriously, we just want something that is more than just our name in a fancy font. I think we need a mascot to help drive us onwards... -Stephen On 18 December 2013 13:27, Benson Margulies bimargul...@gmail.com wrote: A large, not very bright, species of deer that wears giant antlers and attacks what it doesn't understand. If that's what strikes you all as a great metaphor for us, Maven, or both, go right ahead. - 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: Property namespaces Was: Changing JDK version without specifying maven-compiler-plugin version
Feel free to file a ticket suggesting a text update! It's the best way to ensure a change. /Anders (mobile) Den 28 nov 2013 20:41 skrev Mirko Friedenhagen mfriedenha...@gmail.com: Laird, your solution was very precise, I did not want to argue with your solution. However IMO maybe the plugin tutorial[0] should add a strong recommendation that parameter properties must always add a prefix :-). [0] http://maven.apache.org/guides/plugin/guide-java-plugin-development.html Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Nov 28, 2013 at 4:04 AM, Laird Nelson ljnel...@gmail.com wrote: On Wed, Nov 27, 2013 at 6:49 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: the only pity with using properties is that they are not namespaced most of the time (the maven.compiler.* ones being an exception here), output is claimed at least by three mojos IIRC. And skipTests is almost a general one but you may not easily specify that you do not want to run surefire but e.g. invoker tests nonetheless :-) Oh, agreed. This is just a convenient way to have the OP's problem solved in one shot with two lines of XML. Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: prepare maven-ear-plugin 2.9
One thing I've been confused about in the plugin docs is Required Parameters in the goal's page. For example here: C:\Users\KAHA14\workspace_juno_svnkit\maven-ear-plugin\target\site\ear-mojo.html Trying to think as a novice user I would assume that I would need to configured all of the required parameters. But in this case they already have defautl values, so I don't have to configure them. So are they really required? The problem here, I think, is that the technical required flag of the annotation is translated into the user perspective docs which is not correct if it has a default value. So, to bring this back to the topic of this thread, is this something that should be fixed in the ear plugin (remove the required=true from these params), or is it something that should be fixed in m-plugin-plugin? /Anders On Sat, Nov 16, 2013 at 4:49 PM, Robert Scholte rfscho...@apache.orgwrote: Hi, I'd like to release this plugin the coming week. If there are issues you'd like to fix for this release, let me know so I can wait until these fixes are added. Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5
You can't *install* Maven from the source code, only build it. Why do you need to build Maven from source? If you want to install Maven you should download the official distro: http://maven.apache.org/download.cgi /Anders On Wed, Nov 6, 2013 at 3:36 PM, Ed Mansky man...@mindspring.com wrote: Hi all, I am trying to install Maven from source code on a PowerMac G4 PPC 7450 running 10.4.11 and with Java JDK 1.5 and Ant 1.6.5 installed. I am getting an error from line #236 of build.xml (java.io.FileNotFoundException: ...full path to pom.properties file) Apparently the pom.properties file that is expected to be the bootstrap area for that target (compile-boot) to run, is missing. The missing file pom.properties is indeed located in the source code tree in: maven-core/src/test/resources/META-INF/maven/org.apache.maven/maven-core I am new to Maven, but it appears that an entry in maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is needed in order to get it copied over to the bootstrap area during the building of the target generate-sources. My environment variables are set as follows: JAVA_HOME = /Library/Java/Home ANT_HOME = /Developer/Java/Ant M2_HOME = /usr/local/maven-3.0.4 I also set M3_HOME = /usr/local/maven-3.0.4 in case that was needed instead of M2_HOME I do not have CLASSPATH defined at all. What am I missing here to get Maven to build? Any tips or hints would be greatly appreciated! Thanks, --Ed -- E. J. Mansky II Eikonal Research Institute Bend, Oregon - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Generated help mojo and dependency to plexus-util
In the docs of m-plugin-p [1] it says that the generated help mojo has a dependency to plexus-util. But I can't see that dependency in the generated code. Am I missing something obvious or is the docs incorrect? [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html /Anders
Re: Generated help mojo and dependency to plexus-util
you fixed the doc in http://jira.codehaus.org/browse/MPLUGIN-235 :) Oh my, don't even recall doing that... Thanks for keeping track of my work! :-) /Anders site is staged in http://maven.apache.org/plugin-tools-archives/plugin-tools-3.3-SNAPSHOT/maven-plugin-plugin/examples/using-annotations.html Regards, Hervé Le mardi 5 novembre 2013 22:41:49 Anders Hammar a écrit : In the docs of m-plugin-p [1] it says that the generated help mojo has a dependency to plexus-util. But I can't see that dependency in the generated code. Am I missing something obvious or is the docs incorrect? [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-anno tations.html /Anders - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Apache Maven Install Plugin 2.5.1 Released
Filed as a JIRA ticket: http://jira.codehaus.org/browse/MINSTALL-100 /Anders On Mon, Oct 21, 2013 at 8:07 AM, Grzegorz Slowikowski gslowikow...@gmail.com wrote: Fix installAtEnd description. Now it's: Whether every project should be deployed during its own deploy-phase or at the end of the multimodule build. If set to true and the build fails, none of the reactor projects is deployed Should be installed, not deployed. 2013/10/19 Robert Scholte rfscho...@apache.org The Apache Maven team is pleased to announce the release of the Apache Maven Install Plugin, version 2.5.1 This plugin is used during the install phase to add artifact(s) to the local repository. http://maven.apache.org/**plugins/maven-install-plugin/ http://maven.apache.org/plugins/maven-install-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.**plugins/groupId artifactIdmaven-install-**plugin/artifactId version2.5.1/version /plugin Release Notes - Maven Install Plugin - Version 2.5.1 ** Bug * [MINSTALL-98] - installAtEnd broken with parallel builds * [MINSTALL-99] - InstallAtEnd should respect plugin-configuration per project Enjoy, -The Apache Maven team --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Bartholdi Dominik as a new committer
Welcome Domi! Hack on, /Anders On Wed, Oct 16, 2013 at 4:57 AM, Olivier Lamy ol...@apache.org wrote: Hi all, Please welcome Bartholdi Dominik as a new committer of the Apache Maven project. The Apache Maven PMC has voted to grant committership to him. The account have already been set up and he can begin working on the Apache Maven code Domi, welcome to the team ! Have Fun -- The Apache Maven PMC - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core moving to 1.6
+1 for 3.2 (or greater) -1 for 3.1.x /Anders On Sat, Oct 5, 2013 at 1:00 PM, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, 5 October 2013, 9:35 Subject: Re: Maven Core moving to 1.6 +1 On Saturday, 5 October 2013, Jason van Zyl wrote: Given the vote we had about releases after September does anyone mind if I update the source/target levels to 1.6 for the core? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: http://jira.codehaus.org/browse/MSHARED-154 bug fix
Hi, You didn't attach anything to your mail. Also, it's much better to attach a patch or similar to the ticket itself than sending it to this mailing list. /Anders On Thu, Sep 26, 2013 at 8:40 AM, Denis Saponenko saponenko.de...@gmail.comwrote: Hello! I encountered a problem in work with maven war plugin in arhiver section (use maven archiver pluginhttp://maven.apache.org/shared/maven-archiver/). I found task http://jira.codehaus.org/browse/MSHARED-154 with my problem and I want to make a change. Changes attached to whis letter. I hope that after your comments and edits, this problem will be solved and will get the next version of the plugin. Thanks! Yours respectfully, Saponenko Denis - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Stupid Question about plugin annotations
Please file a JIRA ticket if you think something is wrong/could be improved! /Anders On Fri, Sep 20, 2013 at 8:18 AM, Robert Patrick robert.patr...@oracle.comwrote: I figured it out. It appears that in order to get the -Dparam=value to work, you *must* specify the @Parameter annotation's property element. Is this expected behavior? If so, the javadocs at http://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.htmlare a little misleading and/or incomplete. -- Robert Patrick HYPERLINK mailto:robert.patr...@oracle.com; robert.patr...@oracle.com VP, FMW Architects Team: The A-Team Oracle CorporationOffice: +1.940.725.0011 1148 Triple Crown Court Fax: +1.940.725.0012 Bartonville, TX 76226, USAMobile: +1.469.556.9450 A-Team Chronicles Blog: http://www.ateam-oracle.com/ HYPERLINK http://www.amazon.com/Professional-Oracle-WebLogic-Server-Patrick/dp/0470484306/Professional Oracle WebLogic Server by Robert Patrick, Gregory Nyberg, and Philip Aston with Josh Bregman and Paul Done Book Home Page: HYPERLINK http://www.wrox.com/WileyCDA/WroxTitle/Professional-Oracle-WebLogic-Server.productCd-0470484306.html http://www.wrox.com/ Kindle Version: HYPERLINK http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/ http://www.amazon.com/ From: Robert Patrick Sent: Friday, September 20, 2013 1:03 AM To: dev@maven.apache.org Subject: Stupid Question about plugin annotations It appears that the behavior for Maven plugins change depending on whether they use Javadoc-style annotations or Java annotations. With a plugin that uses Javadoc annotations, I can execute a plugin goal directly from the command-line and use -Dparam=value to pass in the configuration parameters (e.g., mvn rpatrick:my-plugin:1.0:my-goal -Dfoo=bar) and I see that the injection is happening properly so that the foo variable in the plugin has the value bar when executing. If I switch the plugin using the exact same code to use Java annotations, the injection is failing and foo is always null when the plugin executes.what am I missing? Sorry for the noise, Robert -- Robert Patrick HYPERLINK mailto:robert.patr...@oracle.com; robert.patr...@oracle.com VP, FMW Architects Team: The A-Team Oracle CorporationOffice: +1.940.725.0011 1148 Triple Crown Court Fax: +1.940.725.0012 Bartonville, TX 76226, USAMobile: +1.469.556.9450 A-Team Chronicles Blog: http://www.ateam-oracle.com/ HYPERLINK http://www.amazon.com/Professional-Oracle-WebLogic-Server-Patrick/dp/0470484306/Professional Oracle WebLogic Server by Robert Patrick, Gregory Nyberg, and Philip Aston with Josh Bregman and Paul Done Book Home Page: HYPERLINK http://www.wrox.com/WileyCDA/WroxTitle/Professional-Oracle-WebLogic-Server.productCd-0470484306.html http://www.wrox.com/ Kindle Version: HYPERLINK http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/ http://www.amazon.com/
Re: Stupid Question about plugin annotations
Actually, he needs to sign up on Codehaus Xircles. /Anders On Fri, Sep 20, 2013 at 9:06 AM, Lennart Jörelid lennart.jore...@gmail.comwrote: You can sign up for a JIRA account on the JIRA welcome page. You can find the respective JIRAs on http://maven.apache.org/issue-tracking.html
Re: Submitting a new maven plugin..
There is also the existing dependency:purge-local-repository goal that has some relationship. /Anders
Re: Maven archetype plugin - issue # 409
Sure, go for it. Create a patch and attach it to the jira ticket. /Anders (mobile) Den 23 jul 2013 16:58 skrev Gilles Seghaier gilles.segha...@gmail.com: Hi all, First of all STFB. My name is Gilles Seghaier, I'm a 25 years old french computer engineer working for TIBCO Sofware Inc. at Paris (France). I have developed with Maven since 2012, implementing some custom plugins to integrate my company solutions into Maven's ecosystem, helping developers in their daily tasks. I'm contacting you via this mailing list, because I didn't find another way to share with some Maven's developers (through JIRA for example). I would like to talk with you about Maven archetype plugin, especialy about a JIRA issue (#409 http://jira.codehaus.org/browse/ARCHETYPE-409). To summarize, this problem is about Maven partial archetype and integration testing with the specific goal provided by Maven archetype plugin. I have seen this issue is open for a while, and it's not expected to fix it in next releases. I would like to know if I might help you resolving this issue that do not require a big effort of coding. Thanks you all for the great job that have been already done on Maven :) Sincerly yours, Gilles Seghaier Direct: +33 (0)6 30 08 36 86 gsegh...@tibco.com / gilles.segha...@gmail.com
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
+1 (non-binding) /Anders (mobile) Den 23 jul 2013 16:00 skrev Stephen Connolly stephen.alan.conno...@gmail.com: This vote is to cover the minimum required version of Java for Maven Core. Maven Plugins produced by the Apache Maven Project that are flagged as compatible with older versions of Maven Core as their baseline will still require to stick to the minimum Java requirements of that Maven Core version. In other words, if for example maven-compiler-plugin advertises compatibility with Maven Core 2.0.11+ then that will still need to be compiled targeting Java 1.4 and only using dependencies that are aligned with that runtime requirement. Additionally patch releases to existing releases of Maven Core will not be subject to this requirement. For example [example]*if* this vote passes and *if* on Sep 29th we release Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security issue that affected all versions of Maven) then only Maven 3.3.0 would be require Java 6 as a minimum runtime requirement, the 2.0.12 release would still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would all still require Java 1.5.[/example] This is not a requirement that 3rd party plugins need use Java 6 as a minimum. Third party plugins are free to require any Java version = the corresponding Maven minimum requirement, though obviously from a users perspective it is best if plugins try to adhere to our contracts for corresponding versions of Maven Core. Justification for the cut-off date: * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still extended and sustaining support for existing Oracle customers using Java 5) * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are still with support, but there are other Java vendors for other platforms) * Apple no longer supports any hardware that does not have at least an Apple Java 6 version available. * Red Hat is providing support for OpenJDK 6 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. As I see it, that essentially ensures that for the vast majority of platforms there is a very strong likelihood of a Java 6 compatible version of Java available for that platform. Toolchains support or forking of the compiler and surefire can provide support for users who still need to build with older versions of Java (e.g., as was the case for Java 1.4.2 with Maven 2.2.1). Additionally users who are forced to use a java version older than Java 6 also are likely unable to upgrade their version of Maven, so this change will not affect them This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. from the PMC) and the majority of votes cast from committers will be required to pass this vote. +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? (This option is equivalent to +1 but provides people the ability to indicate an additional preference while not contributing to the inevitible noise) +1: Yes 0: No opinion -1: No -Stephen
Re: [VOTE] Retire Maven One Plugin
+1 (non-binding) /Anders (mobile) Den 20 jul 2013 11:13 skrev Dennis Lundberg denn...@apache.org: Hi, Now that we have Maven 1 at End-Of-Life, I think it's time to retire Maven One Plugin as well. It has been almost six years since the last release. I therefor propose that we retire maven-one-plugin. http://maven.apache.org/plugins/maven-one-plugin/ If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the retired area in Subversion. The process for retiring a plugin is described here, and is being improved: http://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire maven-idea-plugin
+1, non-binding /Anders (mobile) Den 19 jul 2013 19:01 skrev Dennis Lundberg denn...@apache.org: Hi It has been almost five years since I made the last release of maven-idea-plugin. The features in IDEA to integrate Maven has been greatly improved since then, making our own plugin obsolete. I therefor propose that we retire maven-idea-plugin. If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the retired area in Subversion. This is AFAIK the first vote to follow our process for retiring a plugin. For those interested, the process is described here: http://maven.apache.org/developers/retirement-plan-plugins.html [ ] +1 Yes, it's about time [ ] -1 No, because... -- Dennis Lundberg
Re: tags maven-3.1 vs maven-3.1.0
Isn't the convention way to omit the last zero? This has been done for Maven and all plugins/components before. No, we have 2.1.0 and 2.2.0 for the Maven core distro. Plugins would/could be a different story though. /Anders Mike --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0
Not yet tested but is there someone who could have a look at this one : https://jira.codehaus.org/browse/MNG-5492 This regression seems strange I can't reproduce that issue. Introducing an error in the global settings.xml makes Maven 3.1.0 fail on my MBP. /Anders On Wed, Jul 10, 2013 at 2:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 4 July 2013 20:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am withdrawing my -1 on the basis of the feedback I have received from legal-discuss. My vote is now +0 as I have not tested the distribution and I am waiting for somebody else on the PMC to do the running and make a call on whether we need to fix the NOTICE file for this release. I intend testing the distribution tomorrow unless this vote gets cancelled ;-) - Stephen On Thursday, 4 July 2013, Jason van Zyl wrote: Fair enough. On Jul 4, 2013, at 8:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I will let Barrie decide on whether we *have to* cancel this vote because of the issues he identified in the NOTICE file. Until I hear back from legal-discuss, I do not know whether the test data issue has any changes required, so I do not know whether (on the bits I am focusing) there is a requirement for us to respin yet, so from my point of view I am ok with keeping the vote open until I hear back from legal-discuss on the test data issue... but if Barrie's view is that with the current NOTICE we cannot release, then no choice but to cancel the vote now. I'd rather have a vote open to pester legal for a more prompt answer (from a bunch of volunteers on the 4th of July weekend) than have no vote to push them with. On 4 July 2013 13:54, Jason van Zyl ja...@tesla.io wrote: Then just make the changes you see fit and I'll roll it again. It will only take a few minutes. If we know what it should be like then we might as well just do it, as it's likely to take less time than asking if an exception can be made. I can cancel the vote. Make the changes you think are required for compliance and I'll cut it again. On Jul 4, 2013, at 6:05 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have asked the legal-discuss list for an opinion on test data sets and license headers. From my reading of the current ASF position: http://www.apache.org/legal/src-headers.html#faq-exceptions we do not currently have an exception for test data sets. Pending the outcome of that discussion I will have to be -1 If the outcome is that we do not need to do anything for test data sets, then I would be happy to switch to +1. If the outcome is that we need to add some additional text to the NOTICE files to cover the test data sets, then we will need to respin as nobody on the PMC can vote +1 if we are aware that the release is in violation of the ASF policies and we would be neglecting our governance role. If the outcome is that we need to add the license headers to all the test data files, then I think the PMC will have to review what we want to do as adding license headers to every file in the test data set runs the risk of invalidating the test data and that is an unnecessary risk that would cripple the project and as such I would be looking for the ASF to change such a decision and provide us with a means of using the NOTICE file to cover the test data. I hate being petty, but unfortunately that is part of the governance role that the PMC is tasked with... :-( - Stephen On 1 July 2013 03:56, Barrie Treloar baerr...@gmail.com wrote: On 1 July 2013 06:52, sebb seb...@gmail.com wrote: Another problem: the NOTICE file contains the following spurious text: = == NOTICE file corresponding to the section 4 d of == == the Apache License, Version 2.0, == == in this case for the Apache Maven distribution. == = We know what we are, but know not what we may be. -- Shakespeare -- Sent from my phone -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [VOTE] Apache 3.1.0
+1 (non-binding) Didn't try any of the new stuff explicitly though. /Anders On Sun, Jun 30, 2013 at 9:00 PM, Jason van Zyl ja...@tesla.io wrote: Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-084/ Staged distribution: https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/ Staged Site: http://maven.apache.org/ref/3.1.0 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: [jira] [Created] (MPOM-45) RPM Plugin does not check if rpm-build is installed prior to attempting to build RPMs
Could someone with JIRA karma please move this ticket to the Mojo's RPM Maven Plugin project? I don't have those privs it seems. /Anders On Tue, Jun 25, 2013 at 6:33 PM, Andres Danter (JIRA) j...@apache.orgwrote: Andres Danter created MPOM-45: - Summary: RPM Plugin does not check if rpm-build is installed prior to attempting to build RPMs Key: MPOM-45 URL: https://issues.apache.org/jira/browse/MPOM-45 Project: Maven POMs Issue Type: Improvement Components: maven-plugins Reporter: Andres Danter Priority: Minor This is something I recently ran into. The package for rpm-build was not installed on the system. The MAVEN RPM plugin did not give a very good verbose reason for why the RPM build failed. Currently, it echoes the string of commands it tried to run: [ERROR] Failed to execute goal org.codehaus.mojo:rpm-maven-plugin:2.0-beta-2:rpm (default-cli) on project accumulo: RPM build execution returned: '127' executing '/bin/sh -c cd /home/user/accumulo/accumulo-1.4.3/target/rpm/SPECS rpmbuild -bb --buildroot /home/user/accumulo/accumulo-1.4.3/target/rpm/buildroot --define '_topdir /home/user/accumulo/accumulo-1.4.3/target/rpm' --target amd64 accumulo.spec' A check of the availability of rpm-build prior to executing the above would have prevented some confusion. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Maven setting.xml
This mailing list is for developement of Maven itself (and the core plugins). You should send your question to the Maven users list or maybe even better the m2e users list as you seems to have problem with m2e and not Maven itself. /Anders On Thu, Jun 13, 2013 at 7:18 AM, RajaPrlabu rajapra...@gmail.com wrote: Hi, 1. i am new maven setup from eclipse juno.i have update m2eclipse in eclipse juno. 2.i have download manve 3.0.3. 3.i have copy from setting.xml file put in to C:\Users\rajaprak\.m2 Folder. 4.after eclipse maven usersetting choose the C:\Users\rajaprak\.m2\setting.xml file. 5.change for setting.xml file local rep path only change C:/Raja/maven-repo6.i am try to create maven project in eclipse can't be created.could you please what are steps following create maven project.can u pls help m.. how to change setting.xml...what are things compulsory changing Field. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-setting-xml-tp5759199.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
So what I am for is the following (example) (which does not re-use version numbers): So we have 3.2.12 (released as you currently do). New breaking API is encountered So you up the minor version - and create a RC release That version is 3.3.0-1 (the buildnumber is important) That fails due to some license not being present, so you release the next version 3.3.0-2 ... 3.3.0-3 ... 3.3.0-7 This passes the vote and the announce about apache maven 3.3.0 available for download goes onto the website and links to 3.3.0-7 After release some bugs are found, Next version is 3.3.1-nnn This is exactly what I use for my corporate customers. What is missing though is some nice Nexus staging rule to check that not more than one release (buildnumber) for a specific version can be released (promoted from staging) in Nexus. Would be nice to have to prevent mistakes (which do happen in the real world). /Anders What I am against is the following (which **also** does not re-use version numbers): So we have 3.2.12 (released as you currently do). New breaking API is encountered So you up the minor version - and create a RC release That version is 3.3.0 That fails due to some license not being present, so you release the next version 3.3.1 ... 3.3.3 ... 3.3.7 This passes the vote and the announce about apache maven 3.3.7 available for download goes onto the website (but there is no mention of 3.3.6 or any other prior 3.3.x) So I would not want to see (in released version) 3.2.12 - 3.3.7 - 3.3.16 - 3.4.7 Hope that makes it clearer. /James - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
+1 for pre-releases (RC, etc) -1 for actual releases (non-binding) /Anders On Thu, May 30, 2013 at 8:20 AM, Hervé BOUTEMY herve.bout...@free.frwrote: I agree with Dan and Wayne +1 for qualified releases (alpha, beta, RC, etc…) that are working toward the full blow release but aren't intended to be that. -1 for the actual releases. And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I care is that it is not alpha-1 any more since we're getting confused (votes, git tag copied in local copy) Regards, Hervé Le mercredi 29 mai 2013 14:52:45 Wayne Fay a écrit : Agree with Dan. +1 for qualified -1 for actual Wayne On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp dk...@apache.org wrote: +1 for qualified releases (alpha, beta, RC, etc…) that are working toward the full blow release but aren't intended to be that. -1 for the actual releases. Dan On May 29, 2013, at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedur e.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The archetype/archetype-catalog mess
Thanks Robert! /Anders On Wed, May 15, 2013 at 12:35 PM, Robert Scholte rfscho...@apache.orgwrote: @Anders, I've just done a huge commit for MMOCKRM-10, so you could give it a try. For the catalog, it expects a archetype-catalog.xml in the root of the repository, just as the real world. Robert Op Sat, 20 Apr 2013 17:20:04 +0200 schreef Robert Scholte rfscho...@apache.org: @Anders, I'm almost ready with MMOCKRM-10, but I'm hitting a chicken-egg problem: we both need to write IT's with a snapshot version of MRM and with the adjusted maven-archetype-plugin. I'll try to cover most with unittests and let's see what we want to release first. @Barrie, http://mojo.codehaus.org/mrm-**maven-plugin/examples/invoker-** tests.htmlhttp://mojo.codehaus.org/mrm-maven-plugin/examples/invoker-tests.htmlshould give you a good start. I'll add something about supported files and how to setup your mockrepo. Is there something else you'd like to see? Robert Op Fri, 19 Apr 2013 00:17:07 +0200 schreef Barrie Treloar baerr...@gmail.com: On 19 April 2013 03:56, Anders Hammar and...@hammar.net wrote: I can help with MMOCKRM-10 and its integration for the ITs, I've done it several times. That would be awesome. It's actually what has made me postpone this for a while. If you could update any docs with this information that would be helpful too. I haven't look at IT tests since there were at least three different choices... and all of them were black magic. --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Archetype registry file
What I can add: is that when I was developing archetypes a few years back,
the archetypes I developed did appear in that file. (my memory may be
wrong), but I do not ever remember adding them manually to the file.
Possibly that's how it worked in an older version of the plugin. I will
probably be doing lots of clean up and we'll see what pops up.
/Anders
Ate there hooks in install/deploy or the archetype plugin to do that?
Just a stab in the dark?!
-Chris
Sent from my iPhone
On 19/04/2013, at 7:04 PM, Anders Hammar and...@hammar.net wrote:
Right, and I've traced it to ArchetypeRegistryManager. The problem is
that
I can't see that it is ever used in the code, at least not for the
registry
stuff.
/Anders
On Fri, Apr 19, 2013 at 10:42 AM, Stuart McCulloch mccu...@gmail.com
wrote:
http://maven.apache.org/archetype/archetype-models/archetype-registry/archetype-registry.html
AFAICT it's related to which files get filtered when creating a project
from the archetype
On 19 Apr 2013, at 08:24, Anders Hammar wrote:
Does anyone know what a archetype registry file is? It's possible to
specify this for the create-from-project goal of the archetype plugin
and
the default location is ${user.home}/.m2/archetype.xml. Can't see
it's
being used anywhere though...
/Anders
-
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] Apache 3.1.0-alpha-1
Does anyone (Igor?) know if there is work going on to make Tycho work with this? /Anders On Fri, Apr 19, 2013 at 8:16 AM, Hervé BOUTEMY herve.bout...@free.frwrote: back to the vote +1 - maven-report-exec 1.1 makes m-site-p work with this release: no need to wait for m-site-p 3.3, we can add instructions on how to use p-site-p 3.x + maven- report-exec 1.1 like http://svn.apache.org/r1467751 - maven-dependency-tree 2.1-SNAPSHOT makes dependency:tree, shade and MPIr:dependencies work too, and I don't mind if the compoentn release hasn't been done for the moment, I prefer continue work on it to improve it as much as possible I didn't have time to test the release on much other components, but for the moment, I didn't found any other problem than the previous expected ones I hope experience from others is the same Regards, Hervé Le mardi 2 avril 2013 19:00:36 Hervé BOUTEMY a écrit : Staged documentation: http://maven.apache.org/ref/3.1.0-alpha-1/ Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version= 18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/ma ve n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Archetype registry file
Does anyone know what a archetype registry file is? It's possible to
specify this for the create-from-project goal of the archetype plugin and
the default location is ${user.home}/.m2/archetype.xml. Can't see it's
being used anywhere though...
/Anders
Re: Archetype registry file
Right, and I've traced it to ArchetypeRegistryManager. The problem is that
I can't see that it is ever used in the code, at least not for the registry
stuff.
/Anders
On Fri, Apr 19, 2013 at 10:42 AM, Stuart McCulloch mccu...@gmail.comwrote:
http://maven.apache.org/archetype/archetype-models/archetype-registry/archetype-registry.html
AFAICT it's related to which files get filtered when creating a project
from the archetype
On 19 Apr 2013, at 08:24, Anders Hammar wrote:
Does anyone know what a archetype registry file is? It's possible to
specify this for the create-from-project goal of the archetype plugin and
the default location is ${user.home}/.m2/archetype.xml. Can't see it's
being used anywhere though...
/Anders
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Archetype registry file
ARCHETYPE-433 filed to track this.
/Anders
On Fri, Apr 19, 2013 at 12:25 PM, Hervé BOUTEMY herve.bout...@free.frwrote:
I did some cleanup a few years ago when stabilizing the plugin, and
experience
showed that there is dead code that require investigation to really see if
it's dead or not. I missed this one, but there are AFAIK sufficient unit
and
integration tests to remove and check if it breaks something (that wasn't
the
case a few years ago...)
Regards,
Hervé
Le vendredi 19 avril 2013 10:21:41 Stuart McCulloch a écrit :
Ah, it was removed in favour of -Darchetype.properties=file
http://jira.codehaus.org/browse/ARCHETYPE-112
http://svn.apache.org/viewvc?view=revisionrevision=635711
So it looks like the local archetype registry file is no longer relevant.
On 19 Apr 2013, at 10:04, Anders Hammar wrote:
Right, and I've traced it to ArchetypeRegistryManager. The problem is
that
I can't see that it is ever used in the code, at least not for the
registry
stuff.
/Anders
On Fri, Apr 19, 2013 at 10:42 AM, Stuart McCulloch
mccu...@gmail.comwrote:
http://maven.apache.org/archetype/archetype-models/archetype-registry/arc
hetype-registry.html
AFAICT it's related to which files get filtered when creating a
project
from the archetype
On 19 Apr 2013, at 08:24, Anders Hammar wrote:
Does anyone know what a archetype registry file is? It's possible to
specify this for the create-from-project goal of the archetype plugin
and
the default location is ${user.home}/.m2/archetype.xml. Can't see
it's
being used anywhere though...
/Anders
-
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
The archetype/archetype-catalog mess
Currently, maven-archetype-plugin ignores the configured Maven infrastructure when fetching the archetype-catalog. That is, it is hard-coded to get the catalog from central. This causes problems in environments where Internet access is restricted and a MRM is used. Also, in cases where Internet is accessible I think the current behavior where configured repositories/mirrors are ignored is strange. I would expect my Maven configuration to be honored and the catalog to downloaded from my configured remote repos (incl. mirrors). Do anyone object if I do some drastic changes to this logic in the plugin? I'm thinking that the plugin should follow the Maven configuration and not have anything hard-coded in itself wrt where to get the archetype catalog(s) from. Related tickets are ARCHETYPE-427 and ARCHETYPE-358 primarily, but it touches on other ones as well. /Anders
Re: The archetype/archetype-catalog mess
I can help with MMOCKRM-10 and its integration for the ITs, I've done it several times. That would be awesome. It's actually what has made me postpone this for a while. /Anders Robert Op Thu, 18 Apr 2013 18:41:36 +0200 schreef Manfred Moser manf...@simpligility.com: You would be earning a lot of brownie points I am sure! There are a bunch of open questions around this and the perception that the archetype system is pretty much dead on stackoverflow and other places. This could fix a lot of those concerns.. manfred Currently, maven-archetype-plugin ignores the configured Maven infrastructure when fetching the archetype-catalog. That is, it is hard-coded to get the catalog from central. This causes problems in environments where Internet access is restricted and a MRM is used. Also, in cases where Internet is accessible I think the current behavior where configured repositories/mirrors are ignored is strange. I would expect my Maven configuration to be honored and the catalog to downloaded from my configured remote repos (incl. mirrors). Do anyone object if I do some drastic changes to this logic in the plugin? I'm thinking that the plugin should follow the Maven configuration and not have anything hard-coded in itself wrt where to get the archetype catalog(s) from. Related tickets are ARCHETYPE-427 and ARCHETYPE-358 primarily, but it touches on other ones as well. /Anders --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The archetype/archetype-catalog mess
Heck, we might even go v3.0 with this change and remove a lot of garbage that I've found in the code. And delete the create goal. :-) Maybe even require Maven 3.0+ to simplify the code. Or maybe that's taking this a little bit to far? /Anders On Thu, Apr 18, 2013 at 6:41 PM, Manfred Moser manf...@simpligility.comwrote: You would be earning a lot of brownie points I am sure! There are a bunch of open questions around this and the perception that the archetype system is pretty much dead on stackoverflow and other places. This could fix a lot of those concerns.. manfred Currently, maven-archetype-plugin ignores the configured Maven infrastructure when fetching the archetype-catalog. That is, it is hard-coded to get the catalog from central. This causes problems in environments where Internet access is restricted and a MRM is used. Also, in cases where Internet is accessible I think the current behavior where configured repositories/mirrors are ignored is strange. I would expect my Maven configuration to be honored and the catalog to downloaded from my configured remote repos (incl. mirrors). Do anyone object if I do some drastic changes to this logic in the plugin? I'm thinking that the plugin should follow the Maven configuration and not have anything hard-coded in itself wrt where to get the archetype catalog(s) from. Related tickets are ARCHETYPE-427 and ARCHETYPE-358 primarily, but it touches on other ones as well. /Anders - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] (MNG-5468) Allow mojos to access the user properties
Don't know if you can get all props in one go. But you can always define a read only parameter for the user property you want. @Parameter( property = user.prop, readonly = true ) private String userProp; /Anders On Sat, Apr 13, 2013 at 12:29 AM, Michael Ekstrand (JIRA) j...@codehaus.org wrote: Michael Ekstrand created MNG-5468: - Summary: Allow mojos to access the user properties Key: MNG-5468 URL: https://jira.codehaus.org/browse/MNG-5468 Project: Maven 2 3 Issue Type: Wish Affects Versions: 3.0.4 Reporter: Michael Ekstrand There does not seem to be any way to obtain the user properties in a mojo. The mojo can get the model properties from the project, but not the user properties specified on the Maven command line. This is problematic for mojos that want to consult them for additional configuration to pass on to other things (user classes, scripts, etc.). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Apache CMS UI
The instructions says navigate to https://cms.apache.org/maven to edit the web site. But I get a 404 for the URL. Should it work or is it the wrong URL? /Anders
Re: Apache CMS UI
I get a json answer. Not the UI I was expecting...:-) /Anders On Wed, Apr 10, 2013 at 9:16 AM, Olivier Lamy ol...@apache.org wrote: try https://cms.apache.org/maven/ I have just fixed that in the documentation. 2013/4/10 Anders Hammar and...@hammar.net: The instructions says navigate to https://cms.apache.org/maven to edit the web site. But I get a 404 for the URL. Should it work or is it the wrong URL? /Anders -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
