[jira] Updated: (MDEP-163) Unpacking Artifacts : site usage example does not work.
[
http://jira.codehaus.org/browse/MDEP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MDEP-163:
---
Issue Type: Improvement (was: Bug)
> Unpacking Artifacts : site usage example does not work.
> ---
>
> Key: MDEP-163
> URL: http://jira.codehaus.org/browse/MDEP-163
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack
>Affects Versions: 2.0
> Environment:
> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
>Reporter: Andrew Hughes
>Assignee: Brian Fox
>
> I've taken the dependency:unpack example on
> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
> (below) and it does now work (complete pom for you to test on the bottom if
> you dare).
> {noformat}
>
>[...]
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack
> package
>
>unpack
>
>
>
>
>junit
>junit
>3.8.1
>jar
>false
>
> ${project.build.directory}/alternateLocation
>optional-new-name.jar
>**/*.class,**/*.xml
>**/*test.class
>
>
>**/*.java
>**/*.properties
>
> ${project.build.directory}/wars
>false
>true
>
>
>
>
>
>
>[...]
>
> {noformat}
> The error I get is...
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] One or more required plugin parameters are invalid/missing for
> 'dependency:unpack'
> [0] inside the definition for plugin: 'maven-dependency-plugin'specify the
> following:
>
> ...
> VALUE
> .
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
> org.apache.maven.plugins:maven-dependency-plugin. Reason: Invalid or missing
> parameters: [Mojo parameter [name: 'artifactItems'; alias: 'null']] for mojo:
> org.apache.maven.plugins:maven-dependency-plugin:2.0:unpack
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:568)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> 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:280)
> 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.PluginParameterException: Error
> configuring: org.apache.maven.plugins:maven-dependency-plugin. Reason:
> Invalid or missing parameters: [Mojo parameter [name: 'artifactItems'; alias:
> 'null']] for mojo: org.apache.maven.plugins:maven-dependency-plugin:2.0:unpack
> at
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredParameters(DefaultPluginManager.java:907)
> at
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:612)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421)
> at
[jira] Issue Comment Edited: (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
http://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131215#action_131215
]
svetsch edited comment on MINSTALL-50 at 4/18/08 2:49 AM:
Is there a reason why you do not apply this filtering to artifacts of type
"pom" ?
was (Author: svetsch):
Is there a reason why you do not apply this filtering of artifact of type
"pom" ?
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: http://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> ${myprop}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "filteringEnabled". Since this defaults
> to "false", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in FilteredProjectArtifactMetadata.java, the
> property resolution code has been inspired by ResourcesMojo.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
> is not included in the patch. This file is the same as
> src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
http://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131215#action_131215
]
Samuel Vetsch commented on MINSTALL-50:
---
Is there a reason why you do not apply this filtering of artifact of type "pom"
?
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: http://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> ${myprop}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "filteringEnabled". Since this defaults
> to "false", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in FilteredProjectArtifactMetadata.java, the
> property resolution code has been inspired by ResourcesMojo.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
> is not included in the patch. This file is the same as
> src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-437) Ordering of .classpath entries when using a newer version of JARs already included in the JDK.
Ordering of .classpath entries when using a newer version of JARs already included in the JDK. -- Key: MECLIPSE-437 URL: http://jira.codehaus.org/browse/MECLIPSE-437 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.4 Environment: WinXP, Maven 2.0.7 Reporter: Patrick Zeising While using a newer version of JaxWS (https://jax-ws.dev.java.net/) than the one supplied with JDK6 the generated .classpath file in my project directory contains all relevant entries headed by the entry for the JRE container. ---CODE--- ---/CODE--- As long as the JRE_CONTAINER is mentioned and loaded first my project will not compile in Eclipse since I am using operations unique to the newer version of JaxWS. When I set the order of the classpath entries in Eclipse manually (Properties - Java Build Path - Order and Export, setting the entry for JRE_CONTAINER to the 'bottom') my project will compile of course. Nicolas de Loof suggested the following in my post to the maven users mailing list (http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-p16722527s177.html): ---CITE--- Maybe the eclipse plugin could detect java* and javax* groupIds and force them as toplevel ? This would require : - improve EclipseConfigWriter to have a new getJavaApiDeps(), and remove those deps from getDepsOrdered - improve EclipseClasspathWriter to write getJavaApiDeps prior to the JRE container. ---/CITE--- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-288) Support in component descriptors
[
http://jira.codehaus.org/browse/MASSEMBLY-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131235#action_131235
]
Viktor Nordling commented on MASSEMBLY-288:
---
I would really like to see this fixed. It does not make a lot of sense to allow
everything but moduleSets in the component xml.
Cheers.
> Support in component descriptors
> -
>
> Key: MASSEMBLY-288
> URL: http://jira.codehaus.org/browse/MASSEMBLY-288
> Project: Maven 2.x Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.2-beta-2
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> Would be nice if reusability at the component descriptor level would not stop
> at {{}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131241#action_131241
]
hayo edited comment on MECLIPSE-404 at 4/18/08 5:36 AM:
I have a very similar issue that i already tried to report at the wrong place
[MECLIPSE]. Here is what i wrote:
The local repository was set as follows
{code}${user.home}/.m2/repository{code}
which is documented as the default to do.
When i run "mvn eclipse:eclipse" Maven2 produces entries in .classpath which
all contain a superflouous .m2/repository. E.g.
{code}{code}
Of course, the project will not compile under Eclipse.
In a second project i have additionally set this file as the global
settings.xml in the Sonatype Maven Integration. In that case, when i run the
maven scripts from inside Eclipse, the problem does not appear.
Affects Versions: 0.9.2
Environment: Windows XP, Maven 2.0.7/2.0.8, Eclipse 3.3.2
settings.xml in %USERPROFILE%\.m2 directory
was (Author: hayo):
I have a very similar issue that i already tried to report at the wrong
place [MECLIPSE]. Here is what i wrote:
The local repository was set as follows
[code]${user.home}/.m2/repository[/code]
which is documented as the default to do.
When i run "mvn eclipse:eclipse" Maven2 produces entries in .classpath which
all contain a superflouous .m2/repository. E.g.
[code][/cod]
Of course, the project will not compile under Eclipse.
In a second project i have additionally set this file as the global
settings.xml in the Sonatype Maven Integration. In that case, when i run the
maven scripts from inside Eclipse, the problem does not appear.
Affects Versions: 0.9.2
Environment: Windows XP, Maven 2.0.7/2.0.8, Eclipse 3.3.2
settings.xml in %USERPROFILE%\.m2 directory
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131241#action_131241
]
Hayo commented on MECLIPSE-404:
---
I have a very similar issue that i already tried to report at the wrong place
[MECLIPSE]. Here is what i wrote:
The local repository was set as follows
[code]${user.home}/.m2/repository[/code]
which is documented as the default to do.
When i run "mvn eclipse:eclipse" Maven2 produces entries in .classpath which
all contain a superflouous .m2/repository. E.g.
[code][/cod]
Of course, the project will not compile under Eclipse.
In a second project i have additionally set this file as the global
settings.xml in the Sonatype Maven Integration. In that case, when i run the
maven scripts from inside Eclipse, the problem does not appear.
Affects Versions: 0.9.2
Environment: Windows XP, Maven 2.0.7/2.0.8, Eclipse 3.3.2
settings.xml in %USERPROFILE%\.m2 directory
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-30) Allow to configure file encoding for verifications scripts
[
http://jira.codehaus.org/browse/MINVOKER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-30.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.2
Committed in [r649475|http://svn.apache.org/viewvc?view=rev&revision=649475].
> Allow to configure file encoding for verifications scripts
> --
>
> Key: MINVOKER-30
> URL: http://jira.codehaus.org/browse/MINVOKER-30
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.2
>
> Attachments: file-encoding.patch
>
>
> Right now, the {{verify.bsh}} is read using the platform's default encoding,
> making the tests platform-dependent. We should enrich the plugin
> configuration to allow the user to lock down the encoding and ensure
> reproducible tests.
> The same applies to the {{goals.txt}} and {{profiles.txt}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-374) maven-scm-providers-git is missing some testdata
maven-scm-providers-git is missing some testdata Key: SCM-374 URL: http://jira.codehaus.org/browse/SCM-374 Project: Maven SCM Issue Type: Bug Affects Versions: 1.1 Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 Reporter: mark struberg Attachments: maven-scm-providers-git-testdata.patch It seems that something has gone missing by moving the maven-scm-providers-git plugin from git to SVN. I checked out the SVN version and compared it to my git repo. It seems that the test/resource/git/ ... /*.log files have been ignored. This files contain the testdata for testing the various commandline output consumers for the git executable. The appending patch does contain all missing files plus a small change in the way the base command is constructed. Tests and TCK successfully passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-374) maven-scm-providers-git is missing some testdata
[ http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131266#action_131266 ] Jason van Zyl commented on SCM-374: --- The tests do not all pass: Tests in error: testEmptyLogConsumer(org.apache.maven.scm.provider.git.gitexe.command.remove.GitRemoveConsumerTest) Can you take a look at this? > maven-scm-providers-git is missing some testdata > > > Key: SCM-374 > URL: http://jira.codehaus.org/browse/SCM-374 > Project: Maven SCM > Issue Type: Bug >Affects Versions: 1.1 > Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 >Reporter: mark struberg >Assignee: Jason van Zyl > Attachments: maven-scm-providers-git-testdata.patch > > > It seems that something has gone missing by moving the > maven-scm-providers-git plugin from git to SVN. > I checked out the SVN version and compared it to my git repo. > It seems that the test/resource/git/ ... /*.log files have been ignored. > This files contain the testdata for testing the various commandline output > consumers for the git executable. > The appending patch does contain all missing files plus a small change in the > way the base command is constructed. > Tests and TCK successfully passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-374) maven-scm-providers-git is missing some testdata
[
http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131271#action_131271
]
mark struberg commented on SCM-374:
---
humm, it's actually in the patch, but it is essentially an empty file with the
name
{noformat}
maven-scm-provider-gitexe/src/test/resources/git/remove/gitrm-empty.gitlog
{noformat}
Either 'patch' did not create the file for you if it's empty or your 'svn add'
skipped it silently.
I'll disable this single test if there is any argument against empty files.
> maven-scm-providers-git is missing some testdata
>
>
> Key: SCM-374
> URL: http://jira.codehaus.org/browse/SCM-374
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: linux fedora-8, git-1.5.3.3., git-1.5.4
>Reporter: mark struberg
>Assignee: Jason van Zyl
> Attachments: maven-scm-providers-git-testdata.patch
>
>
> It seems that something has gone missing by moving the
> maven-scm-providers-git plugin from git to SVN.
> I checked out the SVN version and compared it to my git repo.
> It seems that the test/resource/git/ ... /*.log files have been ignored.
> This files contain the testdata for testing the various commandline output
> consumers for the git executable.
> The appending patch does contain all missing files plus a small change in the
> way the base command is constructed.
> Tests and TCK successfully passed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3531) embedder always checks missing release artifacts
embedder always checks missing release artifacts Key: MNG-3531 URL: http://jira.codehaus.org/browse/MNG-3531 Project: Maven 2 Issue Type: Bug Components: Performance Affects Versions: 2.1 Reporter: Igor Fedorenko 2.1 embedder always checks remote repositories for missing release artifacts. This is done multiple times during the same readProjectWithDependencies invocation and results in bad performance problems in embedding application (see MNGECLIPSE-523). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-76) Add option to check for up to date local checkout
Add option to check for up to date local checkout - Key: MDEPLOY-76 URL: http://jira.codehaus.org/browse/MDEPLOY-76 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Reporter: Paul Gier It would be helpful if the deploy plugin had the ability to check the local workspace against the scm (svn, cvs, etc.) to make sure that everything is up to date and there are not local changes before deploying the artifact. This would mainly be useful when deploying snapshots since the release plugin already handles this for release versions. This would be useful to prevent someone (or at least warn them) from deploying a snapshot that cannot be reproduced. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3532) Log download duration and speed
Log download duration and speed --- Key: MNG-3532 URL: http://jira.codehaus.org/browse/MNG-3532 Project: Maven 2 Issue Type: Improvement Components: Logging Affects Versions: 2.1 Reporter: Igor Fedorenko It would be helpful if maven embedder log messages about time each download from remote repository took as well as per-repository totals. This would help users identify problems related to slow remote repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-163) Unpacking Artifacts : site usage example does not work.
[
http://jira.codehaus.org/browse/MDEP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131279#action_131279
]
Brian Fox commented on MDEP-163:
This is a maven core problem as the error you see comes from maven before the
plugin is even started. There is a faq entry and a jira in core for this:
http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#cli
MNG-3401
> Unpacking Artifacts : site usage example does not work.
> ---
>
> Key: MDEP-163
> URL: http://jira.codehaus.org/browse/MDEP-163
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack
>Affects Versions: 2.0
> Environment:
> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
>Reporter: Andrew Hughes
>Assignee: Brian Fox
>
> I've taken the dependency:unpack example on
> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
> (below) and it does now work (complete pom for you to test on the bottom if
> you dare).
> {noformat}
>
>[...]
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack
> package
>
>unpack
>
>
>
>
>junit
>junit
>3.8.1
>jar
>false
>
> ${project.build.directory}/alternateLocation
>optional-new-name.jar
>**/*.class,**/*.xml
>**/*test.class
>
>
>**/*.java
>**/*.properties
>
> ${project.build.directory}/wars
>false
>true
>
>
>
>
>
>
>[...]
>
> {noformat}
> The error I get is...
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] One or more required plugin parameters are invalid/missing for
> 'dependency:unpack'
> [0] inside the definition for plugin: 'maven-dependency-plugin'specify the
> following:
>
> ...
> VALUE
> .
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
> org.apache.maven.plugins:maven-dependency-plugin. Reason: Invalid or missing
> parameters: [Mojo parameter [name: 'artifactItems'; alias: 'null']] for mojo:
> org.apache.maven.plugins:maven-dependency-plugin:2.0:unpack
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:568)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> 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:280)
> 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.PluginParameterException: Error
> configuring: org.apache.maven.plugins:maven-dependency-plugin. Reason:
> Invalid or missing parameters: [Mojo parameter [name: 'artifactItems'; alias:
> 'null']] for mojo: org.apache.maven.plugins:maven-dependency-plugin:2.0:unpack
> at
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredParameters(DefaultPluginManager.java:90
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131285#action_131285
]
Benjamin Bentmann commented on DOXIA-236:
-
A thought with regard to event order/nesting: What about defining a Sink Object
Model in terms of a XSD? This tree structure should not be expressed by a
programmatic API but merely serves as a reference for parser validation. I.e. a
{{CanonicalSink}} would output the XML document
{code:xml}
foo
{code}
for the event sequence {{head()}}, {{title()}}, {{text("foo")}}, {{_title()}},
{{_head()}}. This tree could then be passed through a validating XML parser
(conveniently wrapped in a {{ValidatingSink}}, superceding the
{{WellformednessCheckingSink}}) to check that the parser obeys the
ordering/nesting rules defined by the XSD. Of course, the XSD would also serve
the purpose of documenting the intended usage of the Sink API to implementors.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-162) javadocExecutable unusable
[
http://jira.codehaus.org/browse/MJAVADOC-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MJAVADOC-162.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.5
Fixed in [r649582|http://svn.apache.org/viewvc?view=rev&revision=649582].
> javadocExecutable unusable
> --
>
> Key: MJAVADOC-162
> URL: http://jira.codehaus.org/browse/MJAVADOC-162
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP and non-Windows
>Reporter: Greg Thompson
>Assignee: Benjamin Bentmann
> Fix For: 2.5
>
> Attachments: javadoc-executable.patch
>
>
> AbstractJavadocMojo tries to be smart by seeing if the file indicated by
> javadocExecutable exists, but this is actually quite problematic. If you put
> the following in your config:
> blahblahblah${file.separator}javadoc
> then you'll get an error on Windows since the file is actually javadoc.exe,
> which is a pain since it's perfectly acceptable to omit the .exe when
> executing a command.
> If you put .exe in the config, then it won't work on non-Windows platforms
> since the files doesn't have .exe.
> Forcing users to add hackery to their POMs to add .exe in some cases and
> leave it off in others is onerous.
> Methinks it's much preferable to simply use the path provided by the config.
> If it doesn't exist, let CommandLineUtils.executeCommandLine (or something
> else) throw an exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-61) When running build using "-f /pom.xml" the site is stored in working directory instead of project directory
[ http://jira.codehaus.org/browse/MPMD-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPMD-61. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4 Fixed in [r649586|http://svn.apache.org/viewvc?view=rev&revision=649586]. > When running build using "-f /pom.xml" the site is stored in > working directory instead of project directory > > > Key: MPMD-61 > URL: http://jira.codehaus.org/browse/MPMD-61 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Windows XP, Java 1.5, Maven 2.0.7 >Reporter: Peter Hayes >Assignee: Benjamin Bentmann > Fix For: 2.4 > > Attachments: output-directory.patch, pmd-multi-module.zip > > > I setup a multi-module build and included the pmd check goal to run during > the verify phase. When I execute a build from the top level directory > specifying -f /pom.xml, the plugin creates a target/site/... directory > in the current working directory. This directory should be in the project > directory and now fails to clean. > I have attached a sample project. To reproduce : > cd pmd-multi-module > mvn -f ./root/pom.xml install > Note that after the build there is a target directory in the current working > directory with the pmd.html and other files within it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-74) Clarify usage of outputDirectory parameter
[ http://jira.codehaus.org/browse/MPMD-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPMD-74. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4 Fixed in [r649587|http://svn.apache.org/viewvc?view=rev&revision=649587]. > Clarify usage of outputDirectory parameter > -- > > Key: MPMD-74 > URL: http://jira.codehaus.org/browse/MPMD-74 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 2.4 > > Attachments: output-directory.patch > > > The plugin's documentation should state that the parameter "outputDirectory" > is ONLY evaluated for standalone runs of a mojo and is ignored when run > during a site generation. Otherwise, confusion is likely. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3509) Make "mvn -v" output locale/encoding
[ http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131298#action_131298 ] Paul Benedict commented on MNG-3509: I am concerned about the kind of non-Maven properties outputed with the version. It sounds like it could grow pretty big based on feature requests. Why not just provide an extended debug option that dumps all the JVM properties? > Make "mvn -v" output locale/encoding > > > Key: MNG-3509 > URL: http://jira.codehaus.org/browse/MNG-3509 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.0.10 > > Attachments: locale-output.patch > > > Printing a platform's locale and file encoding might be worth to add when > Maven is requested to show version information since these parameters can > affect text/string handling code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-70) Move hard-coded strings to resource bundle
[ http://jira.codehaus.org/browse/MPMD-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPMD-70. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4 Fixed in [r649601|http://svn.apache.org/viewvc?view=rev&revision=649601]. > Move hard-coded strings to resource bundle > -- > > Key: MPMD-70 > URL: http://jira.codehaus.org/browse/MPMD-70 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: CPD, PMD >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 2.4 > > Attachments: i18n-no-problems.patch > > > Both reports output something like " found no problems in your source > code" in case no violations were found. These strings are hard-coded in the > Java code but should come from the resource bundle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-71) Add german translation
[ http://jira.codehaus.org/browse/MPMD-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPMD-71. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4 Committed in [r649605|http://svn.apache.org/viewvc?view=rev&revision=649605]. > Add german translation > -- > > Key: MPMD-71 > URL: http://jira.codehaus.org/browse/MPMD-71 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 2.4 > > Attachments: i18n-de.patch > > > Well, it's all said, isn't it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MINVOKER-22: -- Attachment: MINVOKER-22-install-artifacts.patch First attempt at a patch for this. This doesn't generate the checksums, are those needed for this? This also does not include any updated site docs. > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier > Fix For: 1.2 > > Attachments: MINVOKER-22-install-artifacts.patch > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3509) Make "mvn -v" output locale/encoding
[ http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131309#action_131309 ] Herve Boutemy commented on MNG-3509: I understand that anything should not be outputted The dump of every properties gives a really huge result, which is already available in Surefiire XML output: ading an option for it isn't useful IMHO Before the change "mvn -v" outputs 3 lines: Maven version, JVM version and OS info. After the line, there is one more line with encoding and locale info: they are strategic properties, like JVM and OS. I think it's worth the extra line, and fits into "carefully chosen properties" category. > Make "mvn -v" output locale/encoding > > > Key: MNG-3509 > URL: http://jira.codehaus.org/browse/MNG-3509 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.0.10 > > Attachments: locale-output.patch > > > Printing a platform's locale and file encoding might be worth to add when > Maven is requested to show version information since these parameters can > affect text/string handling code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-77) excludeRoots doesn't work with basedir-relative paths
[
http://jira.codehaus.org/browse/MPMD-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPMD-77.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4
Applied in [r649616|http://svn.apache.org/viewvc?view=rev&revision=649616],
thanks Justin!
I chose your second patch, i.e. using {{File[]}}, because:
- it's the simplest way to avoid a [common bug with path
resolution|http://www.nabble.com/Common-Bugs-p14783703s177.html] from which
your first patch suffers
- in the plugin documentation, the type {{File[]}} is more descriptive than
{{List}}
One final note: If you supply further patches (please!), avoid absolute paths
in the patch file. Also, patching against the SVN trunk is preferrable.
> excludeRoots doesn't work with basedir-relative paths
> -
>
> Key: MPMD-77
> URL: http://jira.codehaus.org/browse/MPMD-77
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Justin Edelson
>Assignee: Benjamin Bentmann
>Priority: Critical
> Fix For: 2.4
>
> Attachments: pmd-patch.patch, pmd_patch2.patch
>
>
> According to http://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html,
> the excludeRoots property is supposed to suppress PMD report generation for
> certain source roots. However, in practice this does not work with this type
> of configuration:
>
>
>
> target/generated-sources/axis
>
>
> On line 265 of AbstractPmdReport, a new File object is created for each
> excludeRoot element. Then, on line 346, each compileSourceRoot is checked to
> see if the List of excludeRoot File objects contains it. This test will never
> return true as the compileSourceRoot File objects are absolute and the
> excludeRoot File objects are relative.
> The simplest solution (seen in the attached patch) is to create absolute File
> objects for each excludeRoot.
> I tried created a unit test to demonstrate this problem, but couldn't quite
> nail it down. I'll keep trying
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-326) m2eclipse goal does not respect additionalBuildcommands and additionalProjectnatures defined in pom
[ http://jira.codehaus.org/browse/MECLIPSE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Holger Joest updated MECLIPSE-326: -- Attachment: m2eclipseMojoPatchWithUnitTest.patch Attached an additional unit test covering this issue. > m2eclipse goal does not respect additionalBuildcommands and > additionalProjectnatures defined in pom > --- > > Key: MECLIPSE-326 > URL: http://jira.codehaus.org/browse/MECLIPSE-326 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: M2Eclipse support >Affects Versions: 2.4 > Environment: win xp, jre/jdk 1.6, maven 2.0.7, maven-eclipse-plugin > 2.4 >Reporter: Tom Pasierb > Attachments: m2eclipseMojoPatch.patch, > m2eclipseMojoPatchWithUnitTest.patch > > > I have defined additional buildCommand and projectNature in my pom.xml > After running eclipse:m2eclipse on my project, the produced eclipse project > descriptors contain neither of the above. > From what I saw in the source code the m2eclipseMojo uses the > setAdditionalBuildcommands and setAdditionalProjectnatures methods not > considering that the collections may already contain some entries. > I'm attaching a patch that solves this issue, however I have no experience in > developing mojos so I'm not sure if I'm doing it the right way. Should it be > acceptable please apply the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-78) Update to PMD 4.2.1
Update to PMD 4.2.1 --- Key: MPMD-78 URL: http://jira.codehaus.org/browse/MPMD-78 Project: Maven 2.x PMD Plugin Issue Type: Task Components: CPD, PMD Affects Versions: 2.3 Reporter: Benjamin Bentmann Priority: Minor The usual version roundabout... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRESOURCES-57) Provide specific default value for "encoding" parameter
[ http://jira.codehaus.org/browse/MRESOURCES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MRESOURCES-57. --- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.3 done in r649654 > Provide specific default value for "encoding" parameter > --- > > Key: MRESOURCES-57 > URL: http://jira.codehaus.org/browse/MRESOURCES-57 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.3 > > Attachments: resource-encoding.patch > > > The platform's default encoding may easily differ among machines/developers > so relying on it breaks with the aim of reproducible builds. The encoding > used should always be fixed for a particular plugin run, either explicitly by > the user or implicitly by a known default value. > See also MCOMPILER-63. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-78) Update to PMD 4.2.1
[ http://jira.codehaus.org/browse/MPMD-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPMD-78. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4 Done in [r649655|http://svn.apache.org/viewvc?view=rev&revision=649655]. > Update to PMD 4.2.1 > --- > > Key: MPMD-78 > URL: http://jira.codehaus.org/browse/MPMD-78 > Project: Maven 2.x PMD Plugin > Issue Type: Task > Components: CPD, PMD >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 2.4 > > > The usual version roundabout... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-314) use ${project.build.sourceEncoding} as default value for "inputEncoding" parameter
[
http://jira.codehaus.org/browse/MSITE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-314.
---
Assignee: Herve Boutemy
Resolution: Fixed
Fix Version/s: 2.0-beta-7
done in r649656
> use ${project.build.sourceEncoding} as default value for "inputEncoding"
> parameter
> --
>
> Key: MSITE-314
> URL: http://jira.codehaus.org/browse/MSITE-314
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
> Components: encoding
>Affects Versions: 2.0-beta-6
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.0-beta-7
>
>
> see
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-14) Use specific encoding for checksum files
Use specific encoding for checksum files Key: MARTIFACT-14 URL: http://jira.codehaus.org/browse/MARTIFACT-14 Project: Maven Artifact Issue Type: Bug Affects Versions: 3.0-alpha-1 Reporter: Benjamin Bentmann Priority: Minor Attachments: checksum-file-encoding.patch The checksum files are currently written/read using the JVM's default encoding. Even though the ASCII characters constituting the checksums are quite safe from being messed up, the principal possibility for such a problem exists. Just assume somebody running with EBCDIC (like in MANTTASKS-14). See also [Common Bugs|http://www.nabble.com/Re%3A-Common-Bugs-p15919795s177.html]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-317) User proper encoding when interpolating site descriptor
User proper encoding when interpolating site descriptor
---
Key: MSITE-317
URL: http://jira.codehaus.org/browse/MSITE-317
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: encoding, site descriptor
Affects Versions: 2.0-beta-6
Reporter: Benjamin Bentmann
The {{attach-descriptor}} goal is currently using the JVM's default encoding
when reading the site descriptor for interpolation. However, the encoding from
the XML prolog must be used. See also [Common
Bugs|http://www.nabble.com/Re%3A-Common-Bugs-p15919795s177.html].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-317) User proper encoding when interpolating site descriptor
[
http://jira.codehaus.org/browse/MSITE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSITE-317.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.0-beta-7
Fixed in [r649687|http://svn.apache.org/viewvc?view=rev&revision=649687].
> User proper encoding when interpolating site descriptor
> ---
>
> Key: MSITE-317
> URL: http://jira.codehaus.org/browse/MSITE-317
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: encoding, site descriptor
>Affects Versions: 2.0-beta-6
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 2.0-beta-7
>
>
> The {{attach-descriptor}} goal is currently using the JVM's default encoding
> when reading the site descriptor for interpolation. However, the encoding
> from the XML prolog must be used. See also [Common
> Bugs|http://www.nabble.com/Re%3A-Common-Bugs-p15919795s177.html].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-22. Assignee: Olivier Lamy Resolution: Fixed fixed in rev 649690. Thanks! > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier >Assignee: Olivier Lamy > Fix For: 1.2 > > Attachments: MINVOKER-22-install-artifacts.patch > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-75) PMD plugin unable to exclude groovy-stub files.
[
http://jira.codehaus.org/browse/MPMD-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPMD-75.
-
Assignee: Benjamin Bentmann
Resolution: Won't Fix
Fix Version/s: 2.4
bq. the patterns are all relative to the source roots.
Exclusions are controlled by two distinct parameters in the plugin:
{{excludes}} for package/class names and {{excludeRoots}} for entire source
roots. The later one should be the solution for your problems:
{code:xml}
target/generated/groovy-stubs
{code}
I added some more doc about this in
[r649704|http://svn.apache.org/viewvc?view=rev&revision=649704], hopefully
clarifying this two-way exclusion handling.
> PMD plugin unable to exclude groovy-stub files.
> ---
>
> Key: MPMD-75
> URL: http://jira.codehaus.org/browse/MPMD-75
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.3
> Environment: windows xp, java 1.6.0_04, maven 2.0.8, groovy 1.5.1,
> groovy-maven-plugin 1.0-beta3
>Reporter: Jonathan Baker
>Assignee: Benjamin Bentmann
> Fix For: 2.4
>
>
> When trying to run the pmd plugin to fail our build on a mixed java and
> groovy project, I am unable to exclude groovy-generated java stubs. It seems
> as though all of the exclude patterns are package and filename filters only.
> If this is true, then the only way to exclude groovy-generated java sources
> would be to move all of our groovy files into a package that contains the
> word groovy, or to name all of our groovy classes ClassNameGroovy.groovy.
> This seems unacceptible. The example on the webage for usage shows something
> like this:
>
> **/generated/*.java
>
> This implies that we could do something similar like this:
>
> **/groovy-stubs/*.java
>
> But that doesn't seem to work because it ends up looking for
> target/groovy-stubs/main/groovy-stubs/*.java because the patterns are all
> relative to the source roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-76) use ${project.build.sourceEncoding} as default value for "sourceEncoding" parameter
[
http://jira.codehaus.org/browse/MPMD-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPMD-76.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4
Done in [r649719|http://svn.apache.org/viewvc?view=rev&revision=649719].
> use ${project.build.sourceEncoding} as default value for "sourceEncoding"
> parameter
> ---
>
> Key: MPMD-76
> URL: http://jira.codehaus.org/browse/MPMD-76
> Project: Maven 2.x PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
>Affects Versions: 2.3
>Reporter: Herve Boutemy
>Assignee: Benjamin Bentmann
> Fix For: 2.4
>
>
> see
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-64) verbose output not useful for inner classes
[ http://jira.codehaus.org/browse/MPMD-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131349#action_131349 ] Benjamin Bentmann commented on MPMD-64: --- I've updated the plugin's dependency on PMD to 4.2.1 (MPMD-78), so this should be fixed. Unfortunately, I can't deploy a new snapshot for users to test right now due to permission problems. > verbose output not useful for inner classes > --- > > Key: MPMD-64 > URL: http://jira.codehaus.org/browse/MPMD-64 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 2.2 >Reporter: Sean Bridges >Priority: Minor > Attachments: version_update.txt > > > With verbose output on, a pmd error in an inner class will produce output > like, > [INFO] PMD Failure: foo.bar.Anonymous$1:182 > Rule:SignatureDeclareThrowsException Priority:3 A method/constructor > shouldn't explicitly throw java.lang.Exception. > Rather than printing the class name, it would be more useful to print out the > file name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3533) Unreachable mirror should cause Maven to fall back to the original repository
Unreachable mirror should cause Maven to fall back to the original repository - Key: MNG-3533 URL: http://jira.codehaus.org/browse/MNG-3533 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.9 Reporter: Kohsuke Kawaguchi If I have a mirror configured in ~/.m2/settings.xml and for some reason Maven couldn't reach it (perhaps mirror is down), then Maven should attempt to talk to the original repository. OTOH, if the mirror was reachable and returned 404, then Maven shouldn't attempt to connect to the original repository. Today, regardless of how a failure happened, Maven treats them both as if it were a simple 404. Mirrors are often set up inside a corporate firewall, and for an employee who often takes his computer outside firewall, this is a real problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
