[jira] (MASSEMBLY-594) Add ability to suppress "already added, skipping" messages
Andrew Logvinov created MASSEMBLY-594:
-
Summary: Add ability to suppress "already added, skipping" messages
Key: MASSEMBLY-594
URL: https://jira.codehaus.org/browse/MASSEMBLY-594
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Reporter: Andrew Logvinov
A common multi-module project structure would define most of the project
dependencies in the parent POM thus allowing all the child modules to inherit
them. When packaging all the project dependencies using , you'd see
a lot of messages like this (and in case of big project the number is huge):
{noformat}
[INFO] lib/log4j-1.2.15.jar already added, skipping
[INFO] lib/mail-1.4.jar already added, skipping
[INFO] lib/jms-1.1.jar already added, skipping
{noformat}
It would be great to either have an option to suppress such info messages, or
to have them moved to DEBUG log level.
See example of configuration here:
http://stackoverflow.com/questions/4912738/maven-assembly-include-all-sub-module-dependencies-without-already-added-skipp
--
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] (MSKINS-22) Add GitHub ribbons support
[
https://jira.codehaus.org/browse/MSKINS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi closed MSKINS-22.
Resolution: Fixed
Fix Version/s: fluido-1.1
Assignee: Simone Tripodi
fixed on /trunk, see
[r1224835|https://svn.apache.org/viewvc?view=revision&revision=1224835]
> Add GitHub ribbons support
> ---
>
> Key: MSKINS-22
> URL: https://jira.codehaus.org/browse/MSKINS-22
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.1
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: fluido-1.1
>
>
> With a trivial configuration in {{site.xml}}, it is possible to add a
> simplified support for GitHub
> [ribbons|https://github.com/blog/273-github-ribbons] (you can see a live
> sample on the [Oozie page|http://yahoo.github.com/oozie/]):
> {code}
>
>
>
>
> 99soft/backport-spi
>
> right
>
> black
>
>
>
> {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] (MSKINS-22) Add GitHub ribbons support
Simone Tripodi created MSKINS-22:
Summary: Add GitHub ribbons support
Key: MSKINS-22
URL: https://jira.codehaus.org/browse/MSKINS-22
Project: Maven Skins
Issue Type: New Feature
Components: Fluido Skin
Affects Versions: fluido-1.1
Reporter: Simone Tripodi
With a trivial configuration in {{site.xml}}, it is possible to add a
simplified support for GitHub
[ribbons|https://github.com/blog/273-github-ribbons] (you can see a live sample
on the [Oozie page|http://yahoo.github.com/oozie/]):
{code}
99soft/backport-spi
right
black
{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] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.
[ https://jira.codehaus.org/browse/MJAVADOC-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MJAVADOC-336: --- Attachment: MJAVADOC-336.patch Patch replacing 'File.deleteOnExit' with 'File.delete'. Applying this patch, 'mvn clean install -Prun-its' still succeeds for me. > Reports contain temporary files due to usage of 'File.deleteOnExit'. > > > Key: MJAVADOC-336 > URL: https://jira.codehaus.org/browse/MJAVADOC-336 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Christian Schulte >Priority: Minor > Attachments: MJAVADOC-336.patch > > > The plugin creates temporary command line argument files (@file) in the > output directory without removing them prior to e.g. site deployment. Please > replace 'File.deleteOnExit' with 'File.delete'. -- 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] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.
Christian Schulte created MJAVADOC-336: -- Summary: Reports contain temporary files due to usage of 'File.deleteOnExit'. Key: MJAVADOC-336 URL: https://jira.codehaus.org/browse/MJAVADOC-336 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Christian Schulte Priority: Minor The plugin creates temporary command line argument files (@file) in the output directory without removing them prior to e.g. site deployment. Please replace 'File.deleteOnExit' with 'File.delete'. -- 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-593) jarsigner plugin failes after assembly plugin
Adrian Stabiszewski created MASSEMBLY-593: - Summary: jarsigner plugin failes after assembly plugin Key: MASSEMBLY-593 URL: https://jira.codehaus.org/browse/MASSEMBLY-593 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.2, 2.2.1, 2.2 Reporter: Adrian Stabiszewski Attachments: maven-assembly.zip This is a regression since version 2.2-beta-5 where this config is working. Workaround for 2.2.2: It works if the "appendAssemblyId" is set to false. For me it looks like the jar file is still open by the assembly plugin when the jarsigner plugin tries to sign it. This becomes visible when you set the option "true" on the jarsigner plugin: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (sign) on project demo: Failed to unsign archive \bugreports\maven-assembly\target\demo-1.0-SNAPSHOT.jar: Failed to delete \bugreports\maven-assembly\target\demo-1.0-SNAPSHOT.jar while trying to rename \bugreports\maven-assembly\target\demo-1.0-SNAPSHOT.jar.unsigned -> [Help 1] -- 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] (MINVOKER-127) showVersion true for Maven 2.0.11 does not work
[
https://jira.codehaus.org/browse/MINVOKER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286853#comment-286853
]
Karl Heinz Marbaise commented on MINVOKER-127:
--
I realized that the problem is Maven 2.0.11 and not the kind of calling Maven.
> showVersion true for Maven 2.0.11 does not work
> ---
>
> Key: MINVOKER-127
> URL: https://jira.codehaus.org/browse/MINVOKER-127
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> In MVN 2.0.11 the version output can be done via
> {code}
> mvn --version
> {code}
> but not via:
> {code}
> mvn -V
> {code}
> I assume that currently -V option is used to get the version.
--
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] (MINVOKER-127) showVersion true for Maven 2.0.11 does not work
[
https://jira.codehaus.org/browse/MINVOKER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MINVOKER-127.
Resolution: Not A Bug
> showVersion true for Maven 2.0.11 does not work
> ---
>
> Key: MINVOKER-127
> URL: https://jira.codehaus.org/browse/MINVOKER-127
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> In MVN 2.0.11 the version output can be done via
> {code}
> mvn --version
> {code}
> but not via:
> {code}
> mvn -V
> {code}
> I assume that currently -V option is used to get the version.
--
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] (MINVOKER-127) showVersion true for Maven 2.0.11 does not work
Karl Heinz Marbaise created MINVOKER-127:
Summary: showVersion true for Maven 2.0.11 does not work
Key: MINVOKER-127
URL: https://jira.codehaus.org/browse/MINVOKER-127
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Karl Heinz Marbaise
Priority: Minor
In MVN 2.0.11 the version output can be done via
{code}
mvn --version
{code}
but not via:
{code}
mvn -V
{code}
I assume that currently -V option is used to get the version.
--
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] (MINVOKER-126) mavenHome in relationship with invoker.maven.version rule
Karl Heinz Marbaise created MINVOKER-126: Summary: mavenHome in relationship with invoker.maven.version rule Key: MINVOKER-126 URL: https://jira.codehaus.org/browse/MINVOKER-126 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.5 Reporter: Karl Heinz Marbaise I've set up mavenHome in my POM to use Maven 2.2.1 but i have set a rule (invoker.maven.version = 2.2.0+, !3.0.0+) but the integration test is skipped anyway. An assumtion of Rober Scholte was that invoker.maven.version works only for the executing Maven version which looks like. This results in two choices: either this is a bug or it should be clearly documented for the invoker.maven.version -- 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] (MINVOKER-123) Use different Maven versions for running the current build and the integration tests
[ https://jira.codehaus.org/browse/MINVOKER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286838#comment-286838 ] Karl Heinz Marbaise commented on MINVOKER-123: -- I oversight that the http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#mavenHome already exists. (Thanks Robert Scholte for the hint). Closing the issue. > Use different Maven versions for running the current build and the > integration tests > > > Key: MINVOKER-123 > URL: https://jira.codehaus.org/browse/MINVOKER-123 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.5 > Environment: all >Reporter: Karl Heinz Marbaise > > I'm currently faced with the problem that my build (appassembler-plugin) can > be done via Maven 3.0.X and Maven 2.2.1 but not with Maven 2.0.11. But on the > other hand the appassembler-plugin itself can be used in Maven 2.0.11 or be > more accurate that i would like to test this via the integration tests. > So currently i don't see a possibility to run my build of the plugin via > Maven 3.0.3 and let the integration-tests run with a different Maven version > (or may be oversight something?)...for example with Maven 2.2.1 or Maven > 2.0.11. > So it would be very handy to have the possibility to use a different Maven > version for running inside the integration tests than for the build itself. -- 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] (MINVOKER-123) Use different Maven versions for running the current build and the integration tests
[ https://jira.codehaus.org/browse/MINVOKER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINVOKER-123. Resolution: Won't Fix > Use different Maven versions for running the current build and the > integration tests > > > Key: MINVOKER-123 > URL: https://jira.codehaus.org/browse/MINVOKER-123 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.5 > Environment: all >Reporter: Karl Heinz Marbaise > > I'm currently faced with the problem that my build (appassembler-plugin) can > be done via Maven 3.0.X and Maven 2.2.1 but not with Maven 2.0.11. But on the > other hand the appassembler-plugin itself can be used in Maven 2.0.11 or be > more accurate that i would like to test this via the integration tests. > So currently i don't see a possibility to run my build of the plugin via > Maven 3.0.3 and let the integration-tests run with a different Maven version > (or may be oversight something?)...for example with Maven 2.2.1 or Maven > 2.0.11. > So it would be very handy to have the possibility to use a different Maven > version for running inside the integration tests than for the build itself. -- 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] (MINVOKER-125) Global variable about the target folder into the groovy scripts.
Karl Heinz Marbaise created MINVOKER-125:
Summary: Global variable about the target folder into the groovy
scripts.
Key: MINVOKER-125
URL: https://jira.codehaus.org/browse/MINVOKER-125
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.5
Reporter: Karl Heinz Marbaise
Priority: Minor
Often (may be everytime) groovy scripts (post-build) which are doing work in
relationship with integration-tests must access the *target* folder to check
results etc. But currently i have to hard code the folder "target" by contrast
in the pom.xml there already exists a good replacement for that
${project.build.directory} so it would be very helpful to have an context
information like "target" which represents the target folder.
--
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] (MINVOKER-124) Reporting the reason for skipping an integration tests
Karl Heinz Marbaise created MINVOKER-124: Summary: Reporting the reason for skipping an integration tests Key: MINVOKER-124 URL: https://jira.codehaus.org/browse/MINVOKER-124 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Affects Versions: 1.5 Reporter: Karl Heinz Marbaise Priority: Minor If i have a selector-condition which defines to run a particular integration test only for a particular Maven version it would be nice that in the report which can be generated (report goal) a message will appear which says "ignored, based on selector condition". This will also be true for the summary output during run in command line. -- 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] (MINVOKER-122) Import information into groovy scripts of the running Maven environment
[ https://jira.codehaus.org/browse/MINVOKER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286833#comment-286833 ] Karl Heinz Marbaise commented on MINVOKER-122: -- The selector-conditions allow me to run an integration test or not. This will result in running the integration tests for different Maven versions with different Maven versions multiple times. If i have the information inside the groovy script i can make the differences in the groovy script. > Import information into groovy scripts of the running Maven environment > > > Key: MINVOKER-122 > URL: https://jira.codehaus.org/browse/MINVOKER-122 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.5 >Reporter: Karl Heinz Marbaise >Priority: Minor > > During the execution of a postbuild.groovy script i'm checking the contents > of the build.log output (output of plugins etc.). The problem is that based > on the differences between MVN 2.2.1 and MVN 3.0.? the output looks > different. But inside a verify.groovy i don't know under which version of > Maven the integration-tests has been run...so it's not simple to make a > difference here...It might be a good idea to get this information inside the > groovy script. -- 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] (MINVOKER-123) Use different Maven versions for running the current build and the integration tests
Karl Heinz Marbaise created MINVOKER-123: Summary: Use different Maven versions for running the current build and the integration tests Key: MINVOKER-123 URL: https://jira.codehaus.org/browse/MINVOKER-123 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.5 Environment: all Reporter: Karl Heinz Marbaise I'm currently faced with the problem that my build (appassembler-plugin) can be done via Maven 3.0.X and Maven 2.2.1 but not with Maven 2.0.11. But on the other hand the appassembler-plugin itself can be used in Maven 2.0.11 or be more accurate that i would like to test this via the integration tests. So currently i don't see a possibility to run my build of the plugin via Maven 3.0.3 and let the integration-tests run with a different Maven version (or may be oversight something?)...for example with Maven 2.2.1 or Maven 2.0.11. So it would be very handy to have the possibility to use a different Maven version for running inside the integration tests than for the build itself. -- 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
