[jira] Created: (SUREFIRE-647) Memory Leak
Memory Leak --- Key: SUREFIRE-647 URL: http://jira.codehaus.org/browse/SUREFIRE-647 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.6 Environment: Maven 2.2.1, 3.0RC1 Reporter: Stephen Coy Priority: Critical Attachments: surefire dump.png We have a module containing over 500 unit tests, most of which create Hibernate sessions with a largish data model. Surefire 2.6 fails to complete these tests, even with: jvmArg-Xmx512m/jvmArg specified. Surefire 2.5 (and earlier) completes these tests with no trouble at all, without jvmArg settings. I performed a heapdump (which is too big to upload here) and it shows that org.apache.maven.surefire.util.TeeStream seems to be hanging on to data in memory. The 20 biggest objects by retained size were all instances of this. I've attached a screen dump -- 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: (WAGON-121) wagon-http does not MKCOL for missing parent resources during deploy
[
http://jira.codehaus.org/browse/WAGON-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235892#action_235892
]
Jordi Deu-Pons commented on WAGON-121:
--
Hi,
I have this problem with the current wagon-webdav version.
It sends only one MKCOL for the first ancestor. Like:
MKCOL /repository/org/intogen/intogen-data/0.1-SNAPSHOT
If the folder /repository/org/intogen/intogen-data don't exist then the maven
deploy is going to fail. If I create the folder then the maven deploy works
fine.
I checked the current WebDAV specifications:
http://www.webdav.org/specs/rfc4918.html#METHOD_MKCOL
It saids:
During MKCOL processing, a server MUST make the Request-URI an internal member
of its parent collection, unless the Request-URI is /. If no such ancestor
exists, the method MUST fail
So I understand that is the wagon-webdav who has to create all the ancestors
if they don't exist.
I'm using OpenKM (that uses jackrabbit) as a WebDAV server. May be other
servers had different behaviours in this case.
Thanks.
wagon-http does not MKCOL for missing parent resources during deploy
Key: WAGON-121
URL: http://jira.codehaus.org/browse/WAGON-121
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
Apache/2.0.54 (Fedora) DAV/2
Reporter: Matthew Daniel
Assignee: Joakim Erdfelt
Priority: Blocker
Please see MNG-1580 and
When trying to deploy using wagon-http, it does not understand the concept of
parent directories and just issues a blind PUT with the resource URI. Further
to the user's confusion, it does not report a helpful message but Access
denided which is 100% not true.
{quote}
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifactat
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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:585)
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: org.apache.maven.plugin.MojoExecutionException: Error deploying
artifact
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
... 16 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Error deploying artifact: Authorization failed: Access denided to:
http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
... 18 more
Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
failed: Access denided to:
http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
at
[jira] Closed: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRELEASE-318. - Resolution: Fixed Assignee: Brett Porter I applied the test case from Mark, with some modifications to not corrupt his other later test. I fixed this by getting ranges to use the version they were resolved to for the project. This doesn't solve a more general problem about ranges, and particularly snapshots in ranges as discussed here - will defer that to the more specific issues. Release plugin throws NullPointerException when using version range for dependency -- Key: MRELEASE-318 URL: http://jira.codehaus.org/browse/MRELEASE-318 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-7 Reporter: David Hoffer Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Attachments: MNG-3351-unittest.patch, MNG-3351.zip, MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, simple-testcase.zip After upgrading to 2.0.8 I find that the release plugin throws NPE if any dependency uses version range. I have one dependency with version range version[1.0,2.0)/version the rest are test scope with fixed version. Here is the crash stack trace: java.lang.NullPointerException: version was null for com.xrite:xrite-colorlib-api [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) [13:42:05]: at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) [13:42:05]: at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [13:42:05]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) [13:42:05]: at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) [13:42:05]: at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) It seems the reason version is null is that the call to selectVersionFromNewRangeIfAvailable() assumes that versionRange.getRecommendedVersion() will always return non-null, else it sets the version to null! However during the release:prepare phase this is not true, see the output: [13:42:04]: [INFO] [release:prepare] [13:42:04]: [INFO] Verifying that there are no local modifications... [13:42:04]: [INFO] Executing: svn --non-interactive status [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 [13:42:05]: [INFO] Checking dependencies and plugins
[jira] Commented: (MRELEASE-251) expression in a POM cannot be updated during release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235896#action_235896 ] Brett Porter commented on MRELEASE-251: --- trying this with the latest snapshot, the one on the tag works correctly, but the next version goes back to the old one. expression in a POM cannot be updated during release:prepare Key: MRELEASE-251 URL: http://jira.codehaus.org/browse/MRELEASE-251 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-6 Reporter: Brett Porter Priority: Critical Fix For: 2.1 eg. The artifact (org.apache.maven:maven-error-diagnostics) requires a different version (2.0.7) than what is found (2.0.7) for the expression (mavenVersion) in the project (org.apache.maven:maven). This is achieved by running mvn -DdryRun=true release:prepare on the maven-2.0.x branch and selecting 2.0.7 as the release version for all, maven-2.0.7 as the tag and 2.0.8-SNAPSHOT as the next version for them all. -- 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: (MRELEASE-251) expression in a POM cannot be updated during release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRELEASE-251. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.1) Assignee: Brett Porter the last part is MRELEASE-370. Closing as the original now seems fixed. expression in a POM cannot be updated during release:prepare Key: MRELEASE-251 URL: http://jira.codehaus.org/browse/MRELEASE-251 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-6 Reporter: Brett Porter Assignee: Brett Porter Priority: Critical eg. The artifact (org.apache.maven:maven-error-diagnostics) requires a different version (2.0.7) than what is found (2.0.7) for the expression (mavenVersion) in the project (org.apache.maven:maven). This is achieved by running mvn -DdryRun=true release:prepare on the maven-2.0.x branch and selecting 2.0.7 as the release version for all, maven-2.0.7 as the tag and 2.0.8-SNAPSHOT as the next version for them all. -- 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: (MASSEMBLY-504) Transitive dependencies of a dependency added by a profile aren't taken into account
Transitive dependencies of a dependency added by a profile aren't taken into
account
Key: MASSEMBLY-504
URL: http://jira.codehaus.org/browse/MASSEMBLY-504
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Reporter: Guillaume Eyroulet
Attachments: maven-assembly-example.zip
In a reactor, there are 4 modules A, B, C and D.
* A and B depends on C
* D depends
** on B
** on A due to a profile.
When making an assembly from D
* including A
* excluding B
* using transitive dependencies
{noformat}
formats
formatdir/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
useTransitiveDependenciestrue/useTransitiveDependencies
useTransitiveFilteringtrue/useTransitiveFiltering
includes
includeexample:a/include
/includes
excludes
excludeexample:b/exclude
/excludes
/dependencySet
/dependencySets
/assembly
{noformat}
C isn't in the result directory.
Remark: C is in the result directory if D depends on A normally.
--
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: (MPMD-86) Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK 1.5 mode!
[ http://jira.codehaus.org/browse/MPMD-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235904#action_235904 ] Vetle Roeim commented on MPMD-86: - I ran into the same thing, seems easy to reproduce. The workaround, i.e. setting the property globally (instead of the configuration property) works. Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK 1.5 mode! --- Key: MPMD-86 URL: http://jira.codehaus.org/browse/MPMD-86 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4 Environment: JAVA 1.5, Maven 2.0.9 Reporter: Debabrat Panda Assignee: Benjamin Bentmann While running PMD with Maven i am getting parsing error Error while parsing ../../../java file The errors are 1. Can't use generics unless running in JDK 1.5 mode! 2. Can't use static imports when running in JDK 1.4 mode! Can't use annotations when running in JDK 1.4 mode! Any help will be appreciated. Thanks in advance. -- 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: (MECLIPSE-670) additional config file location is now resolved relatively to the current project
additional config file location is now resolved relatively to the current project - Key: MECLIPSE-670 URL: http://jira.codehaus.org/browse/MECLIPSE-670 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Guillaume Eyroulet Attachments: maven-eclipse-example.zip In 2.7, it was resolved relatively to the root project. It was easier to use in a project with many nested directories. root-project - pom.xml - eclipse -- eclipse additional config files - sub-project-1 -- pom.xml with additionalConfig pointing to eclipse directory -- sub-project-2 --- sub-project-2.1 pom.xml with additionalConfig pointing to eclipse directory -- 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-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)
[ http://jira.codehaus.org/browse/MNG-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235922#action_235922 ] Jason van Zyl commented on MNG-4830: Please keep this out of the core. I don't see how this method call helps anyone. An untype String array that accepts a PrintStream? Once stuff like this goes in that we haven't thought about very much has to be supported forever. I would prefer it not go in. Add helper component to build MavenExecutionRequest from cli args (String[] args) - Key: MNG-4830 URL: http://jira.codehaus.org/browse/MNG-4830 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Command Line Affects Versions: 3.0-beta-3 Reporter: Olivier Lamy currently executing maven programmatically is quite difficult because building easily a MavenExecutionRequest needs a lot of parameters, some methods to call etc... Here a simple component which build MavenExecutionRequest from String[] args (cli arguments). Source code is here : [http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java]. Any objection I commit this in ASF ? -- 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-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)
[ http://jira.codehaus.org/browse/MNG-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235925#action_235925 ] Olivier Lamy commented on MNG-4830: --- The goal is here to help people using maven programmaticaly. String array is just cli args and PrintStream is for logging. Sure it's not perfect but building manually MavenExecutionRequest and/or ProjectBuildingRequest is a little bit complicated and not really documented (ie what are necessary objects and/or components etc...). Add helper component to build MavenExecutionRequest from cli args (String[] args) - Key: MNG-4830 URL: http://jira.codehaus.org/browse/MNG-4830 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Command Line Affects Versions: 3.0-beta-3 Reporter: Olivier Lamy currently executing maven programmatically is quite difficult because building easily a MavenExecutionRequest needs a lot of parameters, some methods to call etc... Here a simple component which build MavenExecutionRequest from String[] args (cli arguments). Source code is here : [http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java]. Any objection I commit this in ASF ? -- 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: (MSOURCES-55) Add a skip configuration to source plugin
Add a skip configuration to source plugin - Key: MSOURCES-55 URL: http://jira.codehaus.org/browse/MSOURCES-55 Project: Maven 2.x Source Plugin Issue Type: New Feature Affects Versions: 2.1.2, 2.1.1, 2.1, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0, 2.2 Reporter: Marvin Froeder Add a configuration that allow me to programmatically skip source plugin execution. This is mainly intended to be used from commandLine as a way to tweak/speed up the build. -- 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-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)
[ http://jira.codehaus.org/browse/MNG-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235931#action_235931 ] Jason van Zyl commented on MNG-4830: I'll try to glean what you mean here ... Have you basically extracted: http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/DefaultMavenExecutionRequestBuilder.java out of https://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java If so this would only be useful if we didn't have to duplicate code. So you need to figure out how to use this in the MavenCli in a way that reuses the code. Right now the components that are required are looked up directly by the container. So dropping your code right now in that form would just make a bunch of duplicate code. So until you find a way to make the same component work in both places I'm -1. If you can get your component to work in MavenCli I'm +1. Add helper component to build MavenExecutionRequest from cli args (String[] args) - Key: MNG-4830 URL: http://jira.codehaus.org/browse/MNG-4830 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Command Line Affects Versions: 3.0-beta-3 Reporter: Olivier Lamy currently executing maven programmatically is quite difficult because building easily a MavenExecutionRequest needs a lot of parameters, some methods to call etc... Here a simple component which build MavenExecutionRequest from String[] args (cli arguments). Source code is here : [http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java]. Any objection I commit this in ASF ? -- 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-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)
[ http://jira.codehaus.org/browse/MNG-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235933#action_235933 ] Olivier Lamy commented on MNG-4830: --- that's exactly the goals : * get component to work in MavenCli * not having a -1 :-) Add helper component to build MavenExecutionRequest from cli args (String[] args) - Key: MNG-4830 URL: http://jira.codehaus.org/browse/MNG-4830 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Command Line Affects Versions: 3.0-beta-3 Reporter: Olivier Lamy currently executing maven programmatically is quite difficult because building easily a MavenExecutionRequest needs a lot of parameters, some methods to call etc... Here a simple component which build MavenExecutionRequest from String[] args (cli arguments). Source code is here : [http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java]. Any objection I commit this in ASF ? -- 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: (MSOURCES-55) Add a skip configuration to source plugin
[
http://jira.codehaus.org/browse/MSOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235932#action_235932
]
Marvin Froeder commented on MSOURCES-55:
Patch for it:
{code:java}
Index: pom.xml
===
--- pom.xml (revision 999411)
+++ pom.xml (working copy)
@@ -39,6 +39,15 @@
maven2.0.6/maven
/prerequisites
+ contributors
+contributor
+ nameMarvin Froeder/name
+ emailvelo...@gmail.com/email
+ roles
+roleMSOURCES-55/role
+ /roles
+/contributor
+ /contributors
scm
connectionscm:svn:http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-source-plugin//connection
developerConnectionscm:svn:https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-source-plugin//developerConnection
Index: src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
===
--- src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
(revision 999411)
+++ src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
(working copy)
@@ -190,6 +190,15 @@
*/
private boolean forceCreation;
+/**
+ * A flag used to disable the source procedure. This is primarily intended
for usage from the command line to
+ * occasionally adjust the build.
+ *
+ * @parameter expression=${source.skip} default-value=false
+ * @since 1.4
+ */
+private boolean skipSource;
+
// --
// Public methods
// --
@@ -198,6 +207,12 @@
public void execute()
throws MojoExecutionException
{
+if ( skipSource )
+{
+getLog().info( Skipping source per configuration. );
+return;
+}
+
packageSources( project );
}
{code}
Add a skip configuration to source plugin
-
Key: MSOURCES-55
URL: http://jira.codehaus.org/browse/MSOURCES-55
Project: Maven 2.x Source Plugin
Issue Type: New Feature
Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.1, 2.1.1, 2.1.2, 2.2
Reporter: Marvin Froeder
Add a configuration that allow me to programmatically skip source plugin
execution. This is mainly intended to be used from commandLine as a way to
tweak/speed up the build.
--
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-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)
[ http://jira.codehaus.org/browse/MNG-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235934#action_235934 ] Jason van Zyl commented on MNG-4830: You should also then think about the invoker plugin, the release plugin and the verifier. If we're going to fix this we might as well fix it all. Add helper component to build MavenExecutionRequest from cli args (String[] args) - Key: MNG-4830 URL: http://jira.codehaus.org/browse/MNG-4830 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Command Line Affects Versions: 3.0-beta-3 Reporter: Olivier Lamy currently executing maven programmatically is quite difficult because building easily a MavenExecutionRequest needs a lot of parameters, some methods to call etc... Here a simple component which build MavenExecutionRequest from String[] args (cli arguments). Source code is here : [http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java]. Any objection I commit this in ASF ? -- 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: (MECLIPSE-663) Overriding Packaging does not work correctly for WTP-Project
[
http://jira.codehaus.org/browse/MECLIPSE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mårten Gustafson updated MECLIPSE-663:
--
Attachment: getConfig.patch
Patch against v2.8
Overriding Packaging does not work correctly for WTP-Project
Key: MECLIPSE-663
URL: http://jira.codehaus.org/browse/MECLIPSE-663
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.8
Environment: All
Reporter: Benjamin Gniza
Attachments: getConfig.patch
I found out that overriding the packaging - type (MECLIPSE-331) does not work
correct if you want to have a wtp project:
{code:xml}
project.
modelVersion4.0.0/modelVersion
groupIdcom.mycompany.app/groupId
artifactIdmy-webapp2/artifactId
packagingjar/packaging
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
configuration
packagingwar/packaging
source${jdk.version}/source
target${jdk.version}/target
wtpversion1.5/wtpversion
/configuration
/plugin
{code}
This configuration leads to a Nullpointer Exception:
{noformat}
java.lang.NullPointerException
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.escapeXml(PrettyPrintXMLWriter.java:151)
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.escapeXmlAttribute(PrettyPrintXMLWriter.java:166)
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.addAttribute(PrettyPrintXMLWriter.java:190)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponent15Writer.writeContextRoot(EclipseWtpComponent15Writer.java:68)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponentWriter.writeModuleTypeComponent(EclipseWtpComponentWriter.java:149)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponentWriter.write(EclipseWtpComponentWriter.java:106)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1110)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
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:592)
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)
{noformat}
The cause for that NullpointerException is that _config.getContextName()_ in
*EclipseWtpComponent15Writer.java:68* is null.
I found out that you are referring to *project.getPackaging()* or
*config.getProject().getPackaging()* instead of *config.getPackaging()* in
many places:
* EclipseManifestWriter
* EclipsePlugin (in this class the method
_collectWarContextRootsFromReactorEarConfiguration_ should set the missing
context name, but the method refers to *project.getPackaging()* which is
still *jar*
** here a _reactorProject.getPackaging()_ can also be fond, I don't know if
this is correct.
* RadManifestWriter
* MyEclipseMetadataWriter
* MyEclipseStrutsDataWriter
* EclipseWtpApplicationXMLWriter
* MyEclipsePlugin
* AbstractWtpResourceWriter
After replacing all references to
[jira] Updated: (MECLIPSE-663) Overriding Packaging does not work correctly for WTP-Project
[
http://jira.codehaus.org/browse/MECLIPSE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mårten Gustafson updated MECLIPSE-663:
--
Attachment: proper-getConfig.patch
Previous patch included some non relevant cruft.
Overriding Packaging does not work correctly for WTP-Project
Key: MECLIPSE-663
URL: http://jira.codehaus.org/browse/MECLIPSE-663
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.8
Environment: All
Reporter: Benjamin Gniza
Attachments: getConfig.patch, proper-getConfig.patch
I found out that overriding the packaging - type (MECLIPSE-331) does not work
correct if you want to have a wtp project:
{code:xml}
project.
modelVersion4.0.0/modelVersion
groupIdcom.mycompany.app/groupId
artifactIdmy-webapp2/artifactId
packagingjar/packaging
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
configuration
packagingwar/packaging
source${jdk.version}/source
target${jdk.version}/target
wtpversion1.5/wtpversion
/configuration
/plugin
{code}
This configuration leads to a Nullpointer Exception:
{noformat}
java.lang.NullPointerException
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.escapeXml(PrettyPrintXMLWriter.java:151)
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.escapeXmlAttribute(PrettyPrintXMLWriter.java:166)
at
org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.addAttribute(PrettyPrintXMLWriter.java:190)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponent15Writer.writeContextRoot(EclipseWtpComponent15Writer.java:68)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponentWriter.writeModuleTypeComponent(EclipseWtpComponentWriter.java:149)
at
org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpComponentWriter.write(EclipseWtpComponentWriter.java:106)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1110)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
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:592)
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)
{noformat}
The cause for that NullpointerException is that _config.getContextName()_ in
*EclipseWtpComponent15Writer.java:68* is null.
I found out that you are referring to *project.getPackaging()* or
*config.getProject().getPackaging()* instead of *config.getPackaging()* in
many places:
* EclipseManifestWriter
* EclipsePlugin (in this class the method
_collectWarContextRootsFromReactorEarConfiguration_ should set the missing
context name, but the method refers to *project.getPackaging()* which is
still *jar*
** here a _reactorProject.getPackaging()_ can also be fond, I don't know if
this is correct.
* RadManifestWriter
* MyEclipseMetadataWriter
* MyEclipseStrutsDataWriter
* EclipseWtpApplicationXMLWriter
* MyEclipsePlugin
*
[jira] Created: (MAVENUPLOAD-2805) jt400-7.1-bundle
jt400-7.1-bundle Key: MAVENUPLOAD-2805 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2805 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-7.1-bundle.jar, jt400-7.1-javadoc-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java is a library of Java classes supporting the client/server and internet programming models to a system running OS/400 or i5/OS. The classes can be used by Java applets, servlets, and applications to easily access OS/400 and i5/OS data and resources. -- 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: (MAVENUPLOAD-2805) jt400-7.1-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Lee updated MAVENUPLOAD-2805: -- Attachment: jt400-7.1-source-bundle.jar Adding source code attachment. (I couldn't add it on the original request, since my total file upload size would have exceeded the 10MB limit.) jt400-7.1-bundle Key: MAVENUPLOAD-2805 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2805 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-7.1-bundle.jar, jt400-7.1-javadoc-bundle.jar, jt400-7.1-source-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java is a library of Java classes supporting the client/server and internet programming models to a system running OS/400 or i5/OS. The classes can be used by Java applets, servlets, and applications to easily access OS/400 and i5/OS data and resources. -- 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-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235952#action_235952 ] Arik Kfir commented on MRELEASE-318: Brett, can you please elaborate about the more general problem about ranges you mentioned? Release plugin throws NullPointerException when using version range for dependency -- Key: MRELEASE-318 URL: http://jira.codehaus.org/browse/MRELEASE-318 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-7 Reporter: David Hoffer Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Attachments: MNG-3351-unittest.patch, MNG-3351.zip, MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, simple-testcase.zip After upgrading to 2.0.8 I find that the release plugin throws NPE if any dependency uses version range. I have one dependency with version range version[1.0,2.0)/version the rest are test scope with fixed version. Here is the crash stack trace: java.lang.NullPointerException: version was null for com.xrite:xrite-colorlib-api [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) [13:42:05]: at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) [13:42:05]: at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [13:42:05]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) [13:42:05]: at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) [13:42:05]: at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) It seems the reason version is null is that the call to selectVersionFromNewRangeIfAvailable() assumes that versionRange.getRecommendedVersion() will always return non-null, else it sets the version to null! However during the release:prepare phase this is not true, see the output: [13:42:04]: [INFO] [release:prepare] [13:42:04]: [INFO] Verifying that there are no local modifications... [13:42:04]: [INFO] Executing: svn --non-interactive status [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... [13:42:05]: TEST!!! version=null [13:42:05]: TEST!!! versionRange=[1.0,2.0) [13:42:05]: TEST!!! getRecommendedVersion=null TEST!!! Lines are my test code so I could see what is going on here. -- This message is automatically generated by
[jira] Commented: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235965#action_235965 ] Brett Porter commented on MRELEASE-318: --- Arik, I meant the reference to the MNG-3092 issue which is still being debated. Release plugin throws NullPointerException when using version range for dependency -- Key: MRELEASE-318 URL: http://jira.codehaus.org/browse/MRELEASE-318 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-7 Reporter: David Hoffer Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Attachments: MNG-3351-unittest.patch, MNG-3351.zip, MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, simple-testcase.zip After upgrading to 2.0.8 I find that the release plugin throws NPE if any dependency uses version range. I have one dependency with version range version[1.0,2.0)/version the rest are test scope with fixed version. Here is the crash stack trace: java.lang.NullPointerException: version was null for com.xrite:xrite-colorlib-api [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) [13:42:05]: at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) [13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) [13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) [13:42:05]: at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) [13:42:05]: at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) [13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [13:42:05]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) [13:42:05]: at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) [13:42:05]: at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) It seems the reason version is null is that the call to selectVersionFromNewRangeIfAvailable() assumes that versionRange.getRecommendedVersion() will always return non-null, else it sets the version to null! However during the release:prepare phase this is not true, see the output: [13:42:04]: [INFO] [release:prepare] [13:42:04]: [INFO] Verifying that there are no local modifications... [13:42:04]: [INFO] Executing: svn --non-interactive status [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... [13:42:05]: TEST!!! version=null [13:42:05]: TEST!!! versionRange=[1.0,2.0) [13:42:05]: TEST!!! getRecommendedVersion=null TEST!!! Lines are my test code so I could see what is going on here. -- This message is automatically generated by JIRA. -
[jira] Closed: (MASSEMBLY-187) Incorrect FileSet causes infinite loop
[ http://jira.codehaus.org/browse/MASSEMBLY-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-187. Resolution: Fixed Assignee: John Casey Incorrect FileSet causes infinite loop -- Key: MASSEMBLY-187 URL: http://jira.codehaus.org/browse/MASSEMBLY-187 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Linux JDK 1.5 Maven 2.0.4 Reporter: Jimisola Laursen Assignee: John Casey Priority: Minor Fix For: 2.2-beta-6 Using an incorrect FileSet (see example below) causes an infinite loop after [INFO] Building jar: ... have been outputed. ?xml version=1.0 encoding=UTF-8? assembly xmlns=http://maven.apache.org/ASSEMBLY/1.1.0-SNAPSHOT; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/ASSEMBLY/1.1.0-SNAPSHOT http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd; idpackage/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet includes include*:jar:*/include /includes excludes exclude*:sources/exclude /excludes /dependencySet /dependencySets fileSets fileSet directorytarget/directory /fileSet /fileSets /assembly -- 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: (MASSEMBLY-435) DependencySet: outputDirectory expression using ${artifact.baseVersion} uses equivalent of ${project.baseVersion}
[
http://jira.codehaus.org/browse/MASSEMBLY-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-435.
Resolution: Fixed
Assignee: John Casey
DependencySet: outputDirectory expression using ${artifact.baseVersion} uses
equivalent of ${project.baseVersion}
-
Key: MASSEMBLY-435
URL: http://jira.codehaus.org/browse/MASSEMBLY-435
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-4
Reporter: John Casey
Assignee: John Casey
Fix For: 2.2-beta-6
artifact.baseVersion should apply to the dependency artifact currently being
handled, and project.baseVersion should apply to the project for which an
assembly is being created. The difference should allow the user to file
dependency artifacts in a directory structure according to their base-version.
--
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: (MASSEMBLY-228) UnpackOptions filtered does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-228. Resolution: Fixed Fix Version/s: (was: 2.2) 2.2-beta-6 Assignee: John Casey (was: Petar Tahchiev) UnpackOptions filtered does not work Key: MASSEMBLY-228 URL: http://jira.codehaus.org/browse/MASSEMBLY-228 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: Windows XP with maven 2.0.7 Reporter: Elid OR Assignee: John Casey Fix For: 2.2-beta-6 Attachments: bug.tar.gz Here my configuration in my assembly descriptor file : dependencySets dependencySet unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions includemy-groupId:my-artifactId/include /dependencySets And this correctly unpack my dependencies but it does not filter the token in it. The token are put in a profile that a activate when build the project. -- 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: (MASSEMBLY-206) Filtering does not work when using in fileSet inside moduleSet
[ http://jira.codehaus.org/browse/MASSEMBLY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-206. Resolution: Fixed Fix Version/s: (was: 2.2) 2.2-beta-6 Assignee: John Casey Filtering does not work when using in fileSet inside moduleSet -- Key: MASSEMBLY-206 URL: http://jira.codehaus.org/browse/MASSEMBLY-206 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: win32 Reporter: Liya Katz Assignee: John Casey Fix For: 2.2-beta-6 i have a descriptor : moduleSet includes includecom.cc:module1/include includecom.cc:module2/include includecom.cc:module3/include /includes sources fileSets fileSet directorysrc/main/directory filteredtrue/filtered outputDirectorycore/outputDirectory includes includeconf/*/include /includes /fileSet /fileSets includeModuleDirectoryfalse/includeModuleDirectory /sources /moduleSet and although there is filteredtrue/filtered, the copied sources are not filtered. -- 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: (MASSEMBLY-272) getDescriptor and getDescriptorId should be deprecated.
[ http://jira.codehaus.org/browse/MASSEMBLY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-272. Resolution: Fixed Fix Version/s: (was: 2.2) 2.2-beta-6 Assignee: John Casey getDescriptor and getDescriptorId should be deprecated. --- Key: MASSEMBLY-272 URL: http://jira.codehaus.org/browse/MASSEMBLY-272 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Paul Gier Assignee: John Casey Priority: Minor Fix For: 2.2-beta-6 Attachments: maven-assembly-plugin-deprecation-r616611.patch The instance variables descriptor and descriptorId are deprecated. The matching getter and setter methods should also be deprecated with a comment about replacement. -- 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: (MASSEMBLY-150) Clarify or fix file relative scoping in assembly descriptor to be module centric or location of mvn execution
[ http://jira.codehaus.org/browse/MASSEMBLY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-150. Resolution: Fixed Assignee: John Casey Clarify or fix file relative scoping in assembly descriptor to be module centric or location of mvn execution --- Key: MASSEMBLY-150 URL: http://jira.codehaus.org/browse/MASSEMBLY-150 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: windows xp Reporter: Harold Shinsato Assignee: John Casey Fix For: 2.2-beta-6 According to http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the assembly descriptor's file source is supposed to be absolute or relative from the module's directory. This works when I execute mvn in the module directory. But when I run it from a top level super project, it seems to run from that higher level project. This isn't how the fileSet works, which we were using before, but we needed to set filtering to true, which caused this to break. So this is how we have to write this to make this work from the top level, but it breaks when running the assembly from this directory. files file sourcefileutil/src/main/scripts/FileUploadUtility.bat/source outputDirectoryfile-utility/outputDirectory filteredtrue/filtered /file /files This is how it used to be specified, where it worked both from the top level and from the subdirectory: fileSets fileSet directory../fileutil/directory outputDirectoryfile-utility/outputDirectory includes includeFileUploadUtility.bat/include /includes /fileSet /fileSets Hopefully this won't make a difference, but we've plugged our assembly into the execution of the package phase. This is copied from the pom.xml of the module. build plugins plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptors descriptorsrc/main/assembly/dist.xml/descriptor /descriptors /configuration executions execution goals goalattached/goal /goals phasepackage/phase /execution /executions /plugin /plugins /build -- 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: (MASSEMBLY-167) Property Expansion/Filtering does not always work for System.properties
[
http://jira.codehaus.org/browse/MASSEMBLY-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-167.
Resolution: Fixed
Assignee: John Casey
Property Expansion/Filtering does not always work for System.properties
---
Key: MASSEMBLY-167
URL: http://jira.codehaus.org/browse/MASSEMBLY-167
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: JDK 1.5.0_10, Maven 2.1-SNAPSHOT, Linux 2.6.18
Reporter: Daniel Krisher
Assignee: John Casey
Priority: Minor
Fix For: 2.2-beta-6
When using filtering for a file element in an assembly descriptor, System
properties (e.g. java.version) are not always available (and do not get
replaced in the filtered file).
For example, my assembly descriptor contains:
{noformat}
file
sourcesrc/main/files/config/splash.xml/source
outputDirectory/config/outputDirectory
filteredtrue/filtered
/file
{noformat}
and splash.xml (pre-filtering):
{noformat}
properties
entry key=title${project.name}/entry
entry key=Version${project.version}/entry
entry key=Compiled with Java ${java.version}/entry
/properties
{noformat}
Which results in a post-filtered splash.xml:
{noformat}
properties
entry key=titleACES Viewer/entry
entry key=Version0.7-SNAPSHOT/entry
entry key=Compiled with Java ${java.version}/entry
/properties
{noformat}
The problem appears to be in the 'initializeFiltering()' method of the
FileFormatter class. The filter properties are initialized using:
filterProperties = new Properties(System.getProperties());
Changing this to:
filterProperties = new Properties();
filterProperties.putAll(System.getProperties());
Seems to fix the problem.
The Properties javadocs are a little vague on the constructor parameter:
public Properties(Properties defaults)
Creates an empty property list with the specified defaults.
--
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: (MASSEMBLY-432) assembly misapplies depMgt and selects the wrong dependency for an archive
[ http://jira.codehaus.org/browse/MASSEMBLY-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-432. Resolution: Fixed assembly misapplies depMgt and selects the wrong dependency for an archive -- Key: MASSEMBLY-432 URL: http://jira.codehaus.org/browse/MASSEMBLY-432 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-3 Reporter: Brian Fox Assignee: John Casey Fix For: 2.2-beta-6 Attachments: assemblybug.zip Here's the setup: Parent has a depMgt set to version 1.3.4 Child has a dependency on 1.3.5 Assembly descriptor includes this dependency and 1.3.4 is bundled in, not 1.3.5. See attached project for a working example. First install the parent, second run package on the child. See the zip contains 1.3.4 instead of 1.3.5. Note: The real project where this happened has a property in the depMgt, if you use 2.0.10 this bug seems to not occur because the version is not interpolated in the pom that gets deployed. In 2.2 it is and causes this to manifest in the way I set it up, but fixing the version in the depMgt instead of using the property. -- 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: (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ http://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-360. Resolution: Fixed Fix Version/s: 2.2-beta-6 Assignee: John Casey add the container descriptor handler 'metaInf-spring' to consolidate these files. When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies. Key: MASSEMBLY-360 URL: http://jira.codehaus.org/browse/MASSEMBLY-360 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Windows XP, Java 5 Reporter: Marielle Enderman Assignee: John Casey Fix For: 2.2-beta-6 I'm working on a Java 5 project with maven 2 and I need to deliver an executable jar file. In this project I'm using different Spring dependencies: dependency groupIdorg.springframework/groupId artifactIdspring-beans/artifactId version2.5.5/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version2.5.5/version /dependency For maven packaging I'm using the maven-assembly plugin to create an executable jar with dependencies (using the jar-with-dependencies descriptor). Everything works fine, except that Spring's XSD files can't be found. At least: not all of them. The fact is: Every Spring JAR file contains a META-INF directory with files like spring.handlers and spring.schemas which contain list of locations of respectively namespace handlers and schemas. Unfortunately these files aren't merged during packaging so the META_INF of the executable JAR file only contains the last one added. This can result in errors like this: Example 1: The spring-context-2.5.xsd can't be found: WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored XML validation warning org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not xsd:schema. Example 2: The NamespaceHandler for the spring context namespace can't be located: Exception in thread main org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context] When I manually merge the files, the executable JAR file works fine. I hope this problem can be solved. -- 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: (MASSEMBLY-501) Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor
[ http://jira.codehaus.org/browse/MASSEMBLY-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-501. Resolution: Fixed use useAllReactorProjectstrue/useAllReactorProjects inside a moduleSet to enable access to all modules in the current reactor from binaries or sources. Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor - Key: MASSEMBLY-501 URL: http://jira.codehaus.org/browse/MASSEMBLY-501 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.2-beta-5 Reporter: John Casey Assignee: John Casey Fix For: 2.2-beta-6 Providing access to all modules in a reactor to a child project assembly will make moduleSet/binaries a viable option, since it allows the child project to run after all other projects. This will give it access to the binaries produced by sibling projects. Still need to work out whether there's a way to easily ensure it gets sorted down to the bottom...though I don't suppose that's necessarily required, as long as the modules it does depend on (through includes/excludes) are available by the time it builds. Project dependencies could always handle this, while the moduleSet usage would still open up avenues that dependencySets do not. -- 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: (MASSEMBLY-209) Service provider configuration files should be concatenated instead of overwritten
[ http://jira.codehaus.org/browse/MASSEMBLY-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-209. Resolution: Fixed Assignee: John Casey use container descriptor handler 'metaInf-services' to enable this. Service provider configuration files should be concatenated instead of overwritten -- Key: MASSEMBLY-209 URL: http://jira.codehaus.org/browse/MASSEMBLY-209 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1, 2.2-beta-1 Reporter: Arjohn Kampman Assignee: John Casey Fix For: 2.2-beta-6 Service provider configuration files are text files that define what service providers are available for a specific interface. These files are normally stored in /META-INF/services/ and are named after the interface that is implemented (e.g. java.io.spi.CharCodec). See for more info: http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider and http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html Building a onejar from a multi-module project where multiple modules have similarly named services files results in a jar-file that includes just one of the service files. As a result, just the providers that are mentioned in that file are seen by applications running from the onejar, providers that were mentioned in the other service files are not. To fix this, service files with identical names should simply be concatenated (making sure that there's a newline between the contents of each service file). -- 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: (MASSEMBLY-502) Convert to Java 1.5 Syntax / Requirement
[ http://jira.codehaus.org/browse/MASSEMBLY-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-502. Resolution: Fixed Convert to Java 1.5 Syntax / Requirement Key: MASSEMBLY-502 URL: http://jira.codehaus.org/browse/MASSEMBLY-502 Project: Maven 2.x Assembly Plugin Issue Type: Task Affects Versions: 2.2-beta-5 Reporter: John Casey Assignee: John Casey Fix For: 2.2-beta-6 -- 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: (MASSEMBLY-220) unpacked assemblies render different results when enumerating dependencies vs. using wildcards
[ http://jira.codehaus.org/browse/MASSEMBLY-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-220. Resolution: Fixed Fix Version/s: (was: 2.2) 2.2-beta-6 Assignee: John Casey unpacked assemblies render different results when enumerating dependencies vs. using wildcards -- Key: MASSEMBLY-220 URL: http://jira.codehaus.org/browse/MASSEMBLY-220 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: mvn 2.0.6, jdk 1.4.2 Reporter: Dirk Olmes Assignee: John Casey Fix For: 2.2-beta-6 Attachments: assembly-wildcard.xml, assembly.xml, pom.xml When using wildcards for assemblies which unpack jars, the contents of META-INF of the unpacked jars do not end up in the final JAR. This breaks systems which rely on the contents of the META-INF directory, e.g. Mule. I have attached a pom and two assemblies, one using wildcards and one enumerating all the dependencies. Run the assembly plugin on both descriptors and compare the resulting jars. -- 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: (MASSEMBLY-327) Using filtered within dependencySet unpackOptions
[ http://jira.codehaus.org/browse/MASSEMBLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-327. Resolution: Duplicate Fix Version/s: 2.2-beta-6 Assignee: John Casey duplicate of MASSEMBLY-206 Using filtered within dependencySet unpackOptions - Key: MASSEMBLY-327 URL: http://jira.codehaus.org/browse/MASSEMBLY-327 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Andy Yeung Assignee: John Casey Fix For: 2.2-beta-6 The files within the unpacked jar did not apply the filters defined. pom configuration includes configuration filters filtersrc/assemble/filter.properties/filter /filters /configuration which contains storage.id=abcde assembly.xml defines dependency set dependencySet outputDirectory/snp-agent1/outputDirectory unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions scoperuntime/scope includes include XXX.agent:agent-ear-config /include /includes /dependencySet However, the files within are not filtered. -- 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: (MASSEMBLY-424) poor performance of dependencySet in assembly descriptor (compared to using maven-dependency-plugin + fileSet)
[
http://jira.codehaus.org/browse/MASSEMBLY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-424.
Resolution: Fixed
Fix Version/s: 2.2-beta-6
Assignee: John Casey
dependency resolution only happens once with the new code, so it should be on
par with other plugins now once 2.2-beta-6 (or, hopefully, we'll call it 2.2
final) comes out.
poor performance of dependencySet in assembly descriptor (compared to using
maven-dependency-plugin + fileSet)
--
Key: MASSEMBLY-424
URL: http://jira.codehaus.org/browse/MASSEMBLY-424
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-4
Environment: maven 2.1.0, java 6u13, os x 10.5.6, macbook pro 5400rpm
disk
Reporter: Cameron Fieber
Assignee: John Casey
Priority: Critical
Fix For: 2.2-beta-6
The performance of the dependencySet element in the assembly descriptor is
significantly worse than achieving the equivalent result by doing an
execution of dependency:copy-dependencies and including the
target/dependencies folder as a fileSet in the assembly descriptor
replacing:
assembly
...
dependencySets
dependencySet
outputDirectorylib/outputDirectory
/dependencySet
/dependencySets
...
/assembly
with:
assembly
...
fileSet
directory${project.build.directory}/dependency/directory
outputDirectorylib/outputDirectory
/fileSet
...
/assembly
and (in pom.xml):
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
includeScoperuntime/includeScope
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
...
--
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: (MASSEMBLY-337) dependencySet with unpack=true cannot be used to make file permissions executable
[
http://jira.codehaus.org/browse/MASSEMBLY-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-337:
-
Fix Version/s: 2.2-beta-6
Assignee: John Casey
dependencySet with unpack=true cannot be used to make file permissions
executable
-
Key: MASSEMBLY-337
URL: http://jira.codehaus.org/browse/MASSEMBLY-337
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Maven 2.0.9, Java 1.6_04, tested on both Windows XP and
CentOS 4.1
Reporter: John Crim
Assignee: John Casey
Priority: Blocker
Fix For: 2.2-beta-6
Attachments: massembly-bug.tar.gz
The attached tar.gz contains 2 simple test projects which exhibit this bug:
# Project scripts-assembly generates
{{scripts-assembly-1.0-SNAPSHOT-scripts.zip}}, which contains a single file,
{{script.sh}}, with permissions {{-rwxr-xr-x}}
# Project assembly-filemode-bug depends on project scripts-assembly. It
extracts the scripts.zip file into its {{/bin}} directory when creating its
assembly.
{code:xml}
!-- Assembly descriptor for assembly-filemode-bug project --
dependencySets
dependencySet
outputFileNameMapping/outputFileNameMapping
outputDirectorybin/outputDirectory
unpacktrue/unpack
includes
includemaven-bugs:scripts-assembly:zip:scripts/include
/includes
fileMode0755/fileMode
/dependencySet
/dependencySets
{code}
The {{fileMode}} element does not have the desired effect. I'm not able to
find a workaround with 2.2-beta-2 that enables me to set the executable bit
on the scripts. From looking at other bugs in MASSEMBLY, I did try
configuring the scripts-assembly project to output a zip (also tried tar.gz)
containing the files with the executable bit set. This didn't change the
outcome - the files in package #2 are still not executable.
I consider this a highest priority bug, b/c I can find no way to get around
this limitation and make script files from a dependency executable within an
installable package. If I change to assembly plugin version 2.2-beta-1
(which admittedly has a significant list of bugs I'd like to avoid), this
works. I've also tried using other tar.gz for the assembly output of both
projects, but it didn't affect the outcome.
At this point I think my best path forward is to use assembly plugin version
2.2-beta-1.
--
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: (MWAR-237) packagingIncludes configuration has disappeared
packagingIncludes configuration has disappeared --- Key: MWAR-237 URL: http://jira.codehaus.org/browse/MWAR-237 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1 Environment: 2.2.1, 3.0RC1 Reporter: Stephen Coy Priority: Blocker The packagingIncludes configuration element has completely disappeared from this plugin. This not only breaks our skinny-war build, it also invalidates the documentation at http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.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
