[jira] Created: (MASSEMBLY-530) Allow configuration of encoding
Allow configuration of encoding Key: MASSEMBLY-530 URL: http://jira.codehaus.org/browse/MASSEMBLY-530 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Max Schaefer Zips, that encode the file names with e.g. UTF-8 are not properly unpacked because the system default encoding is assumed. I tracked down that PlexusIoZipFileResourceCollection initialises a ZipFile instance passing in just the file. However, a second parameter of ZipFile allows to control the encoding. I would like to be able to specify that encoding when unpacking a dependencySet. -- 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: (MDEP-273) Analyze Dependency Versions Mojo
[ http://jira.codehaus.org/browse/MDEP-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243252#action_243252 ] Brian Fox commented on MDEP-273: We usually add a small section to the usage page describing the new goal and how it's used. Analyze Dependency Versions Mojo Key: MDEP-273 URL: http://jira.codehaus.org/browse/MDEP-273 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Cole Mickens Assignee: Brian Fox Attachments: analyze-dep-versions.patch, core.PNG, script-ant.PNG This is a patch that adds a new mojo and a report class to maven-dependency-plugin trunk (2.2). The goal `dependency:analyze-dep-versions` lists dependencies that are either resolved at a lower version than needed by a dependency farther from the project root or are being overridden by the dependencyManagement section. In some sense it is complimentary to `dependency:analyze-dep-mgt`. I checked out trunk today, added my new files, `svn add`ed them, then performed an `svn diff`. The patches applied correctly with a rechecked out copy of trunk with `cd apache-maven-dependency-plugin; patch -p0 ../analyze-dep-versions.patch`. After patching, it built, installed and passed IT tests (including the 6 new ones that I've added) properly. -- 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: (MRELEASE-310) ForkedMavenExecutor assumes mvn is on command-line path
[ http://jira.codehaus.org/browse/MRELEASE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243265#action_243265 ] Frederic Tardif commented on MRELEASE-310: -- any update about this issue? It is quite annoying since we can't use the maven-release-plugin with the embed m2e's maven. ForkedMavenExecutor assumes mvn is on command-line path --- Key: MRELEASE-310 URL: http://jira.codehaus.org/browse/MRELEASE-310 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare, stage Affects Versions: 2.0-beta-7 Reporter: Brian Jackson Attachments: ForkedMavenExecutor.patch The ForkedMavenExecutor assumes the mvn executable is on the command-line path. This will cause the release goals to fail if mvn is run from an explicit path and the PATH environment variable has not be set to contain a mvn executable. More dangerously though is the case where the release goal is started with an explicit mvn executable of one version (for instance 2.0.8) but a different version of the mvn executable is available on the PATH. The forked processes will run a different version of Maven2 that the parent process. -- 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-4898) Better DuplicateProjectException error message
Better DuplicateProjectException error message
--
Key: MNG-4898
URL: http://jira.codehaus.org/browse/MNG-4898
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Igor Fedorenko
This was originally reported against as
https://issues.sonatype.org/browse/TYCHO-531. When the same pom.xml file is
referenced from multiple module/ element, the build fails with rather
unhelpful error message like
{noformat}
[ERROR] Two or more projects in the reactor have the same identifier, please
make sure that groupId:artifactId:version is unique for each project:
{org.jboss.tools.build:org.jboss.tools.build.libs:1.0.0-SNAPSHOT=[/qa/hudson_ws/workspace/jbosstools-3.2.0.Beta2.tests/sources/build/libs/pom.xml,
/qa/hudson_ws/workspace/jbosstools-3.2.0.Beta2.tests/sources/build/libs/pom.xml]}
{noformat}
To help user troubleshoot the problem, we need to provide pom.xml and ideally
line numbers that reference the same module.
--
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: (MRELEASE-286) Classpath errors during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRELEASE-286: - Component/s: (was: prepare) perform Classpath errors during release:perform --- Key: MRELEASE-286 URL: http://jira.codehaus.org/browse/MRELEASE-286 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0-beta-6 Reporter: Cameron Jones Priority: Blocker Attachments: sandbox-release-console.log, sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip I have a standard web app project which consists of a core module, a web app and some web services. In the project build i have some automated tasks setup to create the client stub classes by starting a jetty web container, deploying the web app, and then hitting the web service to access the generated wsdl so it can create a stub library. This process works during a standard 'install' goal and when running the 'release:prepare' goal, however when running 'release:perform' i encounter some library conflicts which i can only guess are as a result of a polluted class path. The specific error i get is that there is more than 1 commons-logging library on the classpath. I know this is a common error but i have it sucessfully working in the other goals and i've spent a lot of time making sure it's not an actual commons-logging issue. Also, i've also seen java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a result of running the same config. Is there anything special about the way that the release:perform task manages it's classpath? I notice that the perform task actually executes several iterations of build during this phase, is it possible that the previous iterations classpath is not isolated? To illustrate the issue i've created a test project which mimics the functionality in my app and illustrates the issue. I've attached the project to this jira and also the logs files from running release:prepare and release:perform. Unfortunately the error in jetty is output to the console so i've got that as a separate file. The test project has the following modules: pom.xml - Parent POM core/pom.xml - Core POM using commons-logging with no concrete loggers packaged or as transitive dependencies web/pom.xml - Web App using commons loggins also with no concrete log implementation (log4j is added explicity just for unit tests) test/pom.xml - Client stub generation module (sorry should have renamed to something better). The client stub module starts jetty using cargo during the initialize phase and deploy the web app. In the real app it would generate the stub classes but in this example it just needs to depoy the app for the error to occur. During the compile phase it shuts down jetty. To test i'm afraid you'll have to create a subversion repo for the app but that should be pretty much it. You might need to reconfigue where the site is deploy to as well. The only external property config should be the scm connection details. -- 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-613) Add a parameter that tells the plugin to wait for X seconds before tagging
Add a parameter that tells the plugin to wait for X seconds before tagging -- Key: MRELEASE-613 URL: http://jira.codehaus.org/browse/MRELEASE-613 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.1 Reporter: Dennis Lundberg Attachments: waitBeforeTagging.patch Doing releases at the ASF using the Release Plugin is a pain in you are in Europe, because of the svn-sync and geo-ip mapping that is used. The attached patch adds a new parameter waitBeforeTagging that takes the number of seconds to wait before tagging. I'd appreciate some more eyes on the patch, in particular whether my approach is thread-safe. -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243327#action_243327 ] Emmanuel Potvin commented on MNG-3283: -- Is there any news about this issue since january? I have this problem and I just try with Maven 3 and the @requiresDependencyCollection annotation and now instead of just crash I have warning telling me that some pom are missing and no dependency information is available. And effectively, the getArtifacts method returns me an empty collection. What is wierd is that in my pom, I have dependencies on the other modules of my reactor and the version (in my case trunk-SNAPSHOT) is a property set inside the pom of the reactor, and it is resolved. So it is able to see my reactor's pom, but not use it to get pom inside other modules... Plugins that require dependency resolution in early phases cause dependency resolution issue Key: MNG-3283 URL: http://jira.codehaus.org/browse/MNG-3283 Project: Maven 2 3 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.7 Reporter: Alfie Kirkpatrick Assignee: Brian Fox Fix For: Issues to be reviewed for 3.x Attachments: maven-dependency-bug.zip What we're seeing is that some multi-project configurations succeed on 'mvn package' but fail on 'mvn generate-sources'. They are failing when one project in the reactor references another project in the reactor which is not installed in the local repo. It seems that the referenced project has not quite made it into the reactor this early in the phase lifecycle. But it does work correctly if you target a later phase at the outset which is really confusing. The problem only occurs when a plugin binds itself to the generate-sources phase and has @requiresDependencyResolution, presumably because this is what triggers resolution of the referenced dependency too early in the lifecycle, and hence the error. We are seeing this problem when trying to run 'mvn eclipse:eclipse' because this only executes the generate-sources phase by default and we have other mojos which genuinely do generate source, such as java2wsdl. A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. Attached is a really simple project that exhibits this problem. -- 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: (MRELEASE-613) Add a parameter that tells the plugin to wait for X seconds before tagging
[ http://jira.codehaus.org/browse/MRELEASE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243337#action_243337 ] Brett Porter commented on MRELEASE-613: --- The patch looks fine to me. I haven't followed that issue recently - was there no other alternative, like not remote tagging? Is this option relevant if it is not remote tagging? Add a parameter that tells the plugin to wait for X seconds before tagging -- Key: MRELEASE-613 URL: http://jira.codehaus.org/browse/MRELEASE-613 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.1 Reporter: Dennis Lundberg Attachments: waitBeforeTagging.patch Doing releases at the ASF using the Release Plugin is a pain in you are in Europe, because of the svn-sync and geo-ip mapping that is used. The attached patch adds a new parameter waitBeforeTagging that takes the number of seconds to wait before tagging. I'd appreciate some more eyes on the patch, in particular whether my approach is thread-safe. -- 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: (MRELEASE-613) Add a parameter that tells the plugin to wait for X seconds before tagging
[ http://jira.codehaus.org/browse/MRELEASE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243341#action_243341 ] Mark Struberg commented on MRELEASE-613: The 'wait 10 seconds' trick is ok. The problem is that we have a svn-mirror in the EU. Thus any commit or tag will be reflected only a few seconds later. So if you commit the pom and then check it out/tag it/whatever without waiting, you will almost always fail (because of the svn-mirroring delay to eu.svn.apache.org or any other mirrored server). Add a parameter that tells the plugin to wait for X seconds before tagging -- Key: MRELEASE-613 URL: http://jira.codehaus.org/browse/MRELEASE-613 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.1 Reporter: Dennis Lundberg Attachments: waitBeforeTagging.patch Doing releases at the ASF using the Release Plugin is a pain in you are in Europe, because of the svn-sync and geo-ip mapping that is used. The attached patch adds a new parameter waitBeforeTagging that takes the number of seconds to wait before tagging. I'd appreciate some more eyes on the patch, in particular whether my approach is thread-safe. -- 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: (MCHECKSTYLE-132) Upgrade to Checkstyle 5.3
[ http://jira.codehaus.org/browse/MCHECKSTYLE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCHECKSTYLE-132: - Summary: Upgrade to Checkstyle 5.3 (was: Upgrade to Checkstyle 5.1) Upgrade to Checkstyle 5.3 - Key: MCHECKSTYLE-132 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-132 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Reporter: Simon Brandhof Attachments: checkstyle-5.3.patch [Release notes|http://checkstyle.sourceforge.net/releasenotes.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] Closed: (MCHECKSTYLE-132) Upgrade to Checkstyle 5.3
[ http://jira.codehaus.org/browse/MCHECKSTYLE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-132. Resolution: Fixed Fix Version/s: 2.7 Assignee: Olivier Lamy fixed [rev 1035854|http://svn.apache.org/viewvc?rev=1035854view=rev] Upgrade to Checkstyle 5.3 - Key: MCHECKSTYLE-132 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-132 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Reporter: Simon Brandhof Assignee: Olivier Lamy Fix For: 2.7 Attachments: checkstyle-5.3.patch [Release notes|http://checkstyle.sourceforge.net/releasenotes.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] Commented: (MRELEASE-613) Add a parameter that tells the plugin to wait for X seconds before tagging
[ http://jira.codehaus.org/browse/MRELEASE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243347#action_243347 ] Olivier Lamy commented on MRELEASE-613: --- nice here too. Add a parameter that tells the plugin to wait for X seconds before tagging -- Key: MRELEASE-613 URL: http://jira.codehaus.org/browse/MRELEASE-613 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.1 Reporter: Dennis Lundberg Attachments: waitBeforeTagging.patch Doing releases at the ASF using the Release Plugin is a pain in you are in Europe, because of the svn-sync and geo-ip mapping that is used. The attached patch adds a new parameter waitBeforeTagging that takes the number of seconds to wait before tagging. I'd appreciate some more eyes on the patch, in particular whether my approach is thread-safe. -- 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: (MRELEASE-457) Non sparse-checkout SCM support
[ http://jira.codehaus.org/browse/MRELEASE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243352#action_243352 ] Olivier Lamy commented on MRELEASE-457: --- patch tested with this project (https://github.com/olamy/scm-git-test) to release only my-app or my-app-webapp and it works. Someone else wants to review ? Non sparse-checkout SCM support --- Key: MRELEASE-457 URL: http://jira.codehaus.org/browse/MRELEASE-457 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: perform, scm Affects Versions: 2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2 Attachments: MRELEASE-457.2.patch, MRELEASE-457.patch Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't support sparse checkouts (checkout of a single subdirectory). So while doing a mvn release:perform in a sub-module, we will always get the _whole_ project checked out into target/checkout! For doing the clean build from this checkout, we have to implement a functionality to find the right submodule first. -- 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
