[jira] Commented: (MNG-3358) Require explicit plugin versions
[ http://jira.codehaus.org/browse/MNG-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119530 ] Nick Stolwijk commented on MNG-3358: This is exactly what the enforcer plugin can do. I don't think that Maven itself should do it. > Require explicit plugin versions > > > Key: MNG-3358 > URL: http://jira.codehaus.org/browse/MNG-3358 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Paul Gier > > Currently plugin versions are not required in the pom which causes maven to > use the latest version of each plugin to be used when building a project. > The problem with this system is that builds can break (without any change to > the project itself) if a new version of a plugin is released. This can cause > confusion among developers because the build appears to break for no reason. > It also makes reproducing old builds to be more difficult because a newer > version of a plugin could cause some aspect of the build to be different than > when it was originally released. > SUREFIRE-61 is one example of where this happened. When surefire 2.3.1 was > released, it affected the testing of some builds because the classpath > ordering changed. > My suggestion for fixing this is to require a version for all plugins. This > is already a best practice among many maven users, but it is not enforced by > maven itself. For the default lifecycle plugins (compiler plugin, surefire > plugin, etc.) maven should tie it's version to specific default versions of > the plugins. These could then be overridden when necessary. > This change probably belongs in 2.1 since it is too big a change for 2.0.9. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-314) Prepare goal - set default values
Prepare goal - set default values --- Key: MRELEASE-314 URL: http://jira.codehaus.org/browse/MRELEASE-314 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-8 Reporter: Alessandro Zucchi Hi all, I'm trying to simplify the release process of my project. I run the following command: call mvn -DpreparationGoals=clean,install -DautoVersionSubmodules=true release:clean release:prepare Since my project have dependences against other projects (SNAPSHOT dependeces) I get the following question: "There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no:" I have to answer yes to change the default and from this point over accept all defaults prompted. The question is: can I change, in same way, the above default so I can use --batch-mode ??? Consider that I can't change manuallly the dependences before to start the release prepare process. Best regards. Alex -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-315) Prepare goal - set default values
Prepare goal - set default values --- Key: MRELEASE-315 URL: http://jira.codehaus.org/browse/MRELEASE-315 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-8 Reporter: Alessandro Zucchi Hi all, I'm trying to simplify the release process of my project. I run the following command: call mvn -DpreparationGoals=clean,install -DautoVersionSubmodules=true release:clean release:prepare Since my project have dependences against other projects (SNAPSHOT dependeces) I get the following question: "There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no:" I have to answer yes to change the default and from this point over accept all defaults prompted. The question is: can I change, in same way, the above default so I can use --batch-mode ??? Consider that I can't change manuallly the dependences before to start the release prepare process. Best regards. Alex -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-52) Change type of plugin parameter "outputDirectory" to java.io.File
[ http://jira.codehaus.org/browse/MRESOURCES-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MRESOURCES-52: Attachment: resources.zip Attached is now a mini project for you to experience this bug yourself. Just extract the archive. Then call Maven from a working directory that is not equal to the base directory of the project, e.g. issue "cd .." and then "mvn -f resources/pom.xml". You will notice that the resources get placed into the current working directory instead of the project's base directory. > Change type of plugin parameter "outputDirectory" to java.io.File > - > > Key: MRESOURCES-52 > URL: http://jira.codehaus.org/browse/MRESOURCES-52 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Assignee: Milos Kleint > Fix For: 2.3 > > Attachments: output-directory.patch, resources.zip > > > As described by MNG-3273, using java.lang.String for path parameters is > discouraged as it usually leads to relative paths being resolved against the > current working directory instead of the project's base directory. This bug > manifest itselfs when a user explicitly configures the maven-resources-plugin > with a relative output directory and then runs the build from a different > working directory (for example, the base directory of an aggregator parent). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRESOURCES-52) Change type of plugin parameter "outputDirectory" to java.io.File
[ http://jira.codehaus.org/browse/MRESOURCES-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MRESOURCES-52: - Milos, this issue is NOT a duplicate of MRESOURCES-32, it is just another incarnation of the same problem. I thought pointing at MNG-3273 would make this clear. > Change type of plugin parameter "outputDirectory" to java.io.File > - > > Key: MRESOURCES-52 > URL: http://jira.codehaus.org/browse/MRESOURCES-52 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Assignee: Milos Kleint > Fix For: 2.3 > > Attachments: output-directory.patch, resources.zip > > > As described by MNG-3273, using java.lang.String for path parameters is > discouraged as it usually leads to relative paths being resolved against the > current working directory instead of the project's base directory. This bug > manifest itselfs when a user explicitly configures the maven-resources-plugin > with a relative output directory and then runs the build from a different > working directory (for example, the base directory of an aggregator parent). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-41) Easy access to dependency jars
[
http://jira.codehaus.org/browse/MANTRUN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119538
]
Roman Urich commented on MANTRUN-41:
I have fixed this problem so:
class AbstractAntMojo:
...
107 /* set maven.plugin.classpath with plugin dependencies */
antProject.addReference( "maven.plugin.classpath",
getPathFromArtifacts( pluginArtifacts, antProject ) );
+
+if (pluginArtifacts != null) {
+for (Iterator i = pluginArtifacts.iterator();
i.hasNext();) {
+Artifact a = (Artifact) i.next();
+File file = a.getFile();
+if (file == null) {
+throw new
DependencyResolutionRequiredException(a);
+}
+
+String id = "maven:" + a.getGroupId() +
":" + a.getArtifactId() + ":" + a.getType();
+// String id = "maven:" +
a.getGroupId() + ":" + a.getArtifactId() + ":" + a.getBaseVersion() + ":" +
a.getType();
+Path path = new Path(antProject);
+path.setPath(file.getPath());
+antProject.addReference(id, path);
+}
+}
...
Usage (pom.xml):
...
ponton.product.maven.plugins
maven-antrun-plugin
my.group.id
my.artifact.id
my.version
package
run
...
> Easy access to dependency jars
> --
>
> Key: MANTRUN-41
> URL: http://jira.codehaus.org/browse/MANTRUN-41
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Patrick Lightbody
>Assignee: Kenney Westerhof
> Fix For: 1.2
>
> Attachments: MANTRUN-41-maven-antrun-plugin.patch
>
>
> It would be nice to have an easy access to the dependency jars located in
> ~/.m2. A couple ideas tossed around in #maven were:
> ${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
> OR
> a new Ant task:
>
> Where you could then reference ${jarpath}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3296) mvn.bat looses error code on windows NT type platforms
[
http://jira.codehaus.org/browse/MNG-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-3296:
-
Fix Version/s: 2.1-alpha-1
2.0.9
> mvn.bat looses error code on windows NT type platforms
> --
>
> Key: MNG-3296
> URL: http://jira.codehaus.org/browse/MNG-3296
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 2.0.7
>Reporter: Matthias Kerkhoff
> Fix For: 2.0.9, 2.1-alpha-1
>
>
> There is a bug in the mvn.bat script that prevents that an error code is
> properly returned to the caller of the script.
> The batch script executes the following lines after maven has been invoked if
> an error occurs:
> if ERRORLEVEL 1 goto error
> :error
> set ERROR_CODE=1
> :end
> if "%OS%"=="Windows_NT" goto endNT
> :endNT
> @endlocal
> if exist "%HOME%\mavenrc_post.bat" call "%HOME%\mavenrc_post.bat"
> if "%MAVEN_BATCH_PAUSE%" == "on" pause
> if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE%
> exit /B %ERROR_CODE%
> The problem is the endlocal statement. Calling endlocal ends the scope in
> which ERROR_CODE was set to 1. The previous value of ERROR_CODE will be
> reinstantiated (which is always 0, see line 46).
> To fix the problem make the ERROR_CODE value known in the outer ("global")
> scope by changing the endlocal statement into
> @endlocal & set ERROR_CODE=%ERROR_CODE%
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3320) Avoid perm gen space out of memory errors
[ http://jira.codehaus.org/browse/MNG-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-3320: - Fix Version/s: 2.1-alpha-1 > Avoid perm gen space out of memory errors > - > > Key: MNG-3320 > URL: http://jira.codehaus.org/browse/MNG-3320 > Project: Maven 2 > Issue Type: Wish > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Cédric Munger >Priority: Minor > Fix For: 2.1-alpha-1 > > Attachments: mavenEmbedder.txt > > > Each maven embedder instance is using his own classworld, the problem is that > the creation of multiple maven embedder instances can lead to perm gen space > errors, since each embedder classworld is filling the perm gen space memory > area with new classes, out of memory errors can occurs quite easily. For > some unknown reasons, this memory is never garbaged collected (at least on an > MacOSX 1.5.0 JVM). A Shared classworld between all embedder object instances > could avoid this potential problem. A modification of the 2.1 embedder API to > choose between these 2 modes (own classworld or shared) could be a good thing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3354) mvn.bat incorrectly detects OS on Windows NT or XP with Novell login
[ http://jira.codehaus.org/browse/MNG-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-3354: - Fix Version/s: 2.1-alpha-1 2.0.9 > mvn.bat incorrectly detects OS on Windows NT or XP with Novell login > > > Key: MNG-3354 > URL: http://jira.codehaus.org/browse/MNG-3354 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Jaroslaw Bojar > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: mvn.bat, mvnDebug.bat > > > On Windows NT or XP with Novell Client Login mvn.bat incorrectly selects OS > as Win9x, because Novell sets OS environment variable to WINNT instead of > Windows_NT. > As a result it processes command line arguments as in windows 9x, what is > very inconvenient because all arguments with = (equals) sign must be quoted > on command line. For example -DdownloadSources=true must be quoted as > "-DdownloadSources=true". > The reason for such behaviour is that mvn.bat checks in several places if > "%OS%"=="Windows_NT" and this statement yields false on windows with novell > login. On winnt with novell login OS is set to WINNT instead of Windows_NT. > I attached corrected mvn.bat and mvnDebug.bat that check additionally for > "%OS%"=="WINNT". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3331) Normalize paths to sub modules
[
http://jira.codehaus.org/browse/MNG-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-3331:
-
Fix Version/s: 2.1-alpha-1
2.0.9
> Normalize paths to sub modules
> --
>
> Key: MNG-3331
> URL: http://jira.codehaus.org/browse/MNG-3331
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: normalized-module-file.patch
>
>
> When collecting the sub modules during a reactor build, the path to the
> module POMs should always be normalized. Currently, this happens only on a
> Windows platform via File.getCanonicalFile(). The attached patch adds
> normalization (but not canonicalization) for other platforms, too.
> The motivation: Consider a multi module project with the following directory
> structure:
> project/
> project-parent/
> project-module/
> such that the parent POM in project-parent will contain
>../project-module
> to reference the sub module. Simple string/path concatenation will therefore
> deliver a path like
>{SNIP}/project-parent/../project-module
> for the sub module. Having
> {SNIP}/project-module
> instead is surely better, and may it be just for nice log output.
> However, certain plugins/tools try to detect symlinks by comparing the
> canonicalized path with the absolute path of a file. While users of
> DirectoryScanner are usually fine because this class always canonicalizes the
> base directory before the check, code that does not know about a base
> directory but simply gets a single file will erroneously detect a symlink
> because ".." gets removed during canonicalization.
> This actually happens with the CpdReport of the maven-pmd-plugin. See
> [CPD.addFile(int,
> File)|http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/src/net/sourceforge/pmd/cpd/CPD.java?view=markup]
> for the cause, i.e. the code near line 97 where it prints "Skipping {file}
> since it appears to be a symlink".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2178) incorrect M2_HOME guess in mvn.bat
[ http://jira.codehaus.org/browse/MNG-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-2178: - Fix Version/s: (was: 2.0.x) 2.1-alpha-1 2.0.9 > incorrect M2_HOME guess in mvn.bat > -- > > Key: MNG-2178 > URL: http://jira.codehaus.org/browse/MNG-2178 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.2 > Environment: WXP >Reporter: Jörg Henne > Fix For: 2.0.9, 2.1-alpha-1 > > > mvn.bat contains the following lines: > :chkMHome > if not "%M2_HOME%"=="" goto valMHome > if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\.. > if not "%M2_HOME%"=="" goto valMHome > Guessing M2_HOME=%~dps0\.. leads to complaints later on, since the script > expects m2.bat in bin/...: > if exist "%M2_HOME%\bin\m2.bat" goto init > Hence, the line should read: > if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\..\.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MNG-3321.
Assignee: Vincent Siveton
Resolution: Duplicate
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Assignee: Vincent Siveton
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3280) Keep getting required artifacts are missing when compiling geotool using maven
[ http://jira.codehaus.org/browse/MNG-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-3280. Assignee: Vincent Siveton Resolution: Cannot Reproduce > Keep getting required artifacts are missing when compiling geotool using maven > -- > > Key: MNG-3280 > URL: http://jira.codehaus.org/browse/MNG-3280 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7 >Reporter: F. Ahmed >Assignee: Vincent Siveton > > Missing: > -- > 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, > if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file \ > > -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) org.geotools:gt2:pom:2.3.3 > 2) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > 2) org.codehaus.plexus:plexus-utils:jar:1.1 > > Try downloading the file manually from the project website. > Then, install it using the command: > > mvn install:install-file -DgroupId=org.codehaus.plexus > -DartifactId=plexus-utils \ > > -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, > if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.codehaus.plexus > -DartifactId=plexus-utils \ > > -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file \ > > -Durl=[url] -DrepositoryId=[id] > Path to dependency: > > 1) org.geotools:gt2:pom:2.3.3 > 2) org.codehaus.plexus:plexus-utils:jar: > 1.1 > -- > 2 required artifacts are missing. > for artifact: > org.geotools:gt2:pom:2.3.3 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > > ibiblio (http://www.ibiblio.org/maven2), > > refractions (http://lists.refractions.net/m2), > > geotools (http://maven.geotools.fr/repository) > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 50 minutes 54 seconds > [INFO] Finished at: Sun Oct 28 11:35:51 AST 2007 > [INFO] Final Memory: 10M/197M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2822) links to same host with port are messed up
[ http://jira.codehaus.org/browse/MNG-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-2822. Assignee: Vincent Siveton Resolution: Cannot Reproduce Cannot reproduce with mvn 2.0.8 and maven-site-plugin:2.0-beta-6 > links to same host with port are messed up > -- > > Key: MNG-2822 > URL: http://jira.codehaus.org/browse/MNG-2822 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.4 >Reporter: Patrick Huber >Assignee: Vincent Siveton > Fix For: Reviewed Pending Version Assignment > > > we have a devserver where out project site and a continuum run > site: http://host/ > continuum: http://host:8010/continuum > now when we add a link to the continuum > http://host:8010/continuum"/> > on the generated site, we get a link like this: > http://host/:8010/continuum";>Continuum -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2947) Deploy 3rd party source jar
[ http://jira.codehaus.org/browse/MNG-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-2947. Assignee: Vincent Siveton Resolution: Fixed fixed guide-3rd-party-jars-remote.apt in r611174 removed old guide-deploying-3rd-party-jars.html on the website > Deploy 3rd party source jar > --- > > Key: MNG-2947 > URL: http://jira.codehaus.org/browse/MNG-2947 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Affects Versions: 2.0.6 >Reporter: Daniel Siegmann >Assignee: Vincent Siveton >Priority: Minor > Fix For: Documentation Deficit > > > There is a guide to deploying 3rd party jars to a remote repository [1], > using deploy:deploy-file. This guide does not mention how source jars can be > deployed along with the code jar. A section should be added to the end of > this guide providing a quick explanation. > Here is an example of what such documentation might look like: > *Deploying Source Jars* > To deploy a 3rd party source jar, packaging should be set to "java-source", > and generatePom should be set to false. > [1] http://maven.apache.org/guides/mini/guide-deploying-3rd-party-jars.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-3119: - Fix Version/s: (was: 2.0.x) Reviewed Pending Version Assignment > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: Reviewed Pending Version Assignment > > Attachments: MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119589 ] Benjamin Bentmann commented on MNG-3118: While I agree that having a documentation would be nice, it does not prevent the bugs from reoccurring. What you really want are tests. Therefore, you are invited to vote for MNG-2365 and SUREFIRE-428. > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1890) JasperReports 2.0.3 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodor Danciu closed MAVENUPLOAD-1890. -- Resolution: Incomplete Hit submit button too soon. Please ignore. Thank you, Teodor > JasperReports 2.0.3 upload > -- > > Key: MAVENUPLOAD-1890 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1890 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1891) JasperReports 2.0.4 upload
JasperReports 2.0.4 upload -- Key: MAVENUPLOAD-1891 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1891 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sf.net/maven/jasperreports-2.0.4-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1890) JasperReports 2.0.3 upload
JasperReports 2.0.3 upload -- Key: MAVENUPLOAD-1890 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1890 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2747) Maven doesn't detect invalid dependency descriptions in the pom
[ http://jira.codehaus.org/browse/MNG-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-2747. Assignee: Vincent Siveton Resolution: Duplicate see MNG-2391 > Maven doesn't detect invalid dependency descriptions in the pom > --- > > Key: MNG-2747 > URL: http://jira.codehaus.org/browse/MNG-2747 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 > Environment: Ubuntu 6.10 >Reporter: Tim Kettler >Assignee: Vincent Siveton > Fix For: 2.x > > Attachments: testpom.tgz > > > Maven doesn't detect that the following pom snippet is not valid: > [...] > > jdom > jdom > 1.0 > > [...] > if 'mvn compile' is run on the included test project, this is what happens: > [EMAIL PROTECTED]:~/Develop/testpom$ mvn compile > [INFO] Scanning for projects... > [INFO] > > [INFO] Building testproject > [INFO]task-segment: [compile] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 1 source file to /home/tik/Develop/testpom/target/classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > /home/tik/Develop/testpom/src/main/java/TestClass.java:[1,16] package > org.jdom does not exist > /home/tik/Develop/testpom/src/main/java/TestClass.java:[5,12] cannot find > symbol > symbol : class Element > location: class TestClass > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Mon Jan 08 19:23:14 CET 2007 > [INFO] Final Memory: 3M/8M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-151) Documentation for the assembly plugin is utterly confusing
[
http://jira.codehaus.org/browse/MASSEMBLY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119565
]
Tuomas Kiviaho commented on MASSEMBLY-151:
--
Interpolation precedence,
Current description of outputFileNameMapping did not give any clues that such
prefixes as 'module.' 'artifact.' and 'pom.' existed. There aren't any examples
of how to reference artifact at hand. outputDirectory has also similar extra
features available, but they are not documented on site.
I just spent some time to discover the semantics from within source code where
they were well documented
(org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils) but for general
documentation too technically oriented as-is. Following version removal example
could be added to including-and-excluding-artifacts.apt
...
${artifact.artifactId}${dashClassifier?}.${artifact.extension}
..
> Documentation for the assembly plugin is utterly confusing
> --
>
> Key: MASSEMBLY-151
> URL: http://jira.codehaus.org/browse/MASSEMBLY-151
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: Nigel Magnay
> Fix For: 2.2-beta-2
>
>
> This is going to come across as a whinge, I'm afraid, but the assembly plugin
> is a fairly important vital component in M2; I find it very confusing and
> I've been using it for a bit. I have observed it putting off other people
> from using m2 at all, which is I think a shame.
> I'd document it myself, but I don't understand the differences between some
> of the goals (and I don't understand why the fix in MASSEMBLY-97 is
> neccessary).
> In the goals page,there's lots of options that seem to overlap or do the same
> thing. There's no clue (other than trial and error) as to why some of them
> will work some times, and some will not (e.g. in multiproject builds). What's
> worse is some of the problems only appear in specific circumstances (E.g.
> doing multiprojects in a 'clean' build').
> This either needs documenting, or (better), fixing in the code. We have (from
> the site):
> assembly:assemblyAssemble an application bundle or distribution
> from an assembly descriptor.
> Good, seems logical to me
> assembly:unpack Unpack project dependencies. Currently supports
> dependencies of type jar and zip.
> The reverse. Yep.
> assembly:attached Assemble an application bundle or distribution from an
> assembly descriptor. Do not specify a phase, so make it usable in a reactor
> environment where forking would create issues.
> Erk? How should a user read this? To me "usable in a reactor environment
> where forking would create issues" reads to me as "there's a bug in
> assembly:assembly if used in a multiproject build".
> - it assumes that the user knows a multi project build is a 'reactor' build
> - why can't assembly:assembly be fixed so it does work in multiproject
> builds? Why can't it detect the environment, and do the 'right thing' (or at
> the very least spit out a warning) ?
> This is just inviting the user to pick the wrong goal.
> assembly:directoryAssemble an application bundle or distribution.
> Without a descriptor? If I click the link to the goal parameters for this or
> for assembly:assembly, I get identical pages of parameters. How is this
> different?
> assembly:directory-inline Assemble an application bundle or distribution
> from an assembly descriptor without launching a parallel lifecycle build.
> In what scenarios would I as a user need this? Is it for a bug workaround?
> Would it not be better as a parameter to turn off/on "parallel lifecycle
> build" ?
> assembly:single Assemble an application bundle or distribution from an
> assembly descriptor. Do not specify a phase, so make it usable in a reactor
> environment where forking would create issues. Do not specify it as an
> aggregator, so it is only for a single project. Both cases aid it in working
> around issues with the Maven lifecycle that should be addressed in Maven 2.1.
> A whole heap of information that seems to boil down to "there is a bug", and
> a heap of confusing terminology ("do not specify it as an aggregator").
> When should this be used ? Every time you actually want assembly:assembly in
> a multiproject build? How is it different to assembly:attached?
> It seems to me that the plugin does 2 things. (pack things, unpack things).
> All these additional goals seem to be (I can't tell this) workarounds for
> bugs.
> Why can't we just have
> assembly:assembly
> and
> assembly:unpack
> and make the plugin work properly? If multiproject builds fail on fork, then
> stop the plugin from forking until it can be fixed (o
[jira] Created: (SUREFIRE-428) Add integration test to check class path order
Add integration test to check class path order -- Key: SUREFIRE-428 URL: http://jira.codehaus.org/browse/SUREFIRE-428 Project: Maven Surefire Issue Type: Task Reporter: Benjamin Bentmann Attachments: classpath-order-it.patch The attached integration test checks some ordering constraints on the class path for testing: - test-classes should come before main-classes - main-classes should come before dependencies It might not catch all bad cases but currently there seems to be nothing that prevents regression of MNG-3118 or SUREFIRE-61 and this test at least tells you that Surefire-2.3 is broken. In concern of quality assurance, I would also like to mention that MNG-2365 has an unapplied patch that provides a unit test for MNG-3118. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier reopened MNG-3321:
I don't think this is a duplicate of MNG-3102. While the two issues are
related, they are not the same. I would like to be able to skip certain
plugins and/or executions of plugins from the command line without having to
modify the pom.
This could be used for things like running only one of several surefire
configurations (yes, I know this can be done with profiles, but it would be a
lot cleaner this way IMO), or skipping just the test part of the build but
still compiling the tests.
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Assignee: Vincent Siveton
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1892) SableCC 3.2 upload
SableCC 3.2 upload -- Key: MAVENUPLOAD-1892 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892 Project: maven-upload-requests Issue Type: Improvement Reporter: Paul Donohue http://psd.umd.edu/sablecc-3.2-bundle.jar http://www.sablecc.org/ I am not a developer for SableCC. SableCC 3.1 is currently in the repository. SableCC 3.2 was released ~3 years ago, and is still the latest stable version (the unstable version 4.0 is still under active development). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-29) Enforcer complains about its own version
Enforcer complains about its own version
Key: MENFORCER-29
URL: http://jira.codehaus.org/browse/MENFORCER-29
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Plugin
Affects Versions: 1.0
Environment: GNU/Linux
Reporter: Hilco Wijbenga
Assignee: Brian Fox
Attachments: pom.xml
The attached POM uses the latest version of the Enforcer (revision 611262),
i.e. 1.0-SNAPSHOT. I've called it 1.0-Local-1, so that's what's defined in the
POM.
If I use the Enforcer normally, without a profile, everything works
beautifully. The attached POM, however, tries to use the Enforcer from a
profile ("enforce"). If you now try something like "mvn compile -Penforce" it
complains about its own version not being set, even though it's specified
*twice*.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-276) Links on Modules are completely broken on site:stage
[ http://jira.codehaus.org/browse/MSITE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119608 ] Eric Dalquist commented on MSITE-276: - I see this problem as well. Module links generated by site:stage and site-deploy are broken. Reverting to 2.0-beta-5 solves the issue: Add the following plugin to the in your root POM org.apache.maven.plugins maven-site-plugin 2.0-beta-5 > Links on Modules are completely broken on site:stage > > > Key: MSITE-276 > URL: http://jira.codehaus.org/browse/MSITE-276 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Jörg Hohwiller > > The latest maven-site-plugin 2.0-beta-6 seems to to introduce a new bug that > was NOT present in 2.0-beta-5: > Now all my modules point to the same url which is > "../../opt/project/build/development/projects/../dummyhost.de" > Something goes very wrong here: > 1. The link should not contain pathnames specific for the environment where > it was build (/opt/project/build/development/projects) nor the hostname and > path of the distributionManagement. > 2. The modulename itself is totally lost and all module-links in the menu > have the same href > Whatever has happend here, made it a lot worse. The site is now totally > unuseable. > It seems that only mvn site was tested before the 2.0-beta-6 was released. > Multimodule-Builds need to be tested with site:stage or site:deploy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3361) Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit
Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit Key: MNG-3361 URL: http://jira.codehaus.org/browse/MNG-3361 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Reporter: Paul Hammant [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 minutes 25 seconds [INFO] Finished at: Fri Jan 11 08:49:42 PST 2008 [INFO] Final Memory: 14M/29M [INFO] [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1359802395.commit --targets /tmp/maven-scm-28211-targets [INFO] Working directory: /scm/oss/jremoting/root/trunk [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: MKACTIVITY of '/jremoting/!svn/act/c136e17a-8ec7-44c4-a326-b2611ec72ffc': authorization failed (https://svn.codehaus.org) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-567) WS Common POM v1.0.1 has a compile time dependency on JUnit
WS Common POM v1.0.1 has a compile time dependency on JUnit --- Key: MEV-567 URL: http://jira.codehaus.org/browse/MEV-567 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Vincent Massol WS Common POM v1.0.1 has a compile time dependency on JUnit. It should be declared using a test scope instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1893) please upload the new jdeb 0.6 release
please upload the new jdeb 0.6 release -- Key: MAVENUPLOAD-1893 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1893 Project: maven-upload-requests Issue Type: Bug Reporter: Torsten Curdt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1851) Please add antlr's gunit
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119610 ] Kenny MacDermid commented on MAVENUPLOAD-1851: -- Version updated on the antlr wiki. New bundle is available at: http://code.kmdconsulting.ca/gunit.git/gunit-1.0.1-bundle.jar Kenny > Please add antlr's gunit > > > Key: MAVENUPLOAD-1851 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1851 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Kenny MacDermid > > Hello, > I would like to have version 1.0 of antlr's gunit added to the repository. > I have confirmed with Terrence Parr and the original gunit author Leon Su > that I can make this request. > I'm hosting version 1.0 of the source code in a git repository at: > http://code.kmdconsulting.ca/gunit.git > I will be actively modifying this project to add a set of unit tests and > extend the functionality. I will further expand the pom.xml when I do so that > it more closely matches the required repository format, and can hopefully > sync directly after that point. > If you want confirmation from Terence please email him directly. > If you don't want to use my cleaned up version of the code, it's also > available in a in a jar (with the src in the jar) at: > http://www.antlr.org/wiki/display/ANTLR3/gUnit+-+Grammar+Unit+Testing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-261) Local Parent POM not found if specifies a directory
[
http://jira.codehaus.org/browse/MSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119609
]
Keith Naas commented on MSITE-261:
--
This actually causes a major issue in a continuous build environment if you try
to run the site goal as part of the build. Since the project hasn't been
deployed to the remote repo yet, the site plugin attempts to access it on the
remote repo and the build fails.
The workaround is to run the build once without generating the site so that the
artifacts get into the repo. Then add the site goal later. Of course, the
site goal ends up using the last builds parent pom.xml, but normally its pretty
close.
> Local Parent POM not found if specifies a directory
> --
>
> Key: MSITE-261
> URL: http://jira.codehaus.org/browse/MSITE-261
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP SP2
>Reporter: Benjamin Bentmann
>Priority: Minor
> Attachments: site-parent-pom.patch
>
>
> The Maven core allows to specify a directory for the element
> in a module POM to locate the parent POM, e.g.{code:xml}
> ...
> ../parent
> {code}will properly find the parent POM in "../parent/pom.xml".
> However, the Site plugin does not follow this lookup strategy:{code}
> [INFO] [site:site]
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file '[SNIP]\..\parent'. for project unknown
> [INFO] Parent project loaded from repository.{code}
> This log output is actually from 2.0-beta-6-SNAPSHOT, 2.0-beta-5 outputs a
> different message but fails, too.
> The attached patch fixes this although I wonder whether this functionality is
> not already included somewhere in the Maven core (where is belongs IMHO).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3358) Require explicit plugin versions
[ http://jira.codehaus.org/browse/MNG-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MNG-3358. -- Resolution: Won't Fix You're right, this feature of the enforcer fits my needs. Closing this issue since this feature is not needed once enforcer 1.0 is released. > Require explicit plugin versions > > > Key: MNG-3358 > URL: http://jira.codehaus.org/browse/MNG-3358 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Paul Gier > > Currently plugin versions are not required in the pom which causes maven to > use the latest version of each plugin to be used when building a project. > The problem with this system is that builds can break (without any change to > the project itself) if a new version of a plugin is released. This can cause > confusion among developers because the build appears to break for no reason. > It also makes reproducing old builds to be more difficult because a newer > version of a plugin could cause some aspect of the build to be different than > when it was originally released. > SUREFIRE-61 is one example of where this happened. When surefire 2.3.1 was > released, it affected the testing of some builds because the classpath > ordering changed. > My suggestion for fixing this is to require a version for all plugins. This > is already a best practice among many maven users, but it is not enforced by > maven itself. For the default lifecycle plugins (compiler plugin, surefire > plugin, etc.) maven should tie it's version to specific default versions of > the plugins. These could then be overridden when necessary. > This change probably belongs in 2.1 since it is too big a change for 2.0.9. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-68) Use ant-1.7.0
[
http://jira.codehaus.org/browse/MANTRUN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119615
]
Kohsuke Kawaguchi commented on MANTRUN-68:
--
When I tried to use Ant 1.7.0 with Maven 2 in an environment similar to
maven-antrun-plugin, I get the following error when Ant tries to load a
resource from a jar file, whose path name includes whitespace.
It appears that ClassLoaders from ClassWorlds return file URL that contains
whitespace instead of escaping it to %20, and Ant 1.7 doesn't like this.
{noformat}
ava.lang.IllegalArgumentException
at java.net.URI.create(URI.java:842)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.launch.Locator.fromURI(Locator.java:162)
at
org.apache.tools.ant.launch.Locator.getResourceSource(Locator.java:119)
at org.apache.tools.ant.launch.Locator.getClassSource(Locator.java:90)
at org.apache.tools.ant.Project.setAntLib(Project.java:313)
at org.apache.tools.ant.Project.initProperties(Project.java:309)
at org.apache.tools.ant.Project.init(Project.java:295)
at
org.jvnet.maven.plugin.antrun.components.AntTargetConverter.processConfiguration(AntTargetConverter.java:110)
at
org.jvnet.maven.plugin.antrun.components.AntTargetConverter.fromConfiguration(AntTargetConverter.java:80)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1147)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:614)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.net.URISyntaxException: Illegal character in path at
index 18: file:/C:/Documents and Settings/tjquinn/.m2/repositor
y/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parseHierarchical(URI.java:3066)
at java.net.URI$Parser.parse(URI.java:3014)
at java.net.URI.(URI.java:578)
at java.net.URI.create(URI.java:840)
... 35 more
{noformat}
> Use ant-1.7.0
> -
>
> Key: MANTRUN-68
> URL: http://jira.codehaus.org/browse/MANTRUN-68
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
> Environment: xp, linux
>Reporter: Dan Tran
> Attachments: MANTRUN-68-maven-antrun-plugin.patch
>
>
> with out this upgrade, i will need to ant 1.7.0 to use its new
> features like abily to do delete,move, etc using filelist
--
This message is automatically g
[jira] Commented: (MNG-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119616
]
Richard van der Hoff commented on MNG-2848:
---
Oops, this seems to have broken property passing in mvn exec:java - see MEXEC-41
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: Vincent Siveton
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3356) Multiple -Dkey=value command line options not handled correctly
[ http://jira.codehaus.org/browse/MNG-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119619 ] Paul Cager commented on MNG-3356: - This error will only affect the *Debian* Maven package, and happens because Debian are using commons-cli version 1.1 (rather than version 1.0 which standard Maven uses). Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458895 and http://issues.apache.org/jira/browse/CLI-137 for a full description of why this is happening. A revised Debian package is being prepared. In summary: version 1.1 of commons-cli introduced a more rigid interpretation of the API specification for the hasArg() method of OptionBuilder, such that hasArg() implies there can only be *one* instance of the argument (I think there is a remaining bug in the commons.cli package which I'll take up with them). This means that the second "-D" option is taken to be an argument, rather than an option. In version 1.0 of commons-cli this restriction was never enforced. Maven should really be calling the hasArgs() method to indicate there can be unlimited "-D" arguments. I've attached the patch Debian is using for this problem. > Multiple -Dkey=value command line options not handled correctly > --- > > Key: MNG-3356 > URL: http://jira.codehaus.org/browse/MNG-3356 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Christian Koelle >Priority: Critical > > After upgrading to 2.0.8 on Debian the handling of multiple (more than one) > -Dkey=value cli options fail, i.e. something like: > mvn plugin:goal -Dkey1=value1 -Dkey2=value2 > fails with: > Invalid task 'key2=value2': you must specify a valid lifecycle phase, or a > goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion:goal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3356) Multiple -Dkey=value command line options not handled correctly
[ http://jira.codehaus.org/browse/MNG-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Cager updated MNG-3356: Attachment: command-line.patch Debian's patch to use hasArgs() method. > Multiple -Dkey=value command line options not handled correctly > --- > > Key: MNG-3356 > URL: http://jira.codehaus.org/browse/MNG-3356 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Christian Koelle >Priority: Critical > Attachments: command-line.patch > > > After upgrading to 2.0.8 on Debian the handling of multiple (more than one) > -Dkey=value cli options fail, i.e. something like: > mvn plugin:goal -Dkey1=value1 -Dkey2=value2 > fails with: > Invalid task 'key2=value2': you must specify a valid lifecycle phase, or a > goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion:goal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
