[jira] (MANTRUN-98) multiple input tasks leads to exception
[
https://jira.codehaus.org/browse/MANTRUN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298732#comment-298732
]
Patrick Bray commented on MANTRUN-98:
-
I have just encountered this issue with Maven version 3.0.4:
Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
Running with antrun:
maven-antrun-plugin
1.7
> multiple input tasks leads to exception
> ---
>
> Key: MANTRUN-98
> URL: https://jira.codehaus.org/browse/MANTRUN-98
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: 32-bit Linux, Sun JDK 1.6.0_07, Maven 2.0.9
>Reporter: Andy Schlaikjer
>
> Running more than one task within Antrun plugin causes exception:
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> Please enter test-value-01 [123]
> Please enter test-value-02 [456]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An Ant BuildException has occured: Failed to read input from Console.
> Stream closed
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException
> has occured: Failed to read input from Console.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant
> BuildException has occured: Failed to read input from Console.
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 16 more
> Caused by: Failed to read input from Console.
> at
> org.apache.tools.ant.input.DefaultInputHandler.handleInput(DefaultInputHandler.java:59)
> at org.apache.tools.ant.taskdefs.Input.execute(Input.java:231)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
> ... 19 more
> Caused by: java.io.IOException: Stream closed
> at
> java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
> at java.io.BufferedInputStream.read(BufferedInput
[jira] (SUREFIRE-659) Maven PDF plugin:showSuccess=false creates empty table causing error
[ https://jira.codehaus.org/browse/SUREFIRE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed SUREFIRE-659. -- Resolution: Fixed Fix Version/s: 2.13 Assignee: Lukas Theussl Fixed in [r1338590|http://svn.apache.org/viewvc?view=revision&revision=1338590]. Note that the issue is only relevant with Maven 2, the pdf plugin does not generate any reports with Maven 3 (MPDF-41). > Maven PDF plugin:showSuccess=false creates empty table causing error > > > Key: SUREFIRE-659 > URL: https://jira.codehaus.org/browse/SUREFIRE-659 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.6 > Environment: maven 2.2.1, surefire 2.6, maven-pdf-plugin >Reporter: Darren Hartford >Assignee: Lukas Theussl > Fix For: 2.13 > > > The problem is that for > showSuccess=false an empty table is written but fo expects some > tableRows even if they are empty. > Cheers, > -Lukas > Darren Hartford wrote: > > Hey all, > > Not sure where to put this issue, but using the surefire-report(2.6) with > > showSuccess=false, with the maven-pdf-plugin (1.1) breaks. This is using a > > multi-module/aggregate report approach, maven 2.2.1. With > > showSuccess=true, everything works fine. > > > > Basic intent is to, on a release, create an aggregate/summary PDF of the > > release, but some of the items. such as the surefire-report, are too > > verbose. > > > > > > org.apache.maven.plugins > > maven-surefire-report-plugin > > 2.6 > > > > > >false > > true > > > > > > > > > > > > > > > > Error > > === > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Error during document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > > > [INFO] > > > > [DEBUG] Trace > > org.apache.maven.lifecycle.LifecycleExecutionException: Error during > > document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > > 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 during > > document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:574) > > at org.apache.maven.plugins.pdf.PdfMojo.
[jira] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298745#comment-298745
]
Christoph Gritschenberger commented on MASSEMBLY-557:
-
I'm not sure that's it.
We do not use either nor in our assembly-descriptor.
The "config" directory in question, is part of the assembly's src-folder (-->
it's copied from target/classes).
We basically unpack another assembly (apache-karaf) and among other things add
an additional folder named "config".
The unpacking we configured using an execution-configuration in the assembly's
pom.xml
{code}
org.apache.maven.plugins
maven-dependency-plugin
unpack-unix
generate-resources
unpack
org.apache.karaf
apache-karaf
tar.gz
target/dependencies/unix
...
{code}
The config-directory is added using a
{code}
...
target/classes/config
/config/
dos
0644
...
{code}
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298745#comment-298745
]
Christoph Gritschenberger edited comment on MASSEMBLY-557 at 5/15/12 4:54 AM:
--
I'm not sure that's it.
We do not use either nor in our assembly-descriptor.
The "config" directory in question, is part of the assembly's src-folder (-->
it's copied from target/classes).
We basically unpack another assembly (apache-karaf) and among other things add
an additional folder named "config".
The unpacking we configured using an execution-configuration in the assembly's
pom.xml
{code}
org.apache.maven.plugins
maven-dependency-plugin
unpack-unix
generate-resources
unpack
org.apache.karaf
apache-karaf
tar.gz
target/dependencies/unix
...
{code}
The config-directory is added using a
{code}
...
target/classes/config
/config/
dos
0644
...
{code}
You can browse the full source at
https://github.com/openengsb/openengsb-framework/tree/v2.4.2/assembly
Currently we downgraded the assembly-plugin to 2.2.2 as a workaround (the
thing is not in the main tree yet).
was (Author: christophgr):
I'm not sure that's it.
We do not use either nor in our assembly-descriptor.
The "config" directory in question, is part of the assembly's src-folder (-->
it's copied from target/classes).
We basically unpack another assembly (apache-karaf) and among other things add
an additional folder named "config".
The unpacking we configured using an execution-configuration in the assembly's
pom.xml
{code}
org.apache.maven.plugins
maven-dependency-plugin
unpack-unix
generate-resources
unpack
org.apache.karaf
apache-karaf
tar.gz
target/dependencies/unix
...
{code}
The config-directory is added using a
{code}
...
target/classes/config
/config/
dos
0644
...
{code}
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secu
[jira] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Art O Cathain updated MDEP-194:
---
Attachment: mdp-194-src-main-aoc.diff
I have a new patch, based on Nicolás Cornaglia's patch C attached to MDEP-187.
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: https://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments:
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
> mdep-194-its-aoc.diff, mdp-194-src-main-aoc.diff,
> plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Art O Cathain updated MDEP-194:
---
Attachment: mdep-194-its-aoc.diff
I have also created some integration tests
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: https://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments:
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
> mdep-194-its-aoc.diff, mdp-194-src-main-aoc.diff,
> plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298746#comment-298746
]
Art O Cathain edited comment on MDEP-194 at 5/15/12 5:11 AM:
-
I have a new patch, based on Nicolas Cornaglia's patch C attached to MDEP-187.
was (Author: artbristol):
I have a new patch, based on Nicolás Cornaglia's patch C attached to
MDEP-187.
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: https://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments:
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
> mdep-194-its-aoc.diff, mdp-194-src-main-aoc.diff,
> plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298748#comment-298748 ] Art O Cathain commented on MDEP-187: Nicolas, I fiddled with your patch a bit (to add some debug logging) and added integration tests. I attached the result to MDEP-194. Can you take a look? > dependency:copy fails when invoked from m2e with workspace resolution enabled > - > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Brian Fox > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-98) The source must not be a directory
[ https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298749#comment-298749 ] Art O Cathain commented on MDEP-98: --- There is some more activity on the duplicate MDEP-194. Can you try the patch there? > The source must not be a directory > -- > > Key: MDEP-98 > URL: https://jira.codehaus.org/browse/MDEP-98 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 > Environment: Windows XP Professional SP2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) >Reporter: Pablo Muñiz >Assignee: Brian Fox > Attachments: MDEP-98-ITs.patch, > mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip > > > Using maven-dependency-plugin in a multimodule project inside a module wich > has a dependency with another module in the same project the next error > ocurrs : > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > at > org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98) > at > org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84) > at > org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232) > at > org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error unpacking file: > c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: > c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > Project structure is as follows: > plataforma > - platform-core > - platform-bundle > - platform-bundle-jar > - platform-bundle-src > and the error happens on executing any goal from parent pom. > maven-dependency-plugin seems to receive a reference to target/classes > directory for platform-core dependency instead of the URL to my local > repository where platform-core is located. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-318) Allow tags to be removed
[ https://jira.codehaus.org/browse/SCM-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298750#comment-298750 ] Chris Graham commented on SCM-318: -- Just be aware, that not all SCM's will support this functionality. For instance, Jazz SCM does not currently have a "delete snapshot" command needed to implement this feature (I've requested it). > Allow tags to be removed > > > Key: SCM-318 > URL: https://jira.codehaus.org/browse/SCM-318 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api >Affects Versions: 1.0-rc1 >Reporter: Mark Hobson > Fix For: 1.x > > > Need to add an untag or removeTag method to ScmProvider to reverse the tag > operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-725) Releasing a specific module-based project fails (Regression from 2.1)
[ https://jira.codehaus.org/browse/MRELEASE-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Paland closed MRELEASE-725. --- Resolution: Fixed Fix Version/s: 2.3 This is fixed in 2.3 > Releasing a specific module-based project fails (Regression from 2.1) > - > > Key: MRELEASE-725 > URL: https://jira.codehaus.org/browse/MRELEASE-725 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.2, 2.2.1, 2.2.2 > Environment: Mac OS X 10.7.2 > Apache Maven 3.0.3 > Subversion 1.6.16 (r1073529) >Reporter: Philipp Paland > Fix For: 2.3 > > Attachments: transscript.txt, trunk.zip > > > We can not release our project with a version of the release plugin greater > than 2.1. > I have distilled the problem to a small example project (attached as zip). > The project has a core module (with code) and an aggregating build project, > like this: > -> build > -> release > -> pom.xml > -> core > -> hello-world > -> pom.xml > -> src/main/java/HelloWorld.java > where "hello-world" is a module of "release". > It looks like release:perform tries to build in the wrong directory: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:2.2.2:perform (default-cli) on > project release: Error executing Maven. Working directory > "/Development/maven-release-bug/trunk/build/release/target/checkout/build/release/build/release" > does not exist! -> [Help 1] > I have also attached a transscript with some easy steps to reproduce the > problem. First, a local svn repo is created. Then, the working release with > 2.1 is demonstrated. Then the plugin version in the pom is changed and the > error is shown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5120) Reg:How to build a project when building another project implicitely
[ https://jira.codehaus.org/browse/MNG-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298777#comment-298777 ] Art O Cathain commented on MNG-5120: You can use the --also-make-dependents or --also-make flags of the mvn command. You should close this ticket, it's not a bug. > Reg:How to build a project when building another project implicitely > > > Key: MNG-5120 > URL: https://jira.codehaus.org/browse/MNG-5120 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: krishna prasad vurapalli > > When we are building a project and that project contains dependency from > another project then we have to add the dependency explicitly . Instead of > doing like that is there is any way to build the dependent project while > building the main project implicitly that is we have to take the project name > from the command prompt and that will be dependent project name and that > project has to be build first and then that dependency will be added to our > main project -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5107) bootstrap-building from source fails when behind HTTP proxy
[ https://jira.codehaus.org/browse/MNG-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298786#comment-298786 ] Art O Cathain commented on MNG-5107: This seems to work in 3.0.4? > bootstrap-building from source fails when behind HTTP proxy > --- > > Key: MNG-5107 > URL: https://jira.codehaus.org/browse/MNG-5107 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.3 > Environment: Ant 1.8.2, J2SE JDK 1.6.0_25 downloaded from Oracle, > SUSE Enterprise 11 SP0, Linux x86 2.6.27 kernel >Reporter: Rabbe Fogelholm > > Bootstrap building from source does not work. The > apache-maven-3.0.3-src.tar.gz contains a README.bootstrap.txt file that > explains how to do it. It does not say what to do when behind an HTTP proxy, > but by googling I gathered that a config file should be placed in > $HOME/.m2/settings.xml. > I tried to do so, with the file containing (X.Y.Z of course replaced by the > actual proxy hostname) > > > > true > http > X.Y.Z > 8080 > localhost > > > > I also set the JAVA_HOME, ANT_HOME and PATH variables and checked that `java > -version' and `ant -version' behaved as expected. > The console output that I get is: > $ ant > Buildfile: /local/scratch/eraswiv4/mbug/maven/apache-maven-3.0.3/build.xml > clean-bootstrap: > initTaskDefs: > isMavenHomeSet: > init: > [echo] maven.home = > /local/tmp/eraswiv4/mbug/maven/apache-maven-3.0-SNAPSHOT > [echo] maven.repo.local = /home/eraswiv4/.m2/repository > prompt-maven-home-exists: > pull: > [artifact:pom] Downloading: > org/apache/maven/maven-parent/15/maven-parent-15.pom from repository central > at http://repo1.maven.org/maven2 > At this point the command hangs for a long time and fails with > [artifact:pom] Error transferring file: Connection timed out > [artifact:pom] [WARNING] Unable to get resource > 'org.apache.maven:maven-parent:pom:15' from repository central > (http://repo1.maven.org/maven2): Error transferring file: Connection timed out > [artifact:pom] An error has occurred while processing the Maven artifact > tasks. > [artifact:pom] Diagnosis: > [artifact:pom] > [artifact:pom] Unable to initialize POM dependencies.xml: Cannot find parent: > org.apache.maven:maven-parent for project: null:maven:pom:3.0.3 for project > null:maven:pom:3.0.3 > [artifact:pom] Unable to download the artifact from any repository > BUILD FAILED > /local/scratch/eraswiv4/mbug/maven/apache-maven-3.0.3/build.xml:97: Unable to > initialize POM dependencies.xml: Cannot find parent: > org.apache.maven:maven-parent for project: null:maven:pom:3.0.3 for project > null:maven:pom:3.0.3 > Total time: 3 minutes 13 seconds -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-130) Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging)
[
https://jira.codehaus.org/browse/MENFORCER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-130:
-
Description:
Hi there,
I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their
dependencies a bit, so that we managed them in our pom:
{code:xml}
org.jboss.logging
jboss-logging
3.1.0.GA
{code}
The dependency tree looks good. The dependency jboss-logging 3.1.0.CR2 is
"overwritten" by the above definition:
{noformat}
[INFO] | \- ourgroup:nic-api:jar:103:compile
[INFO] | +- ourgroup:persistence:jar:2.22-Hibernate4:compile
[INFO] | | +- org.springframework:spring-test:jar:3.1.1.RELEASE:compile
[INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile
[INFO] | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile -
omitted for duplicate)
[INFO] | | +- de.hypoport.ef2:ef2-core:jar:2.22-Hibernate4:compile
[INFO] | | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile -
omitted for duplicate)
[INFO] | | | \-
org.springframework:spring-context:jar:3.1.1.RELEASE:compile
[INFO] | | | +-
(org.springframework:spring-beans:jar:3.1.1.RELEASE:compile - omitted for
duplicate)
[INFO] | | | \-
org.springframework:spring-expression:jar:3.1.1.RELEASE:compile
[INFO] | | +- org.hibernate:hibernate-core:jar:4.1.2.Final:compile
[INFO] | | | +- org.jboss.logging:jboss-logging:jar:3.1.0.GA:compile
[INFO] | | | +-
org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:compile
[INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile
[INFO] | | | +-
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile
[INFO] | | | +- org.javassist:javassist:jar:3.15.0-GA:compile
[INFO] | | | \-
org.hibernate.common:hibernate-commons-annotations:jar:4.0.1.Final:compile
[INFO] | | | \- (org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile
- omitted for conflict with 3.1.0.GA)
{noformat}
Running the enforcer rule DependencyConvergence results in an error:
{noformat}
[ERROR]
Dependency convergence error for org.jboss.logging:jboss-logging:3.1.0.GA paths
to dependency are:
+-ourgroup:rules-assembly:11-SNAPSHOT
+-ourgroup:scoring:139
+-ourgroup:nic-api:103
+-ourgroup:persistence:2.22-Hibernate4
+-org.hibernate:hibernate-core:4.1.2.Final
+-org.jboss.logging:jboss-logging:3.1.0.GA
and
+-ourgroup:rules-assembly:11-SNAPSHOT
+-ourgroup:scoring:139
+-ourgroup:nic-api:103
+-ourgroup:persistence:2.22-Hibernate4
+-org.hibernate:hibernate-core:4.1.2.Final
+-org.hibernate.common:hibernate-commons-annotations:4.0.1.Final
+-org.jboss.logging:jboss-logging:3.1.0.CR2
{noformat}
This feels unexpected. Is this a bug, or do I understand s.th. wrong:)
Thanks a lot, Leif
was:
Hi there,
I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their
dependencies a bit, so that we managed them in our pom:
org.jboss.logging
jboss-logging
3.1.0.GA
The dependency tree looks good. The dependency jboss-logging 3.1.0.CR2 is
"overwritten" by the above definition:
[INFO] | \- ourgroup:nic-api:jar:103:compile
[INFO] | +- ourgroup:persistence:jar:2.22-Hibernate4:compile
[INFO] | | +- org.springframework:spring-test:jar:3.1.1.RELEASE:compile
[INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile
[INFO] | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile -
omitted for duplicate)
[INFO] | | +- de.hypoport.ef2:ef2-core:jar:2.22-Hibernate4:compile
[INFO] | | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile -
omitted for duplicate)
[INFO] | | | \-
org.springframework:spring-context:jar:3.1.1.RELEASE:compile
[INFO] | | | +-
(org.springframework:spring-beans:jar:3.1.1.RELEASE:compile - omitted for
duplicate)
[INFO] | | | \-
org.springframework:spring-expression:jar:3.1.1.RELEASE:compile
[INFO] | | +- org.hibernate:hibernate-core:jar:4.1.2.Final:compile
[INFO] | | | +- org.jboss.logging:jboss-logging:jar:3.1.0.GA:compile
[INFO] | | | +-
org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:compile
[INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile
[INFO] | | | +-
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile
[INFO] | | | +- org.javassist:javassist:jar:3.15.0-GA:compile
[INFO] | | | \-
org.hibernate.common:hibernate-commons-annotations:jar:4.0.1.Final:compile
[INFO] | | | \- (org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile
- omitted for conflict with 3.1.0.GA)
Running the enforcer rule DependencyConvergence results in an error:
[ERROR]
Dependency convergence error for org.jboss.logging:jboss-logging:3.1.0.GA paths
to dependency are:
+-
[jira] (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298807#comment-298807
]
Dustin Parker commented on MDEP-259:
I'm watching this bug because of the Cobertura plugin. We updated Sonar and our
builds started failing. I noticed that this error was happening during code
coverage analysis (in our WAR module). Switching to JaCoCo worked around the
problem.
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: https://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
>Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> [INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory)
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-130) Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging)
[
https://jira.codehaus.org/browse/MENFORCER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-130.
Resolution: Not A Bug
Assignee: Robert Scholte
The dependencyConvergence rule checks if all dependencies (direct and
transitive) refer to the same version. This way you know for sure that every
dependency uses the same dependencies as it was released.
You might be interested in
[requireUpperBoundDeps|http://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html],
a new rule which has just been released.
> Strange difference between enforcer dependency convergence and dependency
> tree (hibernate4/jboss-logging)
> -
>
> Key: MENFORCER-130
> URL: https://jira.codehaus.org/browse/MENFORCER-130
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0.1
> Environment: MacOSX && Linux RedHead
>Reporter: leif hanack
>Assignee: Robert Scholte
>
> Hi there,
> I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their
> dependencies a bit, so that we managed them in our pom:
> {code:xml}
>
> org.jboss.logging
> jboss-logging
> 3.1.0.GA
>
> {code}
> The dependency tree looks good. The dependency jboss-logging 3.1.0.CR2 is
> "overwritten" by the above definition:
> {noformat}
> [INFO] | \- ourgroup:nic-api:jar:103:compile
> [INFO] | +- ourgroup:persistence:jar:2.22-Hibernate4:compile
> [INFO] | | +- org.springframework:spring-test:jar:3.1.1.RELEASE:compile
> [INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile
> [INFO] | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile -
> omitted for duplicate)
> [INFO] | | +- de.hypoport.ef2:ef2-core:jar:2.22-Hibernate4:compile
> [INFO] | | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile
> - omitted for duplicate)
> [INFO] | | | \-
> org.springframework:spring-context:jar:3.1.1.RELEASE:compile
> [INFO] | | | +-
> (org.springframework:spring-beans:jar:3.1.1.RELEASE:compile - omitted for
> duplicate)
> [INFO] | | | \-
> org.springframework:spring-expression:jar:3.1.1.RELEASE:compile
> [INFO] | | +- org.hibernate:hibernate-core:jar:4.1.2.Final:compile
> [INFO] | | | +- org.jboss.logging:jboss-logging:jar:3.1.0.GA:compile
> [INFO] | | | +-
> org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:compile
>
> [INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile
> [INFO] | | | +-
> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile
> [INFO] | | | +- org.javassist:javassist:jar:3.15.0-GA:compile
> [INFO] | | | \-
> org.hibernate.common:hibernate-commons-annotations:jar:4.0.1.Final:compile
> [INFO] | | | \-
> (org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile - omitted for conflict
> with 3.1.0.GA)
> {noformat}
> Running the enforcer rule DependencyConvergence results in an error:
> {noformat}
> [ERROR]
> Dependency convergence error for org.jboss.logging:jboss-logging:3.1.0.GA
> paths to dependency are:
> +-ourgroup:rules-assembly:11-SNAPSHOT
> +-ourgroup:scoring:139
> +-ourgroup:nic-api:103
> +-ourgroup:persistence:2.22-Hibernate4
> +-org.hibernate:hibernate-core:4.1.2.Final
> +-org.jboss.logging:jboss-logging:3.1.0.GA
> and
> +-ourgroup:rules-assembly:11-SNAPSHOT
> +-ourgroup:scoring:139
> +-ourgroup:nic-api:103
> +-ourgroup:persistence:2.22-Hibernate4
> +-org.hibernate:hibernate-core:4.1.2.Final
> +-org.hibernate.common:hibernate-commons-annotations:4.0.1.Final
> +-org.jboss.logging:jboss-logging:3.1.0.CR2
> {noformat}
> This feels unexpected. Is this a bug, or do I understand s.th. wrong:)
> Thanks a lot, Leif
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-603) Allow configuration of goals to be executed after release creation
[
https://jira.codehaus.org/browse/MRELEASE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298811#comment-298811
]
Robert Scholte commented on MRELEASE-603:
-
So the story is clear. But I'm just wondering what is wrong with the
[completionGoals|http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#completionGoals]
during {{release:prepare}}? If I'm correct this was exactly why Stephen added
MRELEASE-621.
I can't think of a reason why you want to wait untill the project is checked
out by tag and deployed. ( And you'll get the checkin for free during the
prepare :) )
> Allow configuration of goals to be executed after release creation
> --
>
> Key: MRELEASE-603
> URL: https://jira.codehaus.org/browse/MRELEASE-603
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Marcus Linke
>Assignee: Robert Scholte
>Priority: Minor
>
> It would be nice if the release plugin allows the configuration of some goals
> to be executed after the release creation. This could be used for example to
> configure the automatic execution of the maven-versions-plugin to update the
> dependencies versions of the newly created snaphot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-708) mvn eclipse:eclipse fails with NullPointerException on Java 7 if pom.xml contains version range
[ https://jira.codehaus.org/browse/MECLIPSE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298812#comment-298812 ] Luiz Fernando Oliveira Corte Real commented on MECLIPSE-708: Also confirmed on Maven 3.0.4, Linux 3.2.0 32 bits and Java 7u4 > mvn eclipse:eclipse fails with NullPointerException on Java 7 if pom.xml > contains version range > --- > > Key: MECLIPSE-708 > URL: https://jira.codehaus.org/browse/MECLIPSE-708 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.8 > Environment: Win 7 (32 Bit), JDK 1.7.0_02, MVN 3.0.3, de_DE, Cp1252 >Reporter: Markus KARG >Priority: Blocker > > If pom.xml contains version range (e. g. like this one: > > > javax.ws.rs > jsr311-api > [1.1,1.2) > > > ) and JDK 1.7.0_02 is used, mvn eclipse:eclipse fails with > NullPointerException: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on > project webdav-jaxrs: Execution default-cli of goal > org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse failed. > NullPointerException -> [Help 1] > The bug location seems to be around this place: > Caused by: java.lang.NullPointerException > at > org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:353) > at > org.apache.maven.artifact.versioning.ComparableVersion.(ComparableVersion.java:344) > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.parseVersion(DefaultArtifactVersion.java:111) > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.(DefaultArtifactVersion.java:47) > at > org.apache.maven.artifact.DefaultArtifact.compareTo(DefaultArtifact.java:433) > at > org.apache.maven.artifact.DefaultArtifact.compareTo(DefaultArtifact.java:43) > at java.util.TreeMap.compare(TreeMap.java:1188) > at java.util.TreeMap.put(TreeMap.java:531) > at java.util.TreeSet.add(TreeSet.java:255) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.getProjectArtifacts(AbstractIdeSupportMojo.java:786) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:560) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:507) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-166) runtime-scoped dependencies should be specially handled
[ https://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298817#comment-298817 ] Ron Ratovsky commented on MDEP-166: --- Is this a dead issue? It's opened for 4 years, version 3.X is already out. Any hope? > runtime-scoped dependencies should be specially handled > --- > > Key: MDEP-166 > URL: https://jira.codehaus.org/browse/MDEP-166 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: Max Bowsher >Assignee: Brian Fox > Fix For: 2.5 > > > Currently the plugin warns that runtime-scope dependencies are unused. > It should understand that the correct status for a runtime-scoped dependency > is to *not* be discoverable in the bytecode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-654) Release:perform fails on releasing a tag from an empty directory
[
https://jira.codehaus.org/browse/MRELEASE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298824#comment-298824
]
Jameson Porter commented on MRELEASE-654:
-
I am also seeing this with Maven 3.0.3 and 3.0.4 with version plugin versions
2.2.1, 2.2.2, and 2.3.
> Release:perform fails on releasing a tag from an empty directory
>
>
> Key: MRELEASE-654
> URL: https://jira.codehaus.org/browse/MRELEASE-654
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.1
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
>Reporter: Giacomo Boccardo
>
> If we release our project from the same directory when we executed the
> release:prepare the perform phase completes successfully, while performing a
> release from a tag (in an empty directory) we have the following stack trace:
> {noformat}
> $ mvn release:perform -Dtag=unilet-base-5.3.13
> -DconnectionUrl=scm:svn:https://srvdevel.unimatica.lan/svn/unilet -X
> Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
> [INFO] Error stacktraces are turned on.
> [DEBUG] Reading global settings from /usr/local/app/maven/conf/settings.xml
> [DEBUG] Reading user settings from /home/gboccardo/.m2/settings.xml
> [DEBUG] Using local repository at /home/gboccardo/.m2/repository
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
> /home/gboccardo/.m2/repository
> [INFO] Scanning for projects...
> [DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
> (none)
> [DEBUG] Looking up lifecyle mappings for packaging pom from
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
> org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] === REACTOR BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:pom:1
> [DEBUG] Tasks: [release:perform]
> [DEBUG] Style: Aggregating
> [DEBUG]
> ===
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
> org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy]
> [DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> [DEBUG] === PROJECT BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:1
> [DEBUG] Dependencies (collect): []
> [DEBUG] Dependencies (resolve): []
> [DEBUG] Repositories (dependencies): [unimatica-m2-snapshot-repository
> (http://coderepository.unimatica.lan/dev2/maven2-snapshot, releases=true,
> snapshots=true, managed=false), unimatica-m2-coderepository
> (http://coderepository.unimatica.lan/dev2/maven2, releases=true,
> snapshots=true, managed=false), central (http://repo1.maven.org/maven2,
> releases=true, snapshots=false, managed=false)]
> [DEBUG] Repositories (plugins) : [central (http://repo1.maven.org/maven2,
> releases=true, snapshots=false, managed=false)]
> [DEBUG]
> ---
> [DEBUG] Goal:
> org.apache.maven.plugins:maven-release-plugin:2.0:perform (default-cli)
> [DEBUG] Style: Aggregating
> [DEBUG] Configuration:
>
> ${arguments}
> ${basedir}
> ${connectionUrl}
> ${goals}
>
> ${localCheckout}
>
>default-v
[jira] (MNG-4476) [regression] reporting configuration does not apply to plugins invoked from CLI
[
https://jira.codehaus.org/browse/MNG-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298834#comment-298834
]
Roman Arkadijovych Muntyanu commented on MNG-4476:
--
Hello Benjamin,
Just to clarify.
Did you mean that for plug-ins invoked from the CLI or during the build
lifecycle // is not allowed and
/ should be used instead? How should configuration inheritance
be organized in such case?
> [regression] reporting configuration does not apply to plugins invoked from
> CLI
> ---
>
> Key: MNG-4476
> URL: https://jira.codehaus.org/browse/MNG-4476
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0-alpha-4, 3.0-alpha-5
> Environment: Vista
>Reporter: Fred Bricon
>Assignee: Benjamin Bentmann
> Attachments: pom.zip
>
>
> Using Maven 3 alphas (3,4,5), PMD configuration is not herited from the
> parent pom to its modules.
> Here is the parent pom :
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> foo.bar.pmd
> pom
> pom
> Parent project
> 0.0.1-SNAPSHOT
>
>
>
>
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
> true
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.4
>
> ${java.version}
>
>
>
>
>
> 1.5
>
>
> jar
>
> {code}
> the child module
> {code}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
>
> pom
> foo.bar.pmd
> 0.0.1-SNAPSHOT
> ..\pom.xml
>
> foo.bar.pmd
> jar
> 0.0.1-SNAPSHOT
> jar
>
> {code}
> The analyzed source file
> {code}
> package foo.bar.pmd;
> /**
> * Hello world!
> *
> */
> @SuppressWarnings("PMD")
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( "Hello World!" );
> }
> }
> {code}
> This is the outpout of *mvn pmd:pmd*
> {code}
> D:\Projets\pom>mvn pmd:pmd
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Parent project
> [INFO] jar
> [INFO]
> [INFO]
>
> [INFO] Building Parent project 0.0.1-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-pmd-plugin:2.4:pmd (default-cli) @ pom ---
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO]
> [INFO]
>
> [INFO] Building jar 0.0.1-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-pmd-plugin:2.4:pmd (default-cli) @ jar ---
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [WARNING] File encoding has not been set, using platform encoding Cp1252,
> i.e. b
> uild is platform dependent!
> [WARNING] Error while parsing
> D:\Projets\pom\jar\src\main\java\foo\bar\pmd\App.j
> ava: Can't use annotations when running in JDK 1.4 mode!
> [WARNING] Error while parsing
> D:\Projets\pom\jar\src\main\java\foo\bar\pmd\App.j
> ava: Can't use annotations when running in JDK 1.4 mode!
> [WARNING] Error while parsing
> D:\Projets\pom\jar\src\main\java\foo\bar\pmd\App.j
> ava: Can't use annotations when running in JDK 1.4 mode!
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Parent project SUCCESS [0.789s]
> [INFO] jar ... SUCCESS [0.151s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.532s
> [INFO] Finished at: Tue Dec 01 10:28:59 CET 2009
> [INFO] Final Memory: 5M/11M
> [INFO]
> ---
[jira] (MRELEASE-603) Allow configuration of goals to be executed after release creation
[
https://jira.codehaus.org/browse/MRELEASE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298859#comment-298859
]
Marcus Linke commented on MRELEASE-603:
---
OK, so it seems i've totally misunderstood the meaning of that
{{completionGoals}} option. Thanks for being so patient with me! I will close
this issue now.
> Allow configuration of goals to be executed after release creation
> --
>
> Key: MRELEASE-603
> URL: https://jira.codehaus.org/browse/MRELEASE-603
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Marcus Linke
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.2
>
>
> It would be nice if the release plugin allows the configuration of some goals
> to be executed after the release creation. This could be used for example to
> configure the automatic execution of the maven-versions-plugin to update the
> dependencies versions of the newly created snaphot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-603) Allow configuration of goals to be executed after release creation
[ https://jira.codehaus.org/browse/MRELEASE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Linke closed MRELEASE-603. - Resolution: Duplicate Fix Version/s: 2.2 > Allow configuration of goals to be executed after release creation > -- > > Key: MRELEASE-603 > URL: https://jira.codehaus.org/browse/MRELEASE-603 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Marcus Linke >Assignee: Robert Scholte >Priority: Minor > Fix For: 2.2 > > > It would be nice if the release plugin allows the configuration of some goals > to be executed after the release creation. This could be used for example to > configure the automatic execution of the maven-versions-plugin to update the > dependencies versions of the newly created snaphot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
