date:20100527

Use of proxy properties in lightweight http wagon is not thread-safe


 Key: WAGON-308
 URL: http://jira.codehaus.org/browse/WAGON-308
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http-lightweight
Affects Versions: 1.0-beta-6
Reporter: Benjamin Bentmann


The usage of system properties to configure the proxy for the lightweight wagon 
makes it not thread safe. E.g. as discovered by the Maven IT for MNG-2305, this 
concurrency issue makes parallel artifact resolution via proxy fail 
intermittently.

Moving on to Java 1.5+ APIs, it should be feasible to fix this via 
per-connection proxy settings.


-- 
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: (SUREFIRE-620) Ability to access manifest resource while running unit tests

2010-05-27 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222826#action_222826
 ] 

Milos Kleint commented on SUREFIRE-620:
---

currently the only option is to have the manifest manually created or somehow 
generated (either the real manifest or a test mockup one) and pass it to the 
test classpath via a parameter of the surefire plugin

http://maven.apache.org/plugins/maven-surefire-plugin/examples/additional-classpath.html


 Ability to access manifest resource while running unit tests
 

 Key: SUREFIRE-620
 URL: http://jira.codehaus.org/browse/SUREFIRE-620
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 2.5
 Environment: n/a
Reporter: Ernst de Haan
Priority: Minor

 Use case:
 - my code calls getClass().getPackage().getImplementationVersion() to 
 determine the version specified in the manifest
 - I would like to test this code, for example making sure the returned string 
 is not null
 Currently, when I run mvn test it does not generate the JAR, nor does it 
 not make the META-INF/MANIFEST.MF file available in the classpath.
 First question is whether this is a *unit* test or an *integration* test. I 
 would say a unit test, because no other code bases are involved, this should 
 be within a single module, and not testing any dependencies.
 Secondly, is the test valid at all if it uses a resource. I would say yes, 
 because it is even standard functionality offered by J2SE and I consider this 
 a good approach to determining meta data from the codebase self.
 Thirdly, should the Surefire plugin depend on the JAR being created or should 
 it just generate the manifest (and copy/generate other resources?) and stick 
 them where the compiled classes go?

-- 
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: (MRELEASE-503) When interactive resolving all dependencies no dependencies get resolved

2010-05-27 Thread Gabriel Dogaru (JIRA)


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

Gabriel Dogaru closed MRELEASE-503.
---

Resolution: Not A Bug

 When interactive resolving all dependencies no dependencies get resolved
 

 Key: MRELEASE-503
 URL: http://jira.codehaus.org/browse/MRELEASE-503
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-9
 Environment: windows xp, maven 2.2.1, release plugin 2.0.9
Reporter: Gabriel Dogaru

 Steps to reproduce:
 * interactive resolve all dependencies
 Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
 Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1:
 * select 0
 Even if I enter all the values correctly it says there are snapshot 
 dependencies.
 I did some debugging and here is the problem:
 in org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.java 
 in the method 
  private void resolveSnapshots(Set projectDependencies, Set 
 reportDependencies, Set extensionDependencies,
   Set pluginDependencies, ReleaseDescriptor 
 releaseDescriptor)
 throws ReleaseExecutionException {
 there is this peace of code:
   case 0:
 prompter.showMessage(RESOLVE_ALL_SNAPSHOT_MESSAGE);
 snapshotSet.addAll(projectDependencies);
 snapshotSet.addAll(reportDependencies);
 snapshotSet.addAll(extensionDependencies);
 snapshotSet.addAll(pluginDependencies);
 resolvedSnapshots = processSnapshot(snapshotSet);
 break;
 The method processSnapshot removes the item from snapshotSet once it resolves 
 it. 
 After this method finishes the check is made that projectDependencies, 
 reportDependencies etc are empty. But they never get modified, instead 
 snapshotSet gets empty, but no one caries any more.
 A solution I suggest is to use
 case 0:
 prompter.showMessage(RESOLVE_ALL_SNAPSHOT_MESSAGE);
 resolvedSnapshots = new HashMap();
 
 resolvedSnapshots.putAll(processSnapshot(projectDependencies));
 
 resolvedSnapshots.putAll(processSnapshot(reportDependencies));
 
 resolvedSnapshots.putAll(processSnapshot(extensionDependencies));
 
 resolvedSnapshots.putAll(processSnapshot(pluginDependencies));
 instead of the current code for case: 0 and remove the snapshotSet variable

-- 
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: (MSITE-227) site:deploy - wrong links in ${modules} when artifactId=module's directory

2010-05-27 Thread Lukas Theussl (JIRA)


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

Lukas Theussl updated MSITE-227:


Attachment: MSITE-227-working.zip

The workaround is to specify a {{url}} element for all modules and the 
parent. See attached working test project. Actually I am not sure if this 
should be called a workaround or the proper solution, I didn't find any docs on 
it.

Note that with published site-plugin-2.1 the links are ok as well but the 
modules sites suffer from MSITE-456, which is fixed in 2.1.1-SNAPSHOT.


 site:deploy - wrong links in ${modules} when artifactId=module's directory
 ---

 Key: MSITE-227
 URL: http://jira.codehaus.org/browse/MSITE-227
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 2.0-beta-5, 2.0
 Environment: Eclipse IDE
Reporter: Guimiot Isabelle
 Attachments: MSITE-227-working.zip, MSITE-227.zip


 I have a problem in the ${modules} part when I run the site:deploy goal.
 my project contains a root module and 2 sub-modules, at the same directory 
 depth (I'm using Eclipse) :
 workspace/myRoot/
 workspace/myModule1/
 workspace/myModule2/
 my root pom contains this module declaration :
 modules
   module../myModule1/module
   module../myModule1/module
 /modules
 the site:deploy goal gives this structure :
 [deploydir]/myRoot/index.html -- root's index
 [deploydir]/myRoot/myModule1/index.html -- first module's index
 [deploydir]/myRoot/myModule2/index.html -- second module's index
 when the project name (directory name in the workspace) and the artifactId 
 are exactly the same, I have wrong links, both in root and in sub-modules 
 pages :
 - in the root page, my links to submodules are like this :
 h5Modules/h5
 ul 
 li class=none
a href=../myModule1/index.htmlmyModule1/a !-- should be 
 myModule1/index.html instead --
 /li  
 li class=none
a href=../myModule2/index.htmlmyModule2/a !-- should be 
 myModule2/index.html instead --
 /li
 /ul
 - and in both modules pages, my link to the parent project is like this :
 h5Parent project/h5
 ul
 li class=none
a href=../myRoot/index.htmlmyRoot/a !-- should be 
 ../index.html instead --
 /li
 /ul
 The weirdest thing is that everything is fine when the artefactId and the 
 eclipse project name (directory) are different !!! the problem appears only 
 when they are identical...
 Thanks for your help !

-- 
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-4689) Dependency is copied from original source directory instead of .m2 using maven 3

2010-05-27 Thread Jake Zuidema (JIRA)

Dependency is copied from original source directory instead of .m2 using maven 3


 Key: MNG-4689
 URL: http://jira.codehaus.org/browse/MNG-4689
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0-beta-1
 Environment: SUSE 9 Linux, OpenJDK 1.6.0 build 11.0-b17, Maven 
3.0-beta-1
Reporter: Jake Zuidema
 Attachments: mavenDepsCopyExample.tar

Using Maven 2.2.1, the maven-dependency-plugin copy goal always copied the 
artifacts from the local .m2, which meant that they kept their full name (ex: 
ccad-moda-1.0.0-SNAPSHOT-system-help.pdf).  Using Maven 3.0-beta-1, this is no 
longer always the case.  If I build just the assembly sub-module, then it 
copies the artifact from the local .m2 and maintains the name.  If I build the 
whole project, which includes building the module that produces the artifact 
being copied, then Maven 3 skips going to the local .m2 and instead goes back 
to the original source of the artifact and copies it from there.  This results 
in a copied file with the short name (ex: system-help.pdf).

Here are some lines from the build logs to show the difference.

Maven 2.2.1
===
[INFO] Configured Artifact: 
com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
[DEBUG] Skipping disabled repository central
[DEBUG] ccad-moda: using locally installed snapshot
[INFO] Copying 
/home/jzuidema/.m2/repository/com/ccadllc/test1/ccad-moda/1.0.0-SNAPSHOT/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
 to 
/extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf


Maven 3.0-beta-1

[INFO] Configured Artifact: 
com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
[INFO] Copying /extra1/export/home/jzuidema/tmp2/test1/moda/system-help.pdf to 
/extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/system-help.pdf


Attached is an example project with the build logs from a maven 2.2.1 and a 
3.0-beta-1 run of mvn -X clean install at the top level of the project.

-- 
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: (MRELEASE-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

[
http://jira.codehaus.org/browse/MRELEASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222838#action_222838
]

Carlo de Wolf commented on MRELEASE-565:

Oi, where is did the edit button go?

CLONE -Updating of dependencyManagement inconsistent with updating of
dependencies with regard to SNAPSHOTs
---

Key: MRELEASE-565
URL: http://jira.codehaus.org/browse/MRELEASE-565
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: maven 2.0.4, win XP
Reporter: Carlo de Wolf
Assignee: Emmanuel Venisse
Fix For: 2.0-beta-5

The mechanism in release:prepare for creating the new development version of
POM's handles snapshots that are part of the current reactor build
differently for dependencyManagement and for dependencies.
A snapshot version in a dependencies section will be updated to the next
development version whereas one in dependencyManagement won't.
The attached patch will change this behavior. It will update a snapshot
version under dependencyManagement if and only if it is part of the current
reactor build.
Note that dependencies cannot contain snapshot versions that are not part of
the current reactor, but dependencyManagement can. I suggest to forbid this
too.
A second suggestion is to introduce a parameter to control the updating of
snapshot dependencies in both dependencyManagement and dependencies sections.
Either leave them at the released version or update them to the new
development version. This touches on the discussion in MRELEASE-36 about the
developer having to knowingly choose to use a new development version. I
would be fine with using a parameter to select the behavior as obtained with
my patch. My central point is that dependencyManagement and dependencies
snapshots should behave the same.

--
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: (MRELEASE-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

CLONE -Updating of dependencyManagement inconsistent with updating of 
dependencies with regard to SNAPSHOTs
---

 Key: MRELEASE-565
 URL: http://jira.codehaus.org/browse/MRELEASE-565
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
 Environment: maven 2.0.4, win XP
Reporter: Carlo de Wolf
Assignee: Emmanuel Venisse
 Fix For: 2.0-beta-5


The mechanism in release:prepare for creating the new development version of 
POM's handles snapshots that are part of the current reactor build differently 
for dependencyManagement and for dependencies.

A snapshot version in a dependencies section will be updated to the next 
development version whereas one in dependencyManagement won't.

The attached patch will change this behavior. It will update a snapshot version 
under dependencyManagement if and only if it is part of the current reactor 
build.

Note that dependencies cannot contain snapshot versions that are not part of 
the current reactor, but dependencyManagement can. I suggest to forbid this too.

A second suggestion is to introduce a parameter to control the updating of 
snapshot dependencies in both dependencyManagement and dependencies sections. 
Either leave them at the released version or update them to the new development 
version. This touches on the discussion in MRELEASE-36 about the developer 
having to knowingly choose to use a new development version. I would be fine 
with using a parameter to select the behavior as obtained with my patch. My 
central point is that dependencyManagement and dependencies snapshots should 
behave the same.

-- 
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: (MRELEASE-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

[
http://jira.codehaus.org/browse/MRELEASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222840#action_222840
]

Carlo de Wolf commented on MRELEASE-565:

I'm going to remove the bom-eap5-0.1.2 tag, but I'll keep the MRELEASE-91
branch alive for review:
http://github.com/wolfc/jboss-ejb3-bom-eap5/commits/MRELEASE-91

CLONE -Updating of dependencyManagement inconsistent with updating of
dependencies with regard to SNAPSHOTs
---

[jira] Commented: (MRELEASE-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

[
http://jira.codehaus.org/browse/MRELEASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222839#action_222839
]

Carlo de Wolf commented on MRELEASE-565:

I tried it using release plugin 2.0, still snapshots are unresolved.
See
http://github.com/wolfc/jboss-ejb3-bom-eap5/blob/a424f5a8918764b6484874e3697c2743301f0391/pom.xml

CLONE -Updating of dependencyManagement inconsistent with updating of
dependencies with regard to SNAPSHOTs
---

[jira] Issue Comment Edited: (MRELEASE-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

[
http://jira.codehaus.org/browse/MRELEASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222838#action_222838
]

Carlo de Wolf edited comment on MRELEASE-565 at 5/27/10 7:38 AM:
-

Oi, where did the edit button go?

was (Author: wolfc):
Oi, where is did the edit button go?

CLONE -Updating of dependencyManagement inconsistent with updating of
dependencies with regard to SNAPSHOTs
---

[jira] Moved: (MDEP-264) Dependency is copied from original source directory instead of .m2 using maven 3


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

Benjamin Bentmann moved MNG-4689 to MDEP-264:
-

   Complexity:   (was: Intermediate)
  Component/s: (was: Dependencies)
   copy
Affects Version/s: (was: 3.0-beta-1)
   2.1
  Key: MDEP-264  (was: MNG-4689)
  Project: Maven 2.x Dependency Plugin  (was: Maven 2  3)

 Dependency is copied from original source directory instead of .m2 using 
 maven 3
 

 Key: MDEP-264
 URL: http://jira.codehaus.org/browse/MDEP-264
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.1
 Environment: SUSE 9 Linux, OpenJDK 1.6.0 build 11.0-b17, Maven 
 3.0-beta-1
Reporter: Jake Zuidema
 Attachments: mavenDepsCopyExample.tar


 Using Maven 2.2.1, the maven-dependency-plugin copy goal always copied the 
 artifacts from the local .m2, which meant that they kept their full name (ex: 
 ccad-moda-1.0.0-SNAPSHOT-system-help.pdf).  Using Maven 3.0-beta-1, this is 
 no longer always the case.  If I build just the assembly sub-module, then it 
 copies the artifact from the local .m2 and maintains the name.  If I build 
 the whole project, which includes building the module that produces the 
 artifact being copied, then Maven 3 skips going to the local .m2 and instead 
 goes back to the original source of the artifact and copies it from there.  
 This results in a copied file with the short name (ex: system-help.pdf).
 Here are some lines from the build logs to show the difference.
 Maven 2.2.1
 ===
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [DEBUG] Skipping disabled repository central
 [DEBUG] ccad-moda: using locally installed snapshot
 [INFO] Copying 
 /home/jzuidema/.m2/repository/com/ccadllc/test1/ccad-moda/1.0.0-SNAPSHOT/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
  to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
 Maven 3.0-beta-1
 
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [INFO] Copying /extra1/export/home/jzuidema/tmp2/test1/moda/system-help.pdf 
 to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/system-help.pdf
 Attached is an example project with the build logs from a maven 2.2.1 and a 
 3.0-beta-1 run of mvn -X clean install at the top level of the project.

-- 
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-264) Dependency is copied from original source directory instead of .m2 using maven 3


[ 
http://jira.codehaus.org/browse/MDEP-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222843#action_222843
 ] 

Benjamin Bentmann commented on MDEP-264:


The retrieval of the artifact from the reactor instead of the local repository 
is a long wanted fix for Maven. The issue boils down to {{DependencyUtil. 
getFormattedFileName()}} which makes wrong assumptions about the artifact file 
name.

 Dependency is copied from original source directory instead of .m2 using 
 maven 3
 

 Key: MDEP-264
 URL: http://jira.codehaus.org/browse/MDEP-264
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.1
 Environment: SUSE 9 Linux, OpenJDK 1.6.0 build 11.0-b17, Maven 
 3.0-beta-1
Reporter: Jake Zuidema
 Attachments: mavenDepsCopyExample.tar


 Using Maven 2.2.1, the maven-dependency-plugin copy goal always copied the 
 artifacts from the local .m2, which meant that they kept their full name (ex: 
 ccad-moda-1.0.0-SNAPSHOT-system-help.pdf).  Using Maven 3.0-beta-1, this is 
 no longer always the case.  If I build just the assembly sub-module, then it 
 copies the artifact from the local .m2 and maintains the name.  If I build 
 the whole project, which includes building the module that produces the 
 artifact being copied, then Maven 3 skips going to the local .m2 and instead 
 goes back to the original source of the artifact and copies it from there.  
 This results in a copied file with the short name (ex: system-help.pdf).
 Here are some lines from the build logs to show the difference.
 Maven 2.2.1
 ===
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [DEBUG] Skipping disabled repository central
 [DEBUG] ccad-moda: using locally installed snapshot
 [INFO] Copying 
 /home/jzuidema/.m2/repository/com/ccadllc/test1/ccad-moda/1.0.0-SNAPSHOT/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
  to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
 Maven 3.0-beta-1
 
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [INFO] Copying /extra1/export/home/jzuidema/tmp2/test1/moda/system-help.pdf 
 to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/system-help.pdf
 Attached is an example project with the build logs from a maven 2.2.1 and a 
 3.0-beta-1 run of mvn -X clean install at the top level of the project.

-- 
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: (MDOCCK-19) Mark plugin as @threadSafe

Mark plugin as @threadSafe
--

 Key: MDOCCK-19
 URL: http://jira.codehaus.org/browse/MDOCCK-19
 Project: Maven 2.x Documentation Checker Plugin
  Issue Type: Improvement
Reporter: Kristian Rosenvold


Code review indicates that this plugin can be marked as threadSafe

-- 
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: (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe

Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
---

 Key: MCHECKSTYLE-138
 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-138
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Improvement
Reporter: Kristian Rosenvold


The checkstyle plugin can be marked as threadSafe if checkstyle itself can be 
verified to be thread safe.

Someone should ask the checkstyle community if this is the 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] Closed: (MGPG-17) password is specified, but still promting


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

Benjamin Bentmann closed MGPG-17.
-

   Resolution: Fixed
Fix Version/s: 1.1
 Assignee: Benjamin Bentmann

Fixed in [r948928|http://svn.apache.org/viewvc?view=revisionrevision=948928].

 password is specified, but still promting
 -

 Key: MGPG-17
 URL: http://jira.codehaus.org/browse/MGPG-17
 Project: Maven 2.x GPG Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-4
 Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 08:04:01-0500)
 Java version: 1.6.0_15
 Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.27.29-0.1-default arch: i386 Family: unix
 gpg (GnuPG) 2.0.9
 on OpenSUSE 11.1
Reporter: Albert Kurucz
Assignee: Benjamin Bentmann
 Fix For: 1.1


 Using
 mvn verify -Dgpg.passphrase=thephrase
 with thephrase replaced with the real one.
 When it get to signing, it still promts.
 It is critical, because this prompt repeats with all the 100 modules of the 
 project.
 Problem maybe related to updates/changes of gpg software.
 Related warning message:
 gpg: WARNING: --no-use-agent is an obsolete option - it has no effect
 can't connect to `/home/albert_kurucz/.gnupg/S.gpg-agent': No such file or 
 directory

-- 
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-481) Deploy site:deploy not working for maven 3 for DAV

2010-05-27 Thread Eric Berry (JIRA)

Deploy site:deploy not working for maven 3 for DAV
--

 Key: MSITE-481
 URL: http://jira.codehaus.org/browse/MSITE-481
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0-alpha-1
 Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven 
3.0.0-beta-1 (snapshot version from 5/3).
Reporter: Eric Berry


Sorry if this is not where this goes.

I include this in my pom
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-webdav-jackrabbit/artifactId
version1.0-beta-6/version
/extension
/extensions
There seems to be a conflict between this extension and
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-project-info-reports-plugin/artifactId
version2.2/version
I get an error saying that there are two versions of 
org.apache.commons.logging.LogFactory in the ClassLoader.


I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude 
commons-logging from its dependencies and specified a dependency on 
commons-logging-1.1.1.  So that is problem number 1.


At that point when I tried to deploy my site, I get this error:
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer 
file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css. 
Return code is: 401

My site distribtion management setting is:
site
idsweng-projects/id

urldav+https://${webdavserver.hostname}/config/${product-sites.version}/url
/site
My server setting in settings.xml is (actual values replaced with ***):
server
idsweng-projects/id
username/username
password/password
/server
Problem number 2 is that site:deploy does not seem to using the 
username/password info from settings.xml.

-- 
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: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs


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

Benjamin Bentmann closed MGPG-9.


Resolution: Not A Bug
  Assignee: Benjamin Bentmann

While surely annoying, this is not an issue in the GPG Plugin itself but the 
Release Plugin. For the time being, I added some documentation to the GPG 
Plugin that points out a workaround.

 gpg plugin hangs when it should prompt for the secret key passphrase hangs
 --

 Key: MGPG-9
 URL: http://jira.codehaus.org/browse/MGPG-9
 Project: Maven 2.x GPG Plugin
  Issue Type: Bug
 Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x
Reporter: Alex Karasulu
Assignee: Benjamin Bentmann

 When used in conjunction with the release plugin the release:perform command 
 hangs when it should prompt for the secret key passphrase.  Interestingly 
 enough when I put the passphrase into the settings.xml file the plugin does 
 not hang.  I suspect the prompt is failing to show up.

-- 
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: (MGPG-20) Error with classifiers


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

Benjamin Bentmann closed MGPG-20.
-

Resolution: Incomplete
  Assignee: Benjamin Bentmann

We use the plugin on a regular basis to sign the source and javadoc artifacts 
without issues and the few information provided isn't sufficient for an 
analysis. So please reopen with a demo project that reproduces the issue.

 Error with classifiers
 --

 Key: MGPG-20
 URL: http://jira.codehaus.org/browse/MGPG-20
 Project: Maven 2.x GPG Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: clement escoffier
Assignee: Benjamin Bentmann

 I've a project creating two artifacts with different classifiers. 
 When I try to sign them, I get :
 gpg: .../target/classes: read error: Is a directory
 Here is the stack trace in verbose mode:
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Exit code: 2
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   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:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Exit code: 2
   at 
 org.apache.maven.plugin.gpg.GpgSigner.generateSignatureForArtifact(GpgSigner.java:179)
   at 
 org.apache.maven.plugin.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMojo.java:228)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   ... 17 more
 If I change the configuration to generate only one artifact, it works (and 
 the artifacts are signed).

-- 
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: (MGPG-19) Site descriptor does not get signed


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

Benjamin Bentmann closed MGPG-19.
-

Resolution: Won't Fix
  Assignee: Benjamin Bentmann

Out of scope for the GPG Plugin itself, added a FAQ mentioning the requirement 
to update the Site Plugin instead.

 Site descriptor does not get signed
 ---

 Key: MGPG-19
 URL: http://jira.codehaus.org/browse/MGPG-19
 Project: Maven 2.x GPG Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: Stephen Connolly
Assignee: Benjamin Bentmann
Priority: Blocker

 When the site descriptor is an attached artifact, the GPG signature is not 
 generated.
 Steps to reproduce:
 svn co 
 https://svn.apache.org/repos/asf/maven/surefire/tags/surefire-...@898285 
 surefire-2.5
 cd surefire-2.5
 mvn site:attach-descriptor gpg:sign -Papache-release -N
 ls target/*.asc
 if there is a surefire-2.5-site.xml.asc then this bug is fixed.

-- 
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: (MGPG-23) Allow gpg executable name and path to be specified


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

Benjamin Bentmann closed MGPG-23.
-

   Resolution: Fixed
Fix Version/s: 1.1
 Assignee: Benjamin Bentmann

Added new parameter executable in 
[r948951|http://svn.apache.org/viewvc?view=revisionrevision=948951].

 Allow gpg executable name and path to be specified
 --

 Key: MGPG-23
 URL: http://jira.codehaus.org/browse/MGPG-23
 Project: Maven 2.x GPG Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: SebbASF
Assignee: Benjamin Bentmann
 Fix For: 1.1


 It would be useful to be able to specify the gpg executable name via a 
 property.
 It would also sometimes be useful to be able to specify the full path to the 
 executable.

-- 
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: (MSHARED-155) Update to Doxia 1.1.3

Update to Doxia 1.1.3
-

 Key: MSHARED-155
 URL: http://jira.codehaus.org/browse/MSHARED-155
 Project: Maven Shared Components
  Issue Type: Task
  Components: maven-doxia-tools
Affects Versions: maven-doxia-tools 1.2
Reporter: Dennis Lundberg




-- 
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: (MSHARED-155) Update to Doxia 1.1.3


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

Dennis Lundberg closed MSHARED-155.
---

   Resolution: Fixed
Fix Version/s: maven-doxia-tools 1.2.1
 Assignee: Dennis Lundberg

 Update to Doxia 1.1.3
 -

 Key: MSHARED-155
 URL: http://jira.codehaus.org/browse/MSHARED-155
 Project: Maven Shared Components
  Issue Type: Task
  Components: maven-doxia-tools
Affects Versions: maven-doxia-tools 1.2
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
 Fix For: maven-doxia-tools 1.2.1




-- 
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: (MWAR-226) Make war plugin @threadSafe

Make war plugin @threadSafe
---

 Key: MWAR-226
 URL: http://jira.codehaus.org/browse/MWAR-226
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
Affects Versions: 2.1-beta-1
Reporter: Kristian Rosenvold


Upgrade libraries and fix static singleton within overlays, and this plugin 
should be @threadSafe.

-- 
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: (MWAR-226) Make war plugin @threadSafe


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

Kristian Rosenvold closed MWAR-226.
---

   Resolution: Fixed
Fix Version/s: 2.1-beta-2
 Assignee: Kristian Rosenvold

Fixed in r948982


 Make war plugin @threadSafe
 ---

 Key: MWAR-226
 URL: http://jira.codehaus.org/browse/MWAR-226
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
Affects Versions: 2.1-beta-1
Reporter: Kristian Rosenvold
Assignee: Kristian Rosenvold
 Fix For: 2.1-beta-2


 Upgrade libraries and fix static singleton within overlays, and this plugin 
 should be @threadSafe.

-- 
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: (MSITE-481) Deploy site:deploy not working for maven 3 for DAV

2010-05-27 Thread Eric Berry (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222902#action_222902
 ] 

Eric Berry commented on MSITE-481:
--

Problem 1 goes away if I make the weddav wagon a dependency of the site plugin 
instead of an extension.

 Deploy site:deploy not working for maven 3 for DAV
 --

 Key: MSITE-481
 URL: http://jira.codehaus.org/browse/MSITE-481
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0-alpha-1
 Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven 
 3.0.0-beta-1 (snapshot version from 5/3).
Reporter: Eric Berry

 Sorry if this is not where this goes.
 I include this in my pom
   extensions
   extension
   groupIdorg.apache.maven.wagon/groupId
   artifactIdwagon-webdav-jackrabbit/artifactId
   version1.0-beta-6/version
   /extension
   /extensions
 There seems to be a conflict between this extension and
   reporting
   plugins
   plugin
   groupIdorg.apache.maven.plugins/groupId
   
 artifactIdmaven-project-info-reports-plugin/artifactId
   version2.2/version
 I get an error saying that there are two versions of 
 org.apache.commons.logging.LogFactory in the ClassLoader.
 I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude 
 commons-logging from its dependencies and specified a dependency on 
 commons-logging-1.1.1.  So that is problem number 1.
 At that point when I tried to deploy my site, I get this error:
 Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer 
 file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css. 
 Return code is: 401
 My site distribtion management setting is:
   site
   idsweng-projects/id
   
 urldav+https://${webdavserver.hostname}/config/${product-sites.version}/url
   /site
 My server setting in settings.xml is (actual values replaced with ***):
   server
   idsweng-projects/id
   username/username
   password/password
   /server
 Problem number 2 is that site:deploy does not seem to using the 
 username/password info from settings.xml.

-- 
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: (DOXIA-393) Unable to deploy site for doxia-module-fml

Unable to deploy site for doxia-module-fml
--

 Key: DOXIA-393
 URL: http://jira.codehaus.org/browse/DOXIA-393
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Fml
Affects Versions: 1.1.3
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.5.0_22
Java home: C:\Program\Java\jdk1.5.0_22\jre
Default locale: sv_SE, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Dennis Lundberg


When trying to deploy the site for version 1.1.3  I get the following failure 
in the FML module. It seems to have something to do with xssdoc

{noformat}
[INFO] Generating Surefire Report report.
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason

[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException 
has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
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: An Ant 
BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at org.apache.tools.ant.taskdefs.Mkdir.execute(Mkdir.java:64)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)

[jira] Updated: (DOXIA-393) Unable to deploy site for doxia-module-fml


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

Dennis Lundberg updated DOXIA-393:
--

Description: 
When trying to deploy the site for version 1.1.3  I get the following failure 
in the FML module. It seems to have something to do with xsddoc.

Command line is:
mvn site-deploy -Preporting -e

{noformat}
[INFO] Generating Surefire Report report.
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason

[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException 
has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
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: An Ant 
BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at org.apache.tools.ant.taskdefs.Mkdir.execute(Mkdir.java:64)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
... 20 more
{noformat}

  was:
When trying to deploy the site for version 1.1.3  I get the following failure 
in the FML module. It seems to have something to do with

[jira] Updated: (DOXIA-393) Unable to deploy site for fml and xdoc modules


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

Dennis Lundberg updated DOXIA-393:
--

Component/s: Module - Xdoc
Description: 
When trying to deploy the site for version 1.1.3  I get the following failure 
in the FML and XDoc modules. It seems to have something to do with xsddoc.

Command line is:
mvn site-deploy -Preporting -e

{noformat}
[INFO] Generating Surefire Report report.
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason

[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException 
has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
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: An Ant 
BuildException has occured: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: Directory 
G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
 creation was not successful for an unknown reason
at org.apache.tools.ant.taskdefs.Mkdir.execute(Mkdir.java:64)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
... 20 more
{noformat}

The report for XDoc module

{noformat}
[INFO] Generating Surefire Report report.
[INFO] [antrun:run

[jira] Commented: (MSITE-481) Deploy site:deploy not working for maven 3 for DAV

2010-05-27 Thread Eric Berry (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222907#action_222907
 ] 

Eric Berry commented on MSITE-481:
--

Its caused by the FIXME on line 207 of SiteDeployMojo.  Uncommenting the FIXME 
and removing the following wagon.connect fixed my problem.  So whatever the 
reason for the original FIXME seems to be working in non-proxy mode.

 Deploy site:deploy not working for maven 3 for DAV
 --

 Key: MSITE-481
 URL: http://jira.codehaus.org/browse/MSITE-481
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0-alpha-1
 Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven 
 3.0.0-beta-1 (snapshot version from 5/3).
Reporter: Eric Berry

 Sorry if this is not where this goes.
 I include this in my pom
   extensions
   extension
   groupIdorg.apache.maven.wagon/groupId
   artifactIdwagon-webdav-jackrabbit/artifactId
   version1.0-beta-6/version
   /extension
   /extensions
 There seems to be a conflict between this extension and
   reporting
   plugins
   plugin
   groupIdorg.apache.maven.plugins/groupId
   
 artifactIdmaven-project-info-reports-plugin/artifactId
   version2.2/version
 I get an error saying that there are two versions of 
 org.apache.commons.logging.LogFactory in the ClassLoader.
 I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude 
 commons-logging from its dependencies and specified a dependency on 
 commons-logging-1.1.1.  So that is problem number 1.
 At that point when I tried to deploy my site, I get this error:
 Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer 
 file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css. 
 Return code is: 401
 My site distribtion management setting is:
   site
   idsweng-projects/id
   
 urldav+https://${webdavserver.hostname}/config/${product-sites.version}/url
   /site
 My server setting in settings.xml is (actual values replaced with ***):
   server
   idsweng-projects/id
   username/username
   password/password
   /server
 Problem number 2 is that site:deploy does not seem to using the 
 username/password info from settings.xml.

-- 
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-482) Update to Doxia 1.1.3

Update to Doxia 1.1.3
-

 Key: MSITE-482
 URL: http://jira.codehaus.org/browse/MSITE-482
 Project: Maven 2.x Site Plugin
  Issue Type: Task
Affects Versions: 2.1
Reporter: Dennis Lundberg




-- 
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-482) Update to Doxia 1.1.3


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

Dennis Lundberg closed MSITE-482.
-

   Resolution: Fixed
Fix Version/s: 2.1.1
 Assignee: Dennis Lundberg

 Update to Doxia 1.1.3
 -

 Key: MSITE-482
 URL: http://jira.codehaus.org/browse/MSITE-482
 Project: Maven 2.x Site Plugin
  Issue Type: Task
Affects Versions: 2.1
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
 Fix For: 2.1.1




-- 
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: (MSITE-482) Update to Doxia 1.1.3

2010-05-27 Thread Olivier Lamy (JIRA)


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

Olivier Lamy updated MSITE-482:
---

Fix Version/s: 3.0-alpha-1

 Update to Doxia 1.1.3
 -

 Key: MSITE-482
 URL: http://jira.codehaus.org/browse/MSITE-482
 Project: Maven 2.x Site Plugin
  Issue Type: Task
Affects Versions: 2.1
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
 Fix For: 2.1.1, 3.0-alpha-1




-- 
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: (MRELEASE-566) prepare goal fails if localRepoDirectory doesn't exist, should instead create it

2010-05-27 Thread luke w patterson (JIRA)

prepare goal fails if localRepoDirectory doesn't exist, should instead create 
it
--

 Key: MRELEASE-566
 URL: http://jira.codehaus.org/browse/MRELEASE-566
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Reporter: luke w patterson
 Attachments: maven-release-plugin-local-repo.patch

(patch attached, no testcase but it is fairly straightforward)

if the directory listed in the localRepoDirectory [1] parameter of 
release:prepare doesn't exist, the build fails

e.g. if I set {code} 
localRepoDirectory${project.build.directory}\local-repo-during-release/localRepoDirectory
 {code}

I get error:

{code}
java.lang.IllegalArgumentException: Local repository location: 
'blah\target\local-repo-during-release' is NOT a directory.
at 
org.apache.maven.shared.invoker.MavenCommandLineBuilder.setEnvironmentPaths(MavenCommandLineBuilder.java:359)
at 
org.apache.maven.shared.invoker.MavenCommandLineBuilder.build(MavenCommandLineBuilder.java:90)
at 
org.apache.maven.shared.invoker.DefaultInvoker.execute(DefaultInvoker.java:91)
at 
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:387)
at 
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:413)
at 
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:82)
at 
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
at 
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.simulate(RunPrepareGoalsPhase.java:54)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
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(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: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)
{code}

Ideally, one could avoid the null check in the patch, but then a lot of tests 
would have to be updated, and I wasn't sure if it was worth it.


Thanks


[1] 
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#localRepoDirectory

-- 
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: (MDEP-264) Dependency is copied from original source directory instead of .m2 using maven 3


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

Brian Fox closed MDEP-264.
--

   Resolution: Fixed
Fix Version/s: 2.2

The file name is always reconstructed now. The potential downside to this is 
that timestamped snapshot versions won't be copied anymore, it will use 
SNAPSHOT instead of the timestamp.

 Dependency is copied from original source directory instead of .m2 using 
 maven 3
 

 Key: MDEP-264
 URL: http://jira.codehaus.org/browse/MDEP-264
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.1
 Environment: SUSE 9 Linux, OpenJDK 1.6.0 build 11.0-b17, Maven 
 3.0-beta-1
Reporter: Jake Zuidema
 Fix For: 2.2

 Attachments: mavenDepsCopyExample.tar


 Using Maven 2.2.1, the maven-dependency-plugin copy goal always copied the 
 artifacts from the local .m2, which meant that they kept their full name (ex: 
 ccad-moda-1.0.0-SNAPSHOT-system-help.pdf).  Using Maven 3.0-beta-1, this is 
 no longer always the case.  If I build just the assembly sub-module, then it 
 copies the artifact from the local .m2 and maintains the name.  If I build 
 the whole project, which includes building the module that produces the 
 artifact being copied, then Maven 3 skips going to the local .m2 and instead 
 goes back to the original source of the artifact and copies it from there.  
 This results in a copied file with the short name (ex: system-help.pdf).
 Here are some lines from the build logs to show the difference.
 Maven 2.2.1
 ===
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [DEBUG] Skipping disabled repository central
 [DEBUG] ccad-moda: using locally installed snapshot
 [INFO] Copying 
 /home/jzuidema/.m2/repository/com/ccadllc/test1/ccad-moda/1.0.0-SNAPSHOT/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
  to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf
 Maven 3.0-beta-1
 
 [INFO] Configured Artifact: 
 com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf
 [INFO] Copying /extra1/export/home/jzuidema/tmp2/test1/moda/system-help.pdf 
 to 
 /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/system-help.pdf
 Attached is an example project with the build logs from a maven 2.2.1 and a 
 3.0-beta-1 run of mvn -X clean install at the top level of the project.

-- 
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: (MDEP-257) includeClassifiers / seems to have no effect


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

Brian Fox closed MDEP-257.
--

Resolution: Duplicate

MDEP-193

 includeClassifiers / seems to have no effect
 --

 Key: MDEP-257
 URL: http://jira.codehaus.org/browse/MDEP-257
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: unpack-dependencies
Affects Versions: 2.1
 Environment: Windows XP
Reporter: Patrick Aikens
Assignee: Brian Fox

 I'm trying to package some installer-related files from a project for use in 
 a different izpack installer project.  I want to unpack them into the 
 target/staging directory for inclusion in the izpack installer.  All of the 
 dependencies I want to unpack have a classifier of izpack.  Using the 
 following configuration, the dependency plugin unpacks ALL dependencies, not 
 just the ones with an izpack classifier.
 {code:xml}
 plugin
   artifactIdmaven-dependency-plugin/artifactId
   version2.1/version
   executions
 execution
   idizpack/id
   phasegenerate-resources/phase
   goals
 goalunpack-dependencies/goal
   /goals
   configuration
 outputDirectory${project.build.directory}/staging/outputDirectory
 includeClassifiersizpack/includeClassifiers
   /configuration
 /execution
   /executions
 /plugin
 {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] Commented: (MDEP-213) resolve dependencyManagement section with option to fail the build


[ 
http://jira.codehaus.org/browse/MDEP-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222925#action_222925
 ] 

Brian Fox commented on MDEP-213:


So you want to resolve everything in depMgt to make sure the versions exist?

 resolve dependencyManagement section with option to fail the build
 --

 Key: MDEP-213
 URL: http://jira.codehaus.org/browse/MDEP-213
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
  Components: resolve
Affects Versions: 2.0
Reporter: Jim Sellers
Assignee: Brian Fox

 When using the dependencyManagement section of a pom of type pom to create 
 a bill of materials, it's currently possible to specify an invalid version.  
 eg:
 {code:xml}
   dependencyManagement
   dependencies
   dependency
   groupIdcommons-logging/groupId
   artifactIdcommons-logging/artifactId
   version9.9/version
   /dependency
   /dependencies
   /dependencyManagement
 {code} 
 It would be really useful for these types of pom's to be able to force all 
 the dependencies to be resolved when running something like install and 
 have that fail the build.

-- 
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: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.

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

Brian Fox closed MDEP-208.
--

Resolution: Fixed
Fix Version/s: 2.2

fixed by MDEP-264

finalName of artifacts not in the reactor is not taken into account.

Key: MDEP-208
URL: http://jira.codehaus.org/browse/MDEP-208
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies, unpack-dependencies
Affects Versions: 2.0
Reporter: Maarten Billemont
Assignee: Brian Fox
Fix For: 2.2

Setting:
A project where module B has a dependency on module A.
Module B uses copy-dependencies to copy that dependency into a certain
directory.
What works:
When both module A and B are in the maven reactor, module A's finalName is
taken into account and the artifact that ends up copied into our directory
uses the filename as given by finalName.
What doesn't work:
When only module B is in the maven reactor, module A is copied from the local
repository where it has a different filename. Maven-dependency-plugin does
not correct the filename during copy and as a result we have an artifact in
our destination directory with a different name.
This behavior is inconsistent and a solution should be established. I
propose maven-dependency-plugin reads the dependency (A)'s POM and checks
whether it has a finalName set. If so, it should modify the destination
filename of the dependency copy operation accordingly.

[jira] Closed: (MDEP-240) ignoreNonCompile not available for analyze-report


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

Brian Fox closed MDEP-240.
--

   Resolution: Fixed
Fix Version/s: 2.2

 ignoreNonCompile not available for analyze-report
 -

 Key: MDEP-240
 URL: http://jira.codehaus.org/browse/MDEP-240
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: analyze
Affects Versions: 2.1
Reporter: Pablo
Assignee: Brian Fox
 Fix For: 2.2


 I'd like to use the property ignoreNonCompile=true for my site report, but 
 the goal analyze-report doesn't have this property.
 The doc is pretty clear about it, but I don't see any reason of not having 
 this option for reports too.
 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile
 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-report-mojo.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] Moved: (MNG-4690) Transitive dependency lost when included another dependency


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

Brian Fox moved MDEP-202 to MNG-4690:
-

   Complexity: Intermediate
  Component/s: (was: resolve)
   Dependencies
Affects Version/s: (was: 2.1)
  Key: MNG-4690  (was: MDEP-202)
  Project: Maven 2  3  (was: Maven 2.x Dependency Plugin)

 Transitive dependency lost when included another dependency
 ---

 Key: MNG-4690
 URL: http://jira.codehaus.org/browse/MNG-4690
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
 Environment: maven 2.0.10 (tried with dependency plugin 2.0 and 2.1)
Reporter: Michal Ropka
Assignee: Brian Fox
 Attachments: test.zip


 *We added a new dependency (_velocity-tools_) and the project didn't work any 
 more. We've found that one transitive library (_antlr_ used by _struts_ and 
 _hibernate_) is missing in the installed WAR file.*
 It looks like the _antlr_ transitive dependency is ignored from _hibernate_ 
 dependencies by plugin choosing _struts-1.2.9_ one while eventually _struts_ 
 is replaced by _1.2.7_ version which does not have _antlr_ dependency.
 There is a workaround to the problem - dependencies might be rearranged to 
 include the missing library back (e.g. by moving _struts-1.2.7_ from _parent_ 
 to _ui_ but only before _velocity-tools_ - see the test case) however the 
 problem is that the plugin behavior is unpredictable.
 *Test case:*
 There are root, parent, common, model, ui POM files. The purpose is to create 
 dependency tree deep enough (_ui_ depends on _model_ and inherits from 
 _parent_, _model_ depends on _common_). They include external dependencies 
 (_velocity-tools_, _struts_, _hibernate_).
 * WAR artifact created from the root or _ui_ POM does not contain _antlr_ in 
 WEB-INF/lib which is required by _hibernate_
 * after removing _velocity-tools_ from ui/pom.xml _antlr_ library is included 
 properly

-- 
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: (MDEP-263) filtering by classifier don't work


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

Brian Fox closed MDEP-263.
--

   Resolution: Fixed
Fix Version/s: 2.2

fixed by MDEP-194

 filtering by classifier don't work
 --

 Key: MDEP-263
 URL: http://jira.codehaus.org/browse/MDEP-263
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy, copy-dependencies
Affects Versions: 2.1
 Environment: windows jdk1.6.0, maven 2.0.9
Reporter: Robert Lieb
Assignee: Brian Fox
 Fix For: 2.2


 Following plugin configuration ist used
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-dependency-plugin/artifactId
   executions
   execution
   idcopy/id
   phasepackage/phase
   goals
   goalcopy-dependencies/goal
   /goals
   configuration
   
 outputDirectory${project.build.directory}/dependency/WEB-INF/lib/outputDirectory
   excludeClassifiersweb/excludeClassifiers
   /configuration
   /execution
   execution
   idunpack/id
   phasepackage/phase
   goals
   goalunpack-dependencies/goal
   /goals
   configuration
   includeClassifiersweb/includeClassifiers
   /configuration
   /execution
   /executions
 /plugin
 but in both executions all dependencies are copied, regardless of there 
 classifiers

-- 
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: (MDEP-182) Add exclude*, parameters to copy mojo (analogous to copy-dependencies mojo)


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

Brian Fox closed MDEP-182.
--

Resolution: Won't Fix

Use the -dependencies goals for transitive resolution. The copy/unpack goals 
are meant exactly to pick up just one file.

 Add exclude*,  parameters to copy mojo (analogous to copy-dependencies mojo)
 

 Key: MDEP-182
 URL: http://jira.codehaus.org/browse/MDEP-182
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
  Components: copy
Affects Versions: 2.1
Reporter: Thorsten Möller
Assignee: Brian Fox

 Today I came around a use case that I miss in the copy goal/mojo of the 
 dependency plugin. Currently, it is not possible (at least I could not find 
 any documentation) to resolve transitive dependencies when copying an 
 artifact nor to specify whether transitive dependencies should be included or 
 excluded. This should be extended analogous to the copy-dependencies mojo.
 Example: Say we want to copy Retrotranslator including its dependencies. 
 Currently we would have to use the following declarations
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-dependency-plugin/artifactId
   executions
   execution
   idcopy/id
   phasepackage/phase
   goals
   goalcopy/goal
   /goals
   configuration
   artifactItems
   artifactItem
   
 groupIdnet.sf.retrotranslator/groupId
   
 artifactIdretrotranslator-runtime/artifactId
   
 version${retrotranslator-version}/version
   typejar/type
   
 outputDirectory${project.build.directory}/outputDirectory
   /artifactItem
   !-- Transitive dependency of 
 Retrotranslator. Unfortunately, not automatically included. --
   artifactItem
   
 groupIdbackport-util-concurrent/groupId
   
 artifactIdbackport-util-concurrent/artifactId
   version3.1/version
   typejar/type
   
 outputDirectory${project.build.directory}/outputDirectory
   /artifactItem
   /artifactItems
   /configuration
   /execution
   /executions
 /plugin
 This has the downside that all dependencies must be explicitly listed and 
 artifact versions must be kept consistent, which is unwished maintenance 
 work. More convenient would be a declaration as follows
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-dependency-plugin/artifactId
   executions
   execution
   idcopy/id
   phasepackage/phase
   goals
   goalcopy/goal
   /goals
   configuration
   artifactItems
   artifactItem
   
 groupIdnet.sf.retrotranslator/groupId
   
 artifactIdretrotranslator-runtime/artifactId
   
 version${retrotranslator-version}/version
   typejar/type
   
 outputDirectory${project.build.directory}/outputDirectory
   !-- Force to include *all* 
 transitive dependencies. They should be copied to the same output directory. 
 --
   
 excludeTransitivefalse/excludeTransitive
   /artifactItem
   /artifactItems
   /configuration
   /execution
   /executions
 /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: (MDEP-260) fileSeparator\/fileSeparator causes an exception


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

Brian Fox closed MDEP-260.
--

   Resolution: Fixed
Fix Version/s: 2.2

patch applied, thanks.

 fileSeparator\/fileSeparator causes an exception
 

 Key: MDEP-260
 URL: http://jira.codehaus.org/browse/MDEP-260
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: build-classpath
Affects Versions: 2.1
Reporter: Sergei Ivanov
Assignee: Brian Fox
 Fix For: 2.2

 Attachments: file_separator.patch


 If I specify the following property in the plugin configuration:
 fileSeparator\/fileSeparator
 then the plugin crashes with an exception because a regex parser fails 
 internally.
 It appears that the property needs to be escaped like this:
 fileSeparator\\/fileSeparator
 The plugin should take care of escaping the property itself.

-- 
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: (MDEP-250) Add a skip paramater to dependency:unpack


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

Brian Fox closed MDEP-250.
--

   Resolution: Fixed
Fix Version/s: 2.2

 Add a skip paramater to dependency:unpack
 -

 Key: MDEP-250
 URL: http://jira.codehaus.org/browse/MDEP-250
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: unpack
Affects Versions: 2.1
 Environment: Windows XP
Reporter: Jim McCaskey
Assignee: Brian Fox
 Fix For: 2.2

 Attachments: MDEP-250-patch.txt


 We would like to have a skip paramater for dependency:unpack.  This would 
 cause the unpack to be skipped if true.  We are currently working around the 
 lack of this with profiles.
 The jetspeed plugin has a skip option that we have found some uses for, but 
 jetspeed is not as robust as the dependency plugin (specifically with 
 multi-module builds).  We would prefer to use the core modules anyway.
 Here is a link to the jetspeed configuration page:
 http://portals.apache.org/jetspeed-2/maven/jetspeed-maven-plugins.html#Configuration_and_usage_of_the_jetspeed-unpack:unpack_Maven_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] Moved: (MNG-4691) Partially resolved artifacts in local repo trip up go-offline


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

Brian Fox moved MDEP-247 to MNG-4691:
-

   Complexity: Intermediate
  Component/s: (was: resolve-plugins)
   (was: go-offline)
   (was: resolve)
   (was: copy-dependencies)
   Dependencies
Affects Version/s: (was: 2.1)
  Key: MNG-4691  (was: MDEP-247)
  Project: Maven 2  3  (was: Maven 2.x Dependency Plugin)

 Partially resolved artifacts in local repo trip up go-offline
 -

 Key: MNG-4691
 URL: http://jira.codehaus.org/browse/MNG-4691
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
 Environment: Mac/Linux
Reporter: Lee Thompson
Assignee: Brian Fox

 Sometime ins my local repo, I get an artifact POM downloaded, but not the 
 JAR.  This happens frequently enough that when I do go offline, my 
 development work comes to a halt.
 The latest partial in my local repo is this...
 {code:title=RepoListing|borderStyle=solid}
 $ ls ~/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.1
 plexus-utils-1.4.1.pom  plexus-utils-1.4.1.pom.sha1
 {code}
 Notice the plexus-utils jar file is not in the repo.  The issue is go-offline 
 should detect that the packaged artifact is missing and resolve it, not just 
 the POM

-- 
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: (MDEP-195) dependency resolution fails when modules have inter-dependencies


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

Brian Fox closed MDEP-195.
--

Resolution: Duplicate

 dependency resolution fails when modules have inter-dependencies
 

 Key: MDEP-195
 URL: http://jira.codehaus.org/browse/MDEP-195
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
 Environment: Mac, Maven 2.0.9, Java 1.5
Reporter: Joshua Pollak
 Attachments: demoPom.tgz


 There seems to be problems with dependency resolution at various phases in 
 the maven lifecycle. For example, if I run the following command on the 
 attached project, I get a failure instead of the expected dependency tree:
 jpol...@challenger:~/src/software/projects/demoPom/trunk$ mvn dependency:tree
 [INFO] Scanning for projects...
 [INFO] Reactor build order: 
 [INFO]   Demo Project
 [INFO]   moduleA - Framework Code
 [INFO]   moduleB - Generated Sources
 [INFO]   moduleC - Main Application
 [INFO] Searching repository for plugin with prefix: 'dependency'.
 [INFO] 
 
 [INFO] Building Demo Project
 [INFO]task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree]
 [INFO] com.kiva.demoPom:demoPom:pom:0.0.2-SNAPSHOT
 [INFO] \- junit:junit:jar:3.8.1:test
 [INFO] 
 
 [INFO] Building moduleA - Framework Code
 [INFO]task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree]
 [INFO] com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT
 [INFO] \- junit:junit:jar:3.8.1:test
 [INFO] 
 
 [INFO] Building moduleB - Generated Sources
 [INFO]task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 Missing:
 --
 1) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT
   Try downloading the file manually from the project website.
   Then, install it using the command: 
   mvn install:install-file -DgroupId=com.kiva.demoPom 
 -DartifactId=moduleA -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar 
 -Dfile=/path/to/file
   Alternatively, if you host your own repository you can deploy the file 
 there: 
   mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA 
 -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
 -DrepositoryId=[id]
   Path to dependency: 
   1) com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT
   2) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT
 --
 1 required artifact is missing.
 for artifact: 
   com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT
 from the specified remote repositories:
   central (http://repo1.maven.org/maven2)
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 4 seconds
 [INFO] Finished at: Mon Nov 03 17:00:13 EST 2008
 [INFO] Final Memory: 9M/18M
 [INFO] 
 

-- 
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: (MDEP-188) switch to Mercury 1.0.0-alpha-2