[jira] (MJAR-156) Classpath created in manifest contains timestamp instead of the suffix "-SNAPSHOT"
[
https://jira.codehaus.org/browse/MJAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334032#comment-334032
]
gowri sankar commented on MJAR-156:
---
I suggest the workaround Markus provided above. it works perfectly fine. Thanks!
> Classpath created in manifest contains timestamp instead of the suffix
> "-SNAPSHOT"
> ---
>
> Key: MJAR-156
> URL: https://jira.codehaus.org/browse/MJAR-156
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2, 2.4
> Environment: Win7 Pro SP1 (64 Bit), JDK 1.6.0_26 (32 Bit)
>Reporter: Markus KARG
> Attachments: Sample.zip
>
>
> Sometimes the JAR packager replaces a dependency's "-SNAPSHOT" suffix by a
> timestamp when calculating a corresponding "Class-Path:"-entry for all
> dependencies into the MANIFEST.MF file of the packaged JAR. This is
> problematic, as typically the dependency shipped together with the created
> JAR will NOT be renamed, but shipped WITH the suffix "-SNAPSHOT". The created
> JAR will at runtime not find the JAR due to the wrong suffix then
> ("ClassNotFoundException" will happen for all content in the dependency,
> obviously). Strange but true, this seem to happen only for SOME JARs and only
> in SOME particular situations, but I was not able to identify the root causes.
> Attached is a tiny MVN project containing a pom that will produce this
> behaviour.
> * How to demonstrate:
> - Unpack attached JAR
> - Manually deploy the dependency "webdav-jaxrs-1.2-SNAPSHOT.jar" found in
> subfolder "install-this-in-repo" into the local repository.
> - mvn clean package
> - "target\sample-1.0.0-SNAPSHOT.jar" contains wrong MANIFEST.MF Class-Path:
> entry now:
> Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> (Sample output contained in ZIP\target!)
> Obviously "-SNAPSHOT" was replaced by "20120621.141509-35", what induces the
> problem that the actual dependency is not found, as its file ends still on
> "-SNAPSHOT" (by intention!). This scenario typically happens when both files
> end up in an EAR for example.
> * Expected Result:
> - Class-Path: webdav-jaxrs-1.2-SNAPSHOT.jar jsr311-api-1.1.1.jar
> * Actual Result:
> - Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> * Workaround:
> - Provide a static MANIFEST.MF file. Drawback: Changing dependency induces
> manual corrections to the static file.
> - Fix the entry manually after each build. Drawback: Hard to automate this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334031#comment-334031
]
Stephen Evanchik commented on MNG-5315:
---
Alternatively one can create a custom Component that adds this without
modifying maven-core. Here is an example against 3.1.2-SNAPSHOT and a 3.0.x:
https://github.com/evanchsa/maven-parallel-resolver.git
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoo
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Evanchik updated MNG-5315:
--
Attachment: MNG-5315-3.0.x.patch
Patch suitable for the 3.0.x branch
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.project.DependencyResolutionException: Could not
> res
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Evanchik updated MNG-5315:
--
Attachment: MNG-5315-3.1.2-SNAPSHOT.patch
Simple synchronization as proposed in this issue against 3.1.2-SNAPSHOT
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.project.DependencyResolutionExce
[jira] (SUREFIRE-1038) Regression: Method depends on nonexistent group
[
https://jira.codehaus.org/browse/SUREFIRE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334016#comment-334016
]
Andreas Gudian commented on SUREFIRE-1038:
--
Could you create a small sample Project to demonstrate the bug and attach it to
this issue? That would make things easier for us. Thanks!
> Regression: Method depends on nonexistent group
> ---
>
> Key: SUREFIRE-1038
> URL: https://jira.codehaus.org/browse/SUREFIRE-1038
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.16
>Reporter: Gili
>Priority: Critical
>
> Version 2.16 contains a regression that prevents the use of TestNG groups.
> Version 2.15 works fine.
> When I run my unit tests I get the following error:
> {code}
> Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project web.backend: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
> error in the forked process
> org.testng.TestNGException:
> DependencyMap::Method "CallTest.createCall()[pri:0,
> instance:com.vtlr.web.backend.resource.CallTest@53635ac1]" depends on
> nonexistent group "department"
> at org.testng.DependencyMap.getMethodsThatBelongTo(DependencyMap.java:46)
> at org.testng.TestRunner.createDynamicGraph(TestRunner.java:1074)
> at org.testng.TestRunner.privateRun(TestRunner.java:734)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:91)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:204)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:107)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> I checked and group "department" exists. Furthermore, downgrading back to
> 2.15 makes the problem go away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-96) Skip option for install-file
[ https://jira.codehaus.org/browse/MINSTALL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334009#comment-334009 ] Ivan Bondarenko commented on MINSTALL-96: - The same need here, but for a bit different task. We need to run install-file on internal properties condition. Currently we can only put intall-file into profile (only external parameter condition will work) or perform operation in any case. We have chosen later as lesser of two evils, but now some artifacts are installed twice (not a good practice). > Skip option for install-file > > > Key: MINSTALL-96 > URL: https://jira.codehaus.org/browse/MINSTALL-96 > Project: Maven Install Plugin > Issue Type: Improvement > Components: install:install-file >Affects Versions: 2.4 >Reporter: Tiemo Vorschütz > Attachments: InstallFileMojo.java.patch > > > For my process it would be helpful to also introduce a skip option for > install:install-file to be able to disable install-file creation by setting a > pom property. > This could be necessary if the build chain is designed by a parent pom and > should by simply modified inside the child pom. > In my case all plugin definitions are outsourced to the parent pom file and > should only be set by properties by the developers to take care that > modifications to the build chain are inherited. > I attached a patch to enable skipping also for install-file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-170) Plugin configuration on module level is ignored when deployAtEnd
[ https://jira.codehaus.org/browse/MDEPLOY-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-170. -- Resolution: Fixed Fix Version/s: 2.8.1 Fixed in [r1531347|http://svn.apache.org/r1531347] > Plugin configuration on module level is ignored when deployAtEnd > > > Key: MDEPLOY-170 > URL: https://jira.codehaus.org/browse/MDEPLOY-170 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy > Environment: Mac OS 10.8.5, Oracle JDK 1.7.0_25, Maven 3.0.5 >Reporter: Anders Hammar >Assignee: Robert Scholte > Fix For: 2.8.1 > > Attachments: IT-deploy-at-end-multimodule-indicidual-config.patch > > > The configuration for the plugin used when deploying at end is for the > project where the deployment is taking place. The config for each module is > ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical
[
https://jira.codehaus.org/browse/MRELEASE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333998#comment-333998
]
Jörg Schaible commented on MRELEASE-849:
I would have expected that Maven refuses to process this POM at all, because it
is self-referencing.
> Release plugin replaces parent version with pom version when
> groupId/artifactId are identical
> -
>
> Key: MRELEASE-849
> URL: https://jira.codehaus.org/browse/MRELEASE-849
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4.1
>Reporter: Tuomas Kiviaho
>Priority: Blocker
> Attachments: AbstractRewritePomsPhase.patch
>
>
> POM rewriting for release phase doesn't handle well the following use case.
> Parent version will be replaced which is not the intention here.
> {code:xml|title=pom.xml}
>
> 4.0.0
>
> foo
> bar
> 1
>
> foo
> bar
> 2-SNAPSHOT
> pom
>
> {code}
> I would assume this to be perfectly valid when introducing a new
> non-backwards compatible feature to a parent pom. Probably I could replace
> the inheritance with delegation by using
> pluginManagement/dependencyManagement sections and import scope but I don't
> think there's similar notation for profiles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-159) install-goal should use same mavenHome as run-goal
Robert Scholte created MINVOKER-159:
---
Summary: install-goal should use same mavenHome as run-goal
Key: MINVOKER-159
URL: https://jira.codehaus.org/browse/MINVOKER-159
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 1.8
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
Maven home: D:\apache-maven-3.0.5\bin\..
Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_25\jre
Default locale: nl_NL, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Robert Scholte
Priority: Critical
When running the build with M3, and the invoker with M2.0.6 as mavenHome, you
get an exception like
{noformat}
Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException:
Unable to read local copy of metadata: Cannot read metadata from
'E:\java-workspace\apache-maven-plugins\maven-deploy-plugin\target\local-repo\org\apache\maven\plugins\maven-deploy-plugin\2.9-SNAPSHOT\maven-metadata-local.xml':
expected START_TAG or END_TAG not TEXT (position: TEXT seen
...jarjarjarjarhttp://www.atlassian.com/software/jira
[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical
[
https://jira.codehaus.org/browse/MRELEASE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated MRELEASE-849:
Attachment: AbstractRewritePomsPhase.patch
> Release plugin replaces parent version with pom version when
> groupId/artifactId are identical
> -
>
> Key: MRELEASE-849
> URL: https://jira.codehaus.org/browse/MRELEASE-849
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4.1
>Reporter: Tuomas Kiviaho
>Priority: Blocker
> Attachments: AbstractRewritePomsPhase.patch
>
>
> POM rewriting for release phase doesn't handle well the following use case.
> Parent version will be replaced which is not the intention here.
> {code:xml|title=pom.xml}
>
> 4.0.0
>
> foo
> bar
> 1
>
> foo
> bar
> 2-SNAPSHOT
> pom
>
> {code}
> I would assume this to be perfectly valid when introducing a new
> non-backwards compatible feature to a parent pom. Probably I could replace
> the inheritance with delegation by using
> pluginManagement/dependencyManagement sections and import scope but I don't
> think there's similar notation for profiles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical
Tuomas Kiviaho created MRELEASE-849:
---
Summary: Release plugin replaces parent version with pom version
when groupId/artifactId are identical
Key: MRELEASE-849
URL: https://jira.codehaus.org/browse/MRELEASE-849
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.4.1
Reporter: Tuomas Kiviaho
Priority: Blocker
POM rewriting for release phase doesn't handle well the following use case.
Parent version will be replaced which is not the intention here.
{code:xml|title=pom.xml}
4.0.0
foo
bar
1
foo
bar
2-SNAPSHOT
pom
{code}
I would assume this to be perfectly valid when introducing a new non-backwards
compatible feature to a parent pom. Probably I could replace the inheritance
with delegation by using pluginManagement/dependencyManagement sections and
import scope but I don't think there's similar notation for profiles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-171) Remove deprecated readonly parameters
Anders Hammar created MDEPLOY-171: - Summary: Remove deprecated readonly parameters Key: MDEPLOY-171 URL: https://jira.codehaus.org/browse/MDEPLOY-171 Project: Maven Deploy Plugin Issue Type: Improvement Components: deploy:deploy Environment: n/a Reporter: Anders Hammar Priority: Trivial There are several readonly parameters that have been marked as deprecated. I don't see any point in keeping them as they are readonly and can't be configured outside of the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
