[jira] Created: (MASSEMBLY-486) ComponentDescriptors to support absolute paths

2010-04-18 Thread Michael Lawler (JIRA)
ComponentDescriptors to support absolute paths
--

 Key: MASSEMBLY-486
 URL: http://jira.codehaus.org/browse/MASSEMBLY-486
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Reporter: Michael Lawler


I would really like for component descriptors to support absolute paths rather 
than just paths relative to the current module.

-- 
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-471) ${project.distributionManagement.site.url} can't use ${property} values in multi module projects

2010-04-18 Thread Andrew Hughes (JIRA)
${project.distributionManagement.site.url} can't use ${property} values in 
multi module projects


 Key: MSITE-471
 URL: http://jira.codehaus.org/browse/MSITE-471
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: inheritance, site:deploy
Affects Versions: 2.1
Reporter: Andrew Hughes


I wanted to use the site:stage-deploy goal. In order to use this I needed to 
provide a ${project.distributionManagement.site.url}. Which, first I think it 
wrong, since I provide my own 'stagingSiteURL' the 
${project.distributionManagement.site.*} will not be used.

Because we don't actually have a scp, ftp, svn... location to deploy to I tried 
to substitute a ${project.distributionManagement.site.url} that I knew every 
maven user would have. Since they have ~/.m2/repository I tried using...
file://${settings.localRepository}/../sites/${project.groupId}

But when this is used with a multi module project, and with a 'stagingSiteURL' 
some very strange url's are built when trying to stage-deploy. This means the 
modules never deploy.

There's a few things going on here. My workaround means I just have to have 
${project.distributionManagement.site.url}=='not-used'.



-- 
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-547) Release on Windows, of a multi-module project, using msysgit, throws a StringIndexOutOfBoundsException

2010-04-18 Thread Ricky Clarkson (JIRA)
Release on Windows, of a multi-module project, using msysgit, throws a 
StringIndexOutOfBoundsException
--

 Key: SCM-547
 URL: http://jira.codehaus.org/browse/SCM-547
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-git
Affects Versions: 1.3
 Environment: Windows XP 32-bit, msysgit 1.6.5.1-preview20091022, maven 
2.2.1
Reporter: Ricky Clarkson


Install msysgit with the default settings.  Launch Git Bash.

git clone http://github.com/rickyclarkson/maven-git-testcase.git

cd maven-git-testcase

mvn release:prepare

The following is the output:

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Unnamed - org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT
[INFO]   Unnamed - org.test:maven-git-testcase-child:jar:1.0-SNAPSHOT
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO] 
[INFO] Building Unnamed - org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO] 
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: c:\Documents and Settings\Craig\maven-git-testcase
[INFO] nothing added to commit but untracked files present (use "git add" to 
track)
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "Unnamed - 
org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT"? 
(org.test:maven-git-testcase-parent) 1.0: :
What is the release version for "Unnamed - 
org.test:maven-git-testcase-child:jar:1.0-SNAPSHOT"? 
(org.test:maven-git-testcase-child) 1.0: :
What is SCM release tag or label for "Unnamed - 
org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT"? 
(org.test:maven-git-testcase-parent) maven-git-t
estcase-parent-1.0: :
What is the new development version for "Unnamed - 
org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT"? 
(org.test:maven-git-testcase-parent) 1.1-SNAP
SHOT: :
What is the new development version for "Unnamed - 
org.test:maven-git-testcase-child:jar:1.0-SNAPSHOT"? 
(org.test:maven-git-testcase-child) 1.1-SNAPSH
OT: :
[INFO] Transforming 'Unnamed - 
org.test:maven-git-testcase-parent:pom:1.0-SNAPSHOT'...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] String index out of range: -1
[INFO] 
[INFO] Trace
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at 
org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:206)
at 
org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:177)
at 
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:303)
at 
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208)
at 
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114)
at 
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:97)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleE

[jira] Commented: (MPMD-106) Externalize messages for i18n

2010-04-18 Thread Herve Boutemy (JIRA)

[ 
http://jira.codehaus.org/browse/MPMD-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218159#action_218159
 ] 

Herve Boutemy commented on MPMD-106:


yes, messages are externalized
but pt_BR is not supported yet
Can you provide new properties files with escaped unicode content, please?

> Externalize messages for i18n
> -
>
> Key: MPMD-106
> URL: http://jira.codehaus.org/browse/MPMD-106
> Project: Maven 2.x PMD Plugin
>  Issue Type: Improvement
>  Components: CPD, PMD
>Reporter: Taciano Tres
> Attachments: cpd-report_pt_BR.properties, pmd-report_pt_BR.properties
>
>
> I think it would be great if the messages were externalized so it could be 
> translated for other languages than English. I can help in the pt_BR 
> translation.

-- 
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-83) Use proper file encoding for Non-HTML reports

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MPMD-83.
-

   Resolution: Fixed
Fix Version/s: 2.5
 Assignee: Herve Boutemy

done in r935423.

> Use proper file encoding for Non-HTML reports
> -
>
> Key: MPMD-83
> URL: http://jira.codehaus.org/browse/MPMD-83
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD, PMD
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.5
>
>
> The plugin currently uses {{FileWriter}} to output Non-HTML reports. This 
> includes in particular the XML report where the employed encoding must match 
> the XML declaration.
> It appears Non-HTML reports should be classified by the plugin (somehow) into 
> two groups: XML-based and plain text. For the first group, use the XML writer 
> from plexus-utils. For the later, use the configured output encoding for 
> reports (see also [Reporting Encoding 
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]).

-- 
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-106) Externalize messages for i18n

2010-04-18 Thread Taciano Tres (JIRA)

[ 
http://jira.codehaus.org/browse/MPMD-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218141#action_218141
 ] 

Taciano Tres commented on MPMD-106:
---

I don't know what happened, but the translated code is already on HEAD, so you 
can mark this issue as solved. Thanks for the effort.

> Externalize messages for i18n
> -
>
> Key: MPMD-106
> URL: http://jira.codehaus.org/browse/MPMD-106
> Project: Maven 2.x PMD Plugin
>  Issue Type: Improvement
>  Components: CPD, PMD
>Reporter: Taciano Tres
> Attachments: cpd-report_pt_BR.properties, pmd-report_pt_BR.properties
>
>
> I think it would be great if the messages were externalized so it could be 
> translated for other languages than English. I can help in the pt_BR 
> translation.

-- 
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-120) Ruleset XML files containing non-ascii characters are corrupted when copied into target directory

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MPMD-120.
--

   Resolution: Fixed
Fix Version/s: 2.5
 Assignee: Herve Boutemy

plexus-resources upgraded to 1.0-alpha-7 in r935363

> Ruleset XML files containing non-ascii characters are corrupted when copied 
> into target directory
> -
>
> Key: MPMD-120
> URL: http://jira.codehaus.org/browse/MPMD-120
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: PMD
>Affects Versions: 2.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.5
>
>
> plexus-resources 1.0-alpha-4 uses platform encoding when writing
> using plexus-resources 1.0-alpha-5 or more will fix the issue, since it uses 
> streams only

-- 
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-120) Ruleset XML files containing non-ascii characters are corrupted when copied into target directory

2010-04-18 Thread Herve Boutemy (JIRA)
Ruleset XML files containing non-ascii characters are corrupted when copied 
into target directory
-

 Key: MPMD-120
 URL: http://jira.codehaus.org/browse/MPMD-120
 Project: Maven 2.x PMD Plugin
  Issue Type: Bug
  Components: PMD
Affects Versions: 2.4
Reporter: Herve Boutemy


plexus-resources 1.0-alpha-4 uses platform encoding when writing

using plexus-resources 1.0-alpha-5 or more will fix the issue, since it uses 
streams only

-- 
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: (SCM-542) Add blame command to Perforce provider

2010-04-18 Thread Olivier Lamy (JIRA)

 [ 
http://jira.codehaus.org/browse/SCM-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed SCM-542.


Resolution: Fixed

fixed [rev 935354|http://svn.apache.org/viewvc?rev=935354&view=rev]
Thanks

> Add blame command to Perforce provider
> --
>
> Key: SCM-542
> URL: http://jira.codehaus.org/browse/SCM-542
> Project: Maven SCM
>  Issue Type: New Feature
>  Components: maven-scm-provider-perforce
>Reporter: Evgeny Mandrikov
>Assignee: Olivier Lamy
> Fix For: 1.4
>
> Attachments: SCM-542.diff
>
>
> Patch was tested - see SONARPLUGINS-457

-- 
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: (SCM-543) Add blame command to ClearCase provider

2010-04-18 Thread Olivier Lamy (JIRA)

 [ 
http://jira.codehaus.org/browse/SCM-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed SCM-543.


Resolution: Fixed

fix [rev 935351|http://svn.apache.org/viewvc?rev=935351&view=rev]
Thanks !

> Add blame command to ClearCase provider
> ---
>
> Key: SCM-543
> URL: http://jira.codehaus.org/browse/SCM-543
> Project: Maven SCM
>  Issue Type: New Feature
>  Components: maven-scm-provider-clearcase
>Reporter: Evgeny Mandrikov
>Assignee: Olivier Lamy
> Fix For: 1.4
>
> Attachments: SCM-543.diff
>
>
> Patch was tested - see SONARPLUGINS-454

-- 
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-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"

2010-04-18 Thread Andreas Veithen (JIRA)

[ 
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218113#action_218113
 ] 

Andreas Veithen commented on MDEP-259:
--

There is a similar issue in maven-war-plugin: MWAR-192. One of the proposed 
fixes for that issue is to build the artifact on-the-fly from the files in the 
target/classes folder of the dependency project (see the patch attached to 
MWAR-192). Something similar could also be implemented for the issue described 
here, but this would only work for JAR artifacts, not for other packagings (I 
originally encountered the issue in Axis2 with dependencies on MAR files and in 
another project with OSGi bundles produced by maven-bundle-plugin from Apache 
Felix).

> copy-dependencies fails with "Error copying artifact from .../target/classes 
> to .../classes"
> 
>
> Key: MDEP-259
> URL: http://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 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: (MWAR-192) Conflict with workspace resoutlion in m2eclipse

2010-04-18 Thread Andreas Veithen (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218111#action_218111
 ] 

Andreas Veithen commented on MWAR-192:
--

I think this should be considered a bug in maven-war-plugin and 
maven-dependency-plugin. MDEP-259 gives a clear explanation of the problem in 
the context of the maven-dependency-plugin and also shows how to trigger the 
error from the command line.

> Conflict with workspace resoutlion in m2eclipse
> ---
>
> Key: MWAR-192
> URL: http://jira.codehaus.org/browse/MWAR-192
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: windows vista
>Reporter: Max Powers
> Attachments: maven-war-plugin.patch
>
>
> While building my webapp in eclipse using a launch configuration (goals clean 
> install) and having 'Resolve Workspace Artifacts' checked, the war plugin 
> cant assemble the war file properly.  Note that disabled 'Resolve Workspace 
> Artifacts' and the war is assembled fine
> [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to copy file for 
> artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]
>  
> Embedded error: 
> C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes
>  (Access is denied)
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file 
> for 
> artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy 
> file for 
> artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]
>   at 
> org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125)
>   at 
> org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183)
>   at 
> org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103)
>   at 
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439)
>   at 
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375)
>   at 
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181)
>   at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>   ... 16 more
> Caused by: java.io.FileNotFoundException: 
> C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes
>  (Access is denied)
>   at java.io.FileInputStream.open(Native Method)
>   at java.io.FileInputStream.(FileInputStream.java:106)
>   at 
> org.codehaus.plexus.util.io.FileInputStreamFacade.getInputSt

[jira] Created: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"

2010-04-18 Thread Andreas Veithen (JIRA)
copy-dependencies fails with "Error copying artifact from .../target/classes to 
.../classes"


 Key: MDEP-259
 URL: http://jira.codehaus.org/browse/MDEP-259
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 2.1, 2.0
 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 contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MASSEMBLY-485) DependencySet unpack doesn't allows expression

2010-04-18 Thread Mark Berner (JIRA)
DependencySet unpack doesn't allows expression
--

 Key: MASSEMBLY-485
 URL: http://jira.codehaus.org/browse/MASSEMBLY-485
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Mark Berner


DependencySet unpack doesn't allows expression such ${exploded.ear} when 
exploded.ear is property. unpack allows just constants true/false and in case 
of expression behaves as for "false"

In the maven-ear-plugin module unpack option allows expressions.

-- 
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: (MECLIPSE-561) Provide a way to choose .classpath ordering test-first vs. test-last

2010-04-18 Thread fabrizio giustina (JIRA)

 [ 
http://jira.codehaus.org/browse/MECLIPSE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

fabrizio giustina closed MECLIPSE-561.
--

   Resolution: Fixed
Fix Version/s: 2.9

I was a little bit uncertain to add this option since, according to several 
comments, it could deviate the eclipse configuration from the standard maven 
behaviour.

I think anyway it make sense to made it configurable for different reasons:
- it's not true that the current behaviour closely matches the maven one: it 
matches the one used by maven in the test phase, but since eclipse has no 
concept of phases this doesn't mean it will always be the expected 
configuration. There is no way to mark dependencies and source dirs as "test 
only" like maven does so there will always be a different between maven and 
eclipse. The ability to run it tests (or simply to start an application) from 
eclipse is a good argument.
- since the test-last ordering has been the default for the eclipse till 
version 2.6 and several users complained about the change I think it's better 
to explain why we changed the default but leaving the option to switch back to 
the old behaviour, given the appropriate warning. Too many users seems to be 
still tied to old (2.5) version of the plugin due to changes introduced after 
that version
- another (silly) reason is just to keep the order users are used to in eclipse 
(it's pretty normal to expect the main dirs first there) when there is nothing 
in the project that may cause conflicts and dirs ordering doesn't matter for a 
functional point of view.


Added in version 2.9, the new property is named "testSourcesLast" for 
consistency with other options. An appropriate explanation/warning has been 
added to the parameter documentation.






> Provide a way to choose .classpath ordering test-first vs. test-last
> 
>
> Key: MECLIPSE-561
> URL: http://jira.codehaus.org/browse/MECLIPSE-561
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: Core : Dependencies resolution and build path 
> (.classpath)
>Affects Versions: 2.6
>Reporter: Rustam Abdullaev
>Assignee: fabrizio giustina
> Fix For: 2.9
>
> Attachments: testBeforeMain.patch
>
>
> It seems like classpath ordering has been changed in 2.6, see bug 
> MECLIPSE-318.
> Yes it improves unit testing, but it completely breaks integration testing. 
> Now we can't run our Spring-based web application inside Eclipse because unit 
> test resources override normal resources.
> Please revert this change or provide a way to specify that I want test 
> classes/resources to be put in the classpath after non-test resources.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MAVENUPLOAD-2762) OSGiLab MonitorAdmin 1.0.0 upload request

2010-04-18 Thread Dmytro Pishchukhin (JIRA)

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218099#action_218099
 ] 

Dmytro Pishchukhin commented on MAVENUPLOAD-2762:
-

Bundle URL updated: 
http://osgilab.googlecode.com/svn/tags/monitoradmin-1.0.0/monitoradmin-1.0.0-bundle.jar

sorry for mistake

> OSGiLab MonitorAdmin 1.0.0 upload request
> -
>
> Key: MAVENUPLOAD-2762
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2762
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Dmytro Pishchukhin
>
> http://code.google.com/p/osgilab/source/browse/tags/monitoradmin-1.0.0/monitoradmin-1.0.0-bundle.jar
> http://code.google.com/p/osgilab
> http://code.google.com/u/dmytro.pishchukhin/
> I'm a project owner of OSGiLab project and http://osgilab.org blog. I want to 
> use the org.osgilab.bundles groupId for this upload.
> You can see my name listed in Project members section at 
> http://code.google.com/p/osgilab/ and http://osgilab.org.
> The bundle has no external dependencies.

-- 
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: (MAVENUPLOAD-2768) OSGiLab JMX Management Model 1.0.0 upload request

2010-04-18 Thread Dmytro Pishchukhin (JIRA)
OSGiLab JMX Management Model 1.0.0 upload request
-

 Key: MAVENUPLOAD-2768
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2768
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Dmytro Pishchukhin


http://osgilab.googlecode.com/svn/tags/jmx-1.0.0/jmx-1.0.0-bundle.jar

http://code.google.com/p/osgilab
http://code.google.com/u/dmytro.pishchukhin/

I'm a project owner of OSGiLab project and http://osgilab.org blog. I want to 
use the org.osgilab.bundles groupId for this upload.
You can see my name listed in Project members section at 
http://code.google.com/p/osgilab/ and http://osgilab.org.

The bundle has no external dependencies. 

-- 
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] Reopened: (MPMD-83) Use proper file encoding for Non-HTML reports

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy reopened MPMD-83:
---


> Use proper file encoding for Non-HTML reports
> -
>
> Key: MPMD-83
> URL: http://jira.codehaus.org/browse/MPMD-83
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD, PMD
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> The plugin currently uses {{FileWriter}} to output Non-HTML reports. This 
> includes in particular the XML report where the employed encoding must match 
> the XML declaration.
> It appears Non-HTML reports should be classified by the plugin (somehow) into 
> two groups: XML-based and plain text. For the first group, use the XML writer 
> from plexus-utils. For the later, use the configured output encoding for 
> reports (see also [Reporting Encoding 
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]).

-- 
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-93) CPD writes XML report with wrong encoding

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MPMD-93.
-

   Resolution: Fixed
Fix Version/s: 2.5
 Assignee: Herve Boutemy

for CPD report, the problem is not related to MPMD-83, but to a more specific 
CPD report bug: report file in site directory was using platform encoding, 
where the same report in target directory was using UTF-8

fixed in r935316: now both files use UTF-8

> CPD writes XML report with wrong encoding
> -
>
> Key: MPMD-93
> URL: http://jira.codehaus.org/browse/MPMD-93
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD
>Affects Versions: 2.4
>Reporter: Ulli Hafner
>Assignee: Herve Boutemy
> Fix For: 2.5
>
>
> We have Java Files encoding in our default Locale (latin 1):
> ISO-8859-1
> When running CPD on a Java file that contains german umlauts then CPD 
> produces a cpd.xml file with defined encoding of UTF-8 that contains some 
> invalid characters in latin 1 instead of UTF-8.
> Maybe the same problem as described in  Bug MPMD-83.

-- 
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: (MPMD-83) Use proper file encoding for Non-HTML reports

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MPMD-83:
--

Comment: was deleted

(was: for CPD report, the problem is not related to MPMD-93, but to a more 
specific CPD report bug: report file in site directory was using platform 
encoding, where the same report in target directory was using UTF-8

fixed in r935316: now both files use UTF-8)

> Use proper file encoding for Non-HTML reports
> -
>
> Key: MPMD-83
> URL: http://jira.codehaus.org/browse/MPMD-83
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD, PMD
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Minor
>
> The plugin currently uses {{FileWriter}} to output Non-HTML reports. This 
> includes in particular the XML report where the employed encoding must match 
> the XML declaration.
> It appears Non-HTML reports should be classified by the plugin (somehow) into 
> two groups: XML-based and plain text. For the first group, use the XML writer 
> from plexus-utils. For the later, use the configured output encoding for 
> reports (see also [Reporting Encoding 
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]).

-- 
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-83) Use proper file encoding for Non-HTML reports

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MPMD-83.
-

   Resolution: Fixed
Fix Version/s: 2.5
 Assignee: Herve Boutemy

for CPD report, the problem is not related to MPMD-93, but to a more specific 
CPD report bug: report file in site directory was using platform encoding, 
where the same report in target directory was using UTF-8

fixed in r935316: now both files use UTF-8

> Use proper file encoding for Non-HTML reports
> -
>
> Key: MPMD-83
> URL: http://jira.codehaus.org/browse/MPMD-83
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD, PMD
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.5
>
>
> The plugin currently uses {{FileWriter}} to output Non-HTML reports. This 
> includes in particular the XML report where the employed encoding must match 
> the XML declaration.
> It appears Non-HTML reports should be classified by the plugin (somehow) into 
> two groups: XML-based and plain text. For the first group, use the XML writer 
> from plexus-utils. For the later, use the configured output encoding for 
> reports (see also [Reporting Encoding 
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]).

-- 
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: (MPMD-83) Use proper file encoding for Non-HTML reports

2010-04-18 Thread Herve Boutemy (JIRA)

 [ 
http://jira.codehaus.org/browse/MPMD-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MPMD-83:
--

Fix Version/s: (was: 2.5)
 Assignee: (was: Herve Boutemy)

> Use proper file encoding for Non-HTML reports
> -
>
> Key: MPMD-83
> URL: http://jira.codehaus.org/browse/MPMD-83
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: CPD, PMD
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> The plugin currently uses {{FileWriter}} to output Non-HTML reports. This 
> includes in particular the XML report where the employed encoding must match 
> the XML declaration.
> It appears Non-HTML reports should be classified by the plugin (somehow) into 
> two groups: XML-based and plain text. For the first group, use the XML writer 
> from plexus-utils. For the later, use the configured output encoding for 
> reports (see also [Reporting Encoding 
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]).

-- 
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