[jira] (SCM-713) Check for local modifications works incorrectly with Mercurial

[Robert Scholte (JIRA)]

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

Robert Scholte moved MRELEASE-823 to SCM-713:
-

   Complexity: Intermediate
  Component/s: (was: Mercurial)
   maven-scm-provider-mercurial (hg)
Affects Version/s: (was: 2.3.2)
   1.7
  Key: SCM-713  (was: MRELEASE-823)
  Project: Maven SCM  (was: Maven 2.x Release Plugin)

> Check for local modifications works incorrectly with Mercurial
> --
>
> Key: SCM-713
> URL: https://jira.codehaus.org/browse/SCM-713
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.7
>Reporter: Stanilslav Spiridonov
>
> It just ignore modified files. In the log above the "impl\pom.xml" is modified
> C:\Development\work\repo\JRS\open\base\manager\pom>mvn release:branch 
> -DbranchName=my-branch   -DupdateBranchVersions=true
> C:\Development\work\repo\JRS\open\base\manager\pom>set 
> MAVEN_OPTS=-Dfile.encoding=UTF-8
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JRESEARCH-COMMONS: POM for base domain managers
> [INFO] JRS-COMMONS: Base service API
> [INFO] JRS-COMMONS: Base service implementation
> [INFO]
> [INFO] 
> 
> [INFO] Building JRESEARCH-COMMONS: POM for base domain managers 1.0.2-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-release-plugin:2.3.2:branch (default-cli) @ 
> org.jresearch.commons.base.manager.pom ---
> [INFO] Verifying that there are no local modifications...
> [INFO]   ignoring changes on: **\release.properties, **\pom.xml.next, 
> **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] EXECUTING: cmd.exe /X /C "hg status"
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml. Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\api\pom.xml.releaseBackup. 
> Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml.releaseBackup.
>  Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\pom\pom.xml.releaseBackup. 
> Ignoring
> What is the branch version for "JRESEARCH-COMMONS: POM for base domain 
> managers"? 
> (org.jresearch.commons.base.manager:org.jresearch.commons.base.manager.pom) 
> 1.0.2-SNAPSHOT: : Terminate batch
> job (Y/N)? y
> C:\Development\work\repo\JRS\open\base\manager\impl>hg status
> M impl\pom.xml
> ? api\pom.xml.releaseBackup
> ? impl\pom.xml.releaseBackup
> ? pom\pom.xml.releaseBackup

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SCM-713) Check for local modifications works incorrectly with Mercurial

[Robert Scholte (JIRA)]

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

Robert Scholte updated SCM-713:
---

Description: 
It just ignore modified files. In the log above the "impl\pom.xml" is modified

{noformat}
C:\Development\work\repo\JRS\open\base\manager\pom>mvn release:branch 
-DbranchName=my-branch   -DupdateBranchVersions=true

C:\Development\work\repo\JRS\open\base\manager\pom>set 
MAVEN_OPTS=-Dfile.encoding=UTF-8
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] JRESEARCH-COMMONS: POM for base domain managers
[INFO] JRS-COMMONS: Base service API
[INFO] JRS-COMMONS: Base service implementation
[INFO]
[INFO] 
[INFO] Building JRESEARCH-COMMONS: POM for base domain managers 1.0.2-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-release-plugin:2.3.2:branch (default-cli) @ 
org.jresearch.commons.base.manager.pom ---
[INFO] Verifying that there are no local modifications...
[INFO]   ignoring changes on: **\release.properties, **\pom.xml.next, 
**\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] EXECUTING: cmd.exe /X /C "hg status"
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml. Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\api\pom.xml.releaseBackup. 
Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml.releaseBackup. 
Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\pom\pom.xml.releaseBackup. 
Ignoring
What is the branch version for "JRESEARCH-COMMONS: POM for base domain 
managers"? 
(org.jresearch.commons.base.manager:org.jresearch.commons.base.manager.pom) 
1.0.2-SNAPSHOT: : Terminate batch
job (Y/N)? y
{noformat}

{noformat}
C:\Development\work\repo\JRS\open\base\manager\impl>hg status
M impl\pom.xml
? api\pom.xml.releaseBackup
? impl\pom.xml.releaseBackup
? pom\pom.xml.releaseBackup
{noformat}

  was:
It just ignore modified files. In the log above the "impl\pom.xml" is modified

C:\Development\work\repo\JRS\open\base\manager\pom>mvn release:branch 
-DbranchName=my-branch   -DupdateBranchVersions=true

C:\Development\work\repo\JRS\open\base\manager\pom>set 
MAVEN_OPTS=-Dfile.encoding=UTF-8
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] JRESEARCH-COMMONS: POM for base domain managers
[INFO] JRS-COMMONS: Base service API
[INFO] JRS-COMMONS: Base service implementation
[INFO]
[INFO] 
[INFO] Building JRESEARCH-COMMONS: POM for base domain managers 1.0.2-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-release-plugin:2.3.2:branch (default-cli) @ 
org.jresearch.commons.base.manager.pom ---
[INFO] Verifying that there are no local modifications...
[INFO]   ignoring changes on: **\release.properties, **\pom.xml.next, 
**\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] EXECUTING: cmd.exe /X /C "hg status"
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml. Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\api\pom.xml.releaseBackup. 
Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml.releaseBackup. 
Ignoring
[INFO] Not a file: 
C:\Development\work\repo\JRS\open\base\manager\pom\pom\pom.xml.releaseBackup. 
Ignoring
What is the branch version for "JRESEARCH-COMMONS: POM for base domain 
managers"? 
(org.jresearch.commons.base.manager:org.jresearch.commons.base.manager.pom) 
1.0.2-SNAPSHOT: : Terminate batch
job (Y/N)? y

C:\Development\work\repo\JRS\open\base\manager\impl>hg status
M impl\pom.xml
? api\pom.xml.releaseBackup
? impl\pom.xml.releaseBackup
? pom\pom.xml.releaseBackup



> Check for local modifications works incorrectly with Mercurial
> --
>
> Key: SCM-713
> URL: https://jira.codehaus.org/browse/SCM-713
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.7
>Reporter: Stanilslav Spiridonov
>
> It just ignore modified files. In the log above the "impl\pom.xml" is modified
> {noformat}
> C:\Development\work\repo\JRS\open\base\manager\pom>mvn release:branch 
> -DbranchName=my-branch   -DupdateBranchVersions=true
> C:\Development\work\repo\JRS\open\base\manager\pom>set 
> MAVEN_OPTS=-Dfile.encoding=UTF-8
> [INFO] Scanning for projects...
> [INFO]

[jira] (SCM-713) Check for local modifications works incorrectly with Mercurial

[Robert Scholte (JIRA)]

[ 
https://jira.codehaus.org/browse/SCM-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319834#comment-319834
 ] 

Robert Scholte commented on SCM-713:


It looks to be an issue with the working directory.

{{C:\Development\work\repo\JRS\open\base\manager\pom\}} is passed as the 
working directory and the results of {{hg status}} are assumed to be relative 
to this folder.



> Check for local modifications works incorrectly with Mercurial
> --
>
> Key: SCM-713
> URL: https://jira.codehaus.org/browse/SCM-713
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.7
>Reporter: Stanilslav Spiridonov
>
> It just ignore modified files. In the log above the "impl\pom.xml" is modified
> {noformat}
> C:\Development\work\repo\JRS\open\base\manager\pom>mvn release:branch 
> -DbranchName=my-branch   -DupdateBranchVersions=true
> C:\Development\work\repo\JRS\open\base\manager\pom>set 
> MAVEN_OPTS=-Dfile.encoding=UTF-8
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JRESEARCH-COMMONS: POM for base domain managers
> [INFO] JRS-COMMONS: Base service API
> [INFO] JRS-COMMONS: Base service implementation
> [INFO]
> [INFO] 
> 
> [INFO] Building JRESEARCH-COMMONS: POM for base domain managers 1.0.2-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-release-plugin:2.3.2:branch (default-cli) @ 
> org.jresearch.commons.base.manager.pom ---
> [INFO] Verifying that there are no local modifications...
> [INFO]   ignoring changes on: **\release.properties, **\pom.xml.next, 
> **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] EXECUTING: cmd.exe /X /C "hg status"
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml. Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\api\pom.xml.releaseBackup. 
> Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\impl\pom.xml.releaseBackup.
>  Ignoring
> [INFO] Not a file: 
> C:\Development\work\repo\JRS\open\base\manager\pom\pom\pom.xml.releaseBackup. 
> Ignoring
> What is the branch version for "JRESEARCH-COMMONS: POM for base domain 
> managers"? 
> (org.jresearch.commons.base.manager:org.jresearch.commons.base.manager.pom) 
> 1.0.2-SNAPSHOT: : Terminate batch
> job (Y/N)? y
> {noformat}
> {noformat}
> C:\Development\work\repo\JRS\open\base\manager\impl>hg status
> M impl\pom.xml
> ? api\pom.xml.releaseBackup
> ? impl\pom.xml.releaseBackup
> ? pom\pom.xml.releaseBackup
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (DOXIASITETOOLS-67) Velocity ToolManager doesn't work for skins and custom templates

[Robert Scholte (JIRA)]

[ 
https://jira.codehaus.org/browse/DOXIASITETOOLS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319835#comment-319835
 ] 

Robert Scholte commented on DOXIASITETOOLS-67:
--

I've retried it, also with maven-site-plugin-3.2, and most of the tools work.
$context and $link are having issues and $alt is not recognized. The sad part: 
the sources of velocity-tools are not available at Maven Central. And when 
downloading the sources, the linenumbers don't match.

> Velocity ToolManager doesn't work for skins and custom templates
> 
>
> Key: DOXIASITETOOLS-67
> URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-67
> Project: Maven Doxia Sitetools
>  Issue Type: Bug
>  Components: Site renderer
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> DOXIA-450 introduces the Velocity ToolManager, but this only works with the 
> default site rendering settings, because in these cases the classloader 
> changes to pick up the right skin or template.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCOMPILER-194) Strange effects with springs @Configurable (AspectJ) and new compiler plugin version 3.0

[Oliver Gierke (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319836#comment-319836
 ] 

Oliver Gierke commented on MCOMPILER-194:
-

I've seen similar issues. Here's what I think I could break it down to. The 3.0 
version of the compiler somehow seems to detect "changes" that do not appear to 
be ones. Just run {{mvn clean test-compile}} and {{mvn test}} afterwards and 
you still see

{noformat}
[INFO] Changes detected - recompiling the module!
{noformat}

for the second invocation. Now the AspectJ plugin set up to run before the 
compiler *has not been invoked as there were no changes* actually. Now the 
compiler plugin essentially throws away the generated class files and 
recompiles them which means the AspectJ compilation step is not applied.

The only safe way to get this working for me is using {{mvn clean install}} all 
the way.

> Strange effects with springs @Configurable (AspectJ) and new compiler plugin 
> version 3.0
> 
>
> Key: MCOMPILER-194
> URL: https://jira.codehaus.org/browse/MCOMPILER-194
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: jdk 1.6.0_38, jdk 1.6.0_37
>Reporter: Andreas Höhmann
>Priority: Blocker
>
> I have no details I can only report the "effects" ..
> I have a maven project with compiler-plugin 2.5.1,
> aspectj-plugin 1.4, java 1.6 and a lot of @Configurable 
> annotations in my code. Aspectj will decorate these classes
> so @Autowired dependencies injected during runtime. 
> All is working fine.
> Now I switch to compiler-plugin 3.0 ... nothing else changed!
> Then "sometimes" I got NPE's because the injected service etc. are
> not available. I guess aspectj was not successfull. I have no
> errors etc. anywhere during build.
> Strang :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5308) i installed the maven and run some comment in it but it showing some plugin is not available

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MNG-5308.
---

Resolution: Not A Bug
  Assignee: Robert Scholte

After executing Maven for the first time, you should have seen the following 
message:
{noformat}[INFO] Repository 'central' will be blacklisted{noformat}

This is very likely a network/proxy problem.

Try {{mvn help:help -U}} until you've downloaded the maven-help-plugin. ({{-U}} 
will force an update, overruling blacklisted repositories)

If you're using a proxy, please read 
http://maven.apache.org/guides/mini/guide-proxies.html


> i installed the maven and run some comment in it but it showing some plugin 
> is not available
> 
>
> Key: MNG-5308
> URL: https://jira.codehaus.org/browse/MNG-5308
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Plugin Requests
> Environment: C:\Documents and Settings\mercerserver>mvn clean
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building Maven Default Project
> [INFO]task-segment: [clean]
> [INFO] 
> 
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not 
> exist or no valid version could be found
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Jul 05 15:51:19 IST 2012
> [INFO] Final Memory: 1M/15M
> [INFO] 
> 
>Reporter: Dinesh Kumar
>Assignee: Robert Scholte
> Attachments: error].bmp
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-4485) Informational messages could be clearer regarding goal execution

[Robert Scholte (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319838#comment-319838
 ] 

Robert Scholte commented on MNG-4485:
-

Actually, if you prefix the plugin with the groupId, i.e. 
{{org.apache.maven.plugins:maven-clean-plugin:2.3:clean}}, it would make it a 
lot easier to copy/paste that line and execute it directly on the commandline.
I'd prefer to keep it as compact as possible, since this line is printed quite 
often during a build.

> Informational messages could be clearer regarding goal execution
> 
>
> Key: MNG-4485
> URL: https://jira.codehaus.org/browse/MNG-4485
> Project: Maven 2 & 3
>  Issue Type: Improvement
>  Components: Errors
>Affects Versions: 3.0-alpha-5
>Reporter: Paul Benedict
>Priority: Trivial
> Fix For: Issues to be reviewed for 3.x
>
>
> As the lifecycle of projects are executed, these type of informational 
> messages are emitted:
> {{[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ project-name ---}}
> Based on my own team, I think there are three things to note:
>  * The {{plugin:version::goal}} can easily be confused with the the 
> dependency {{artifactId:version:classifier}} format. Seriously. ;-)
>  * I don't think the @ symbol is natural to describe the project.
>  * The execution name probably could be suppressed unless DEBUG was on.
> How about?
> {{[INFO] --- maven-clean-plugin:2.3 executing goal "clean" for project 
> Project Name ---}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin

[Michael Koch (JIRA)]

[ 
https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319840#comment-319840
 ] 

Michael Koch commented on MSKINS-75:


I am currently working on a patch for this and will attach it when it's ready.

> Add Piwik web analytics tracking code integration to Fluido skin
> 
>
> Key: MSKINS-75
> URL: https://jira.codehaus.org/browse/MSKINS-75
> Project: Maven Skins
>  Issue Type: New Feature
>  Components: Fluido Skin
>Reporter: Michael Koch
>Priority: Minor
>
> I'd like to have support for adding the [Piwik web 
> analytics|http://piwik.org/] [tracking 
> code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code]
>  for the Fluido skin. This is similar to the Google analytics code or 
> MSKINS-33.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin

[Michael Koch (JIRA)]

Michael Koch created MSKINS-75:
--

 Summary: Add Piwik web analytics tracking code integration to 
Fluido skin
 Key: MSKINS-75
 URL: https://jira.codehaus.org/browse/MSKINS-75
 Project: Maven Skins
  Issue Type: New Feature
  Components: Fluido Skin
Reporter: Michael Koch
Priority: Minor


I'd like to have support for adding the [Piwik web analytics|http://piwik.org/] 
[tracking 
code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code]
 for the Fluido skin. This is similar to the Google analytics code or MSKINS-33.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin

[Michael Koch (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Koch updated MSKINS-75:
---

Attachment: mskins-75.patch

Added patch which adds Piwi tracking code integration to Fluido skin.

* add support in site.vm
* add documentation in index.apt.vm
* add integration test

I've tested the patch with 
http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin rev 1447032.

> Add Piwik web analytics tracking code integration to Fluido skin
> 
>
> Key: MSKINS-75
> URL: https://jira.codehaus.org/browse/MSKINS-75
> Project: Maven Skins
>  Issue Type: New Feature
>  Components: Fluido Skin
>Reporter: Michael Koch
>Priority: Minor
> Attachments: mskins-75.patch
>
>
> I'd like to have support for adding the [Piwik web 
> analytics|http://piwik.org/] [tracking 
> code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code]
>  for the Fluido skin. This is similar to the Google analytics code or 
> MSKINS-33.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MPLUGIN-241) Add Annotation for Objects injected by Maven

[Robert Scholte (JIRA)]

Robert Scholte created MPLUGIN-241:
--

 Summary: Add Annotation for Objects injected by Maven
 Key: MPLUGIN-241
 URL: https://jira.codehaus.org/browse/MPLUGIN-241
 Project: Maven 2.x Plugin Tools
  Issue Type: Improvement
Affects Versions: 3.2, 3.1, 3.0
Reporter: Robert Scholte


With version 3.0 we've introduced Annotations.

There are several objects which are injected by Maven, but is hard to find the 
list of available objects.

We decided to make life a bit easier by adding some magic to the @Component 
tag, by recognizing the Type of the field, for instance {{MavenProject}}

But Components are injected differently then these objects, so this seems to 
have been a poor choice.

Maybe it's better to add something like 
{code}
@Reference( ENUMVALUE )
{code}

where ENUMVALUE can be:
* PROJECT
* SESSION
* SETTINGS
* MOJOEXECUTION
* PLUGIN
* LOCALREPOSITORY
* REACTORPROJECTS
* ... (any rootObject)








--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect

[Maik Riechert (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319657#comment-319657
 ] 

Maik Riechert edited comment on MASSEMBLY-644 at 2/17/13 10:29 AM:
---

Sorry, made a mistake on formatting and can't edit it. The bold parts are 
surrounded by stars...

Edit: The debug output I get is the following:

{noformat}[DEBUG] Processing binary dependencies for module project: 
com.ardor3d:ardor3d-lwjgl:bundle:0.9-SNAPSHOT
[DEBUG] Processing DependencySet (output=null)
[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency path 
information.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[WARNING] The following patterns were never triggered in this artifact 
exclusion filter:
o  '*:lwjgl*natives-*'
o  '*:jinput*natives-*'
[...]
[DEBUG] Adding dependency artifact 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4.
[...]{noformat}

Shouldn't this artifact be matched by {noformat} *:lwjgl*natives-*{noformat} ? 
Using true doesn't fix the 
problem.

As mentioned, it works for an assembly inside a module (ardor3d-examples):

{noformat}[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency 
path information.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4 was removed by one 
or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-linux:2.0.5 was removed by 
one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-windows:2.0.5 was removed 
by one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-osx:2.0.5 was removed by 
one or more filters.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[DEBUG] The following artifacts were removed by this artifact exclusion filter: 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4
net.java.jinput:jinput-platform:jar:natives-linux:2.0.5
net.java.jinput:jinput-platform:jar:natives-windows:2.0.5
net.java.jinput:jinput-platform:jar:natives-osx:2.0.5{noformat}

  was (Author: neothemachine):
Sorry, made a mistake on formatting and can't edit it. The bold parts are 
surrounded by stars...
  
> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet, filtering, moduleSet
>Affects Versions: 2.4
>Reporter: Maik Riechert
>
> I'm trying to create a distribution assembly of a multi-module project in a 
> separate distribution module which works quite nice, except that exclusions 
> of dependencies of modules seem to be ignored. This is strange, as the same 
> exclusions do work in an assembly inside a submodule.
> This is the problematic descriptor:
> {{
> 
> 
>   lwjgl
>   
>   zip
>   
>   false
>   
>   
>   true
>   
>   com.ardor3d:ardor3d-animation
>   com.ardor3d:ardor3d-awt
>   com.ardor3d:ardor3d-collada
>   com.ardor3d:ardor3d-core
>   com.ardor3d:ardor3d-effects
>   com.ardor3d:ardor3d-extras
>   com.ardor3d:ardor3d-lwjgl
>   com.ardor3d:ardor3d-math
>   com.ardor3d:ardor3d-savable
>   com.ardor3d:ardor3d-swt
>   com.ardor3d:ardor3d-terrain
>   com.ardor3d:ardor3d-ui
>   
>   
>   false
>   
>   
>   
>   
> *:lwjgl*natives-*
>   
> *:jinput*natives-*
>   
>   
>   
>   
>   
>   
>   
>   
>   target/natives
>   natives
>   
>   *jogl*
>   *nati

[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect

[Maik Riechert (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319657#comment-319657
 ] 

Maik Riechert edited comment on MASSEMBLY-644 at 2/17/13 11:13 AM:
---

Sorry, made a mistake on formatting and can't edit it. The bold parts are 
surrounded by stars...

Edit: The debug output I get is the following:

{noformat}[DEBUG] Processing binary dependencies for module project: 
com.ardor3d:ardor3d-lwjgl:bundle:0.9-SNAPSHOT
[DEBUG] Processing DependencySet (output=null)
[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency path 
information.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[WARNING] The following patterns were never triggered in this artifact 
exclusion filter:
o  '*:lwjgl*natives-*'
o  '*:jinput*natives-*'
[...]
[DEBUG] Adding dependency artifact 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4.
[...]{noformat}

Shouldn't this artifact be matched by {noformat} *:lwjgl*natives-*{noformat}?

As mentioned, it works for an assembly inside a module (ardor3d-examples):

{noformat}[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency 
path information.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4 was removed by one 
or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-linux:2.0.5 was removed by 
one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-windows:2.0.5 was removed 
by one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-osx:2.0.5 was removed by 
one or more filters.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[DEBUG] The following artifacts were removed by this artifact exclusion filter: 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4
net.java.jinput:jinput-platform:jar:natives-linux:2.0.5
net.java.jinput:jinput-platform:jar:natives-windows:2.0.5
net.java.jinput:jinput-platform:jar:natives-osx:2.0.5{noformat}

  was (Author: neothemachine):
Sorry, made a mistake on formatting and can't edit it. The bold parts are 
surrounded by stars...

Edit: The debug output I get is the following:

{noformat}[DEBUG] Processing binary dependencies for module project: 
com.ardor3d:ardor3d-lwjgl:bundle:0.9-SNAPSHOT
[DEBUG] Processing DependencySet (output=null)
[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency path 
information.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[WARNING] The following patterns were never triggered in this artifact 
exclusion filter:
o  '*:lwjgl*natives-*'
o  '*:jinput*natives-*'
[...]
[DEBUG] Adding dependency artifact 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4.
[...]{noformat}

Shouldn't this artifact be matched by {noformat} *:lwjgl*natives-*{noformat} ? 
Using true doesn't fix the 
problem.

As mentioned, it works for an assembly inside a module (ardor3d-examples):

{noformat}[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency 
path information.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4 was removed by 
one or more filters.
[DEBUG] org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4 was removed by one 
or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-linux:2.0.5 was removed by 
one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-windows:2.0.5 was removed 
by one or more filters.
[DEBUG] net.java.jinput:jinput-platform:jar:natives-osx:2.0.5 was removed by 
one or more filters.
[DEBUG] Statistics for Excludes filter:
o '*:lwjgl*natives-*'
o '*:jinput*natives-*'

[DEBUG] The following artifacts were removed by this artifact exclusion filter: 
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-windows:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-linux:2.8.4
org.lwjgl.lwjgl:lwjgl-platform:jar:natives-osx:2.8.4
net.java.jinput:jinput-platform:jar:natives-linux:2.0.5
net.java.jinput:jinput-platform:jar:natives-windows:2.0.5
net.java.jinput:jinput-platform:jar:natives-osx:2.0.5{noformat}
  
> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet, filtering

[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect

[Maik Riechert (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319849#comment-319849
 ] 

Maik Riechert commented on MASSEMBLY-644:
-

Alright... I found the problem. The module was using the (super pom) default 
plugin version (2.2-beta5) while the problematic assembly uses the current 2.4. 
Apparently, the behaviour of pattern matching has changed, which is implemented 
in maven-common-artifact-filters (2.2-beta5 used version 1.1, while 2.4 uses 
1.4) in the method 
org.apache.maven.shared.artifact.filter.PatternIncludesArtifactFilter#matchAgainst.
 The docs say {noformat}Additionally, wildcards can be used, as in 
*:maven-*{noformat} which in my opinion is not exact enough, given the specific 
behaviour of the implementation.

Changing my patterns to
{noformat}*:lwjgl*:*:natives-*
*:jinput*:*:natives-*
{noformat}
makes it work in 2.4.

If I understand the code correctly, then patterns must be given in a form 
"x:y:..." where each additional ":..." segment is optional as long as nothing 
else follows it. There's also some special case code which tries to handle the 
other direction so that patterns can have the form "*:y:z" which means that 
only the last two segments y and z are matched and must in fact be the end, and 
anything before that doesn't matter. For this special case it is important 
which id-forms get checked against, namely the shortId "groupId:artifactId", an 
id without version "groupId:artifactId:type[:classifier]", and the fully 
qualified id "groupId:artifactId:type[:classifier]:version". The fact that the 
classifier is left out in the string segments to match against is a bit 
troubling to me when reasoning about the matching logic, but anyway.

> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet, filtering, moduleSet
>Affects Versions: 2.4
>Reporter: Maik Riechert
>
> I'm trying to create a distribution assembly of a multi-module project in a 
> separate distribution module which works quite nice, except that exclusions 
> of dependencies of modules seem to be ignored. This is strange, as the same 
> exclusions do work in an assembly inside a submodule.
> This is the problematic descriptor:
> {{
> 
> 
>   lwjgl
>   
>   zip
>   
>   false
>   
>   
>   true
>   
>   com.ardor3d:ardor3d-animation
>   com.ardor3d:ardor3d-awt
>   com.ardor3d:ardor3d-collada
>   com.ardor3d:ardor3d-core
>   com.ardor3d:ardor3d-effects
>   com.ardor3d:ardor3d-extras
>   com.ardor3d:ardor3d-lwjgl
>   com.ardor3d:ardor3d-math
>   com.ardor3d:ardor3d-savable
>   com.ardor3d:ardor3d-swt
>   com.ardor3d:ardor3d-terrain
>   com.ardor3d:ardor3d-ui
>   
>   
>   false
>   
>   
>   
>   
> *:lwjgl*natives-*
>   
> *:jinput*natives-*
>   
>   
>   
>   
>   
>   
>   
>   
>   target/natives
>   natives
>   
>   *jogl*
>   *nativewindow*
>   *newt*
>   *gluegen*
>   META-INF/
>   
>   
>   
> 
> }}
> This assembly descriptor can be found here: 
> https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
> It produces a zip which also contains 
> "lwjgl-platform-2.8.4-natives-linux.jar" and others which should be matched 
> by the filter.
> The submodule where the exclusions work can be found at: 
> https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
> If you need any other information, please tell me.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrat

[jira] (DOXIASITETOOLS-67) Velocity ToolManager doesn't work for skins and custom templates

[Michael Osipov (JIRA)]

[ 
https://jira.codehaus.org/browse/DOXIASITETOOLS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319852#comment-319852
 ] 

Michael Osipov commented on DOXIASITETOOLS-67:
--

This is very embarassing and unprofessional for an Apache project. Jason was 
one of the devs of Velocity. Maybe he could contact Nathan or Will to fix 
missing artifacts?

> Velocity ToolManager doesn't work for skins and custom templates
> 
>
> Key: DOXIASITETOOLS-67
> URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-67
> Project: Maven Doxia Sitetools
>  Issue Type: Bug
>  Components: Site renderer
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> DOXIA-450 introduces the Velocity ToolManager, but this only works with the 
> default site rendering settings, because in these cases the classloader 
> changes to pick up the right skin or template.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MPMD-162) PMD/CPD report does not take into account pmd.excludeFromFailureFile

[Mirko Friedenhagen (JIRA)]

Mirko Friedenhagen created MPMD-162:
---

 Summary: PMD/CPD report does not take into account 
pmd.excludeFromFailureFile
 Key: MPMD-162
 URL: https://jira.codehaus.org/browse/MPMD-162
 Project: Maven 2.x PMD Plugin
  Issue Type: Bug
  Components: CPD, PMD
Affects Versions: 3.0
Reporter: Mirko Friedenhagen


MPMD-161 introduced exclusion of violations by property files. However, these 
properties are not picked up during report generation, so while they are 
excluded during {{pmd:check}} and {{pmd:cpd-check}}, in the site these 
violations still show up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-681) Error uploading site - String index out of range: 0

[Leonardo Bueno Postacchini (JIRA)]

[ 
https://jira.codehaus.org/browse/MSITE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319854#comment-319854
 ] 

Leonardo Bueno Postacchini commented on MSITE-681:
--

Also happens on MacOS X 10.8.2, Maven 3.0.4

> Error uploading site - String index out of range: 0
> ---
>
> Key: MSITE-681
> URL: https://jira.codehaus.org/browse/MSITE-681
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 2.3, 2.4, 3.0, 3.1, 3.2
> Environment: Windows 7, Java 5, Maven 2.2.1, Maven Site Plugin 3.2
>Reporter: Jackie Noi
>
> The following exception occurs with all maven site plugin versions greater 
> than 2.2 during site:deploy.
> This is the stacktrace of version 3.2
> bq.
> $ mvn -e site:deploy
> + Error stacktraces are turned on.
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_22
> Java home: C:\apps\dev\java\sun_jdk1.5.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building PL01
> [INFO]task-segment: [site:deploy]
> [INFO] 
> 
> [INFO] [site:deploy {execution: default-cli}]
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Opened
> [INFO] Pushing D:\workspaces\eclipse38\pl01\target\site
> [INFO]>>> to sftp://mv002.local/projects/pl01/htdocs/site/./
> Recursively uploading directory D:\workspaces\eclipse38\pl01\target\site as ./
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Disconnecting
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Disconnected
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Error occurred while deploying 
> 'D:\workspaces\eclipse38\pl01\target\site' to remote repository: 
> sftp://mv002.local/projects/pl01/site/
> String index out of range: 0
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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:348)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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:592)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading 
> site
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:451)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:286)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:247)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:164)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 m

[jira] (MSITE-681) Error uploading site - String index out of range: 0

[Leonardo Bueno Postacchini (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSITE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Bueno Postacchini updated MSITE-681:
-

Attachment: failure-macosx.txt

> Error uploading site - String index out of range: 0
> ---
>
> Key: MSITE-681
> URL: https://jira.codehaus.org/browse/MSITE-681
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 2.3, 2.4, 3.0, 3.1, 3.2
> Environment: Windows 7, Java 5, Maven 2.2.1, Maven Site Plugin 3.2
>Reporter: Jackie Noi
> Attachments: failure-macosx.txt
>
>
> The following exception occurs with all maven site plugin versions greater 
> than 2.2 during site:deploy.
> This is the stacktrace of version 3.2
> bq.
> $ mvn -e site:deploy
> + Error stacktraces are turned on.
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_22
> Java home: C:\apps\dev\java\sun_jdk1.5.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building PL01
> [INFO]task-segment: [site:deploy]
> [INFO] 
> 
> [INFO] [site:deploy {execution: default-cli}]
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Opened
> [INFO] Pushing D:\workspaces\eclipse38\pl01\target\site
> [INFO]>>> to sftp://mv002.local/projects/pl01/htdocs/site/./
> Recursively uploading directory D:\workspaces\eclipse38\pl01\target\site as ./
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Disconnecting
> sftp://mv002.local/projects/pl01/htdocs/site/ - Session: Disconnected
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Error occurred while deploying 
> 'D:\workspaces\eclipse38\pl01\target\site' to remote repository: 
> sftp://mv002.local/projects/pl01/site/
> String index out of range: 0
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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:348)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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:592)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading 
> site
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:451)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:286)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:247)
> at 
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:164)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.ma

[jira] (MDEP-399) Multi-module dependencies incorrectly marked as unused

[Tim Williamson (JIRA)]

Tim Williamson created MDEP-399:
---

 Summary: Multi-module dependencies incorrectly marked as unused
 Key: MDEP-399
 URL: https://jira.codehaus.org/browse/MDEP-399
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: analyze
Affects Versions: 2.6, 2.5.1, 2.5, 2.4, 2.3, 2.2, 2.1, 2.0, 2.0-alpha-4
Reporter: Tim Williamson
 Attachments: mda-test.tar

MDEP-72 made DefaultProjectDependencyAnalyzer.buildArtifactClassMap() only 
consider jar files, i.e.:
{code}if ( file != null && file.getName().endsWith( ".jar" ) ){code}
This causes it to ignore all classes defined in a submodule of a multi-module 
project.  See the attached example.  It has two submodules:
- a, which defines an interface Foo
- b, which defines a class FooImpl that implements Foo

Running "mvn dependency:analyze" results in:
{code}
[WARNING] Unused declared dependencies found:
[WARNING]com.example:a:jar:0.0.1-SNAPSHOT:compile
{code}

The following change fixes the issue:
{code}if ( file != null && (file.getName().endsWith( ".jar" ) || 
file.isDirectory()) ){code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-109) Dependency plugin looses file permissions when unpacking or copying artifact items

[Leonid Ilyevsky (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319856#comment-319856
 ] 

Leonid Ilyevsky commented on MDEP-109:
--

This problem is still there. More specifically, when unpacking tar.gz on linux, 
and the files have specific permissions for the group in the archive, they are 
incorrect after the unpack.
I believe, the reason is that java.io.File class does not support Posix style 
permissions, and obviously this is what is used in the dependency plugin.
There are two ways of fixing it.
First way is to use java.nio.file.attribute package that supports Posix 
permissions, but this is available only since Java 7, and so this fix will not 
work with Java 6. I personally would prefer this solution; we all will start 
using Java 7 anyway at some point.
Another way is to call tar utility from inside the plugin, instead of pure 
clean Java solution.


> Dependency plugin looses file permissions when unpacking or copying artifact 
> items
> --
>
> Key: MDEP-109
> URL: https://jira.codehaus.org/browse/MDEP-109
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Vincent Massol
>
> I have to add the following ugly config in my pom.xml to overcome this:
> {code}
>   
> org.apache.maven.plugins
> maven-antrun-plugin
> 
>   
> prepare-package
> 
>   run
> 
> 
>   
> 
>  file="${project.build.directory}/dependency/bin/windres" perm="ugo+rx"/>
>  perm="ugo+rx"/>
> ...
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-400) Ability to create symbolic link to the copied artifact

[Leonid Ilyevsky (JIRA)]

Leonid Ilyevsky created MDEP-400:


 Summary: Ability to create symbolic link to the copied artifact
 Key: MDEP-400
 URL: https://jira.codehaus.org/browse/MDEP-400
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: copy-dependencies
Affects Versions: 2.6
 Environment: linux
Reporter: Leonid Ilyevsky


Currently, when copying dependencies, we have two choices for the final name: 
either strip the version or not.
It would be very useful to have it both ways: do not strip the version, but in 
addition, create a symbolic link with the version stripped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira