date:20140307


[ 
https://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342545#comment-342545
 ] 

Jörg Hohwiller commented on MNG-2971:
-

There is great news for this issue:
https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin
Please note that the plugin will move out of sandbox in the future so try mojo 
instead of sandbox if the link stopped working:
https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin

Simply check-out and install this plugin. Then add this to your toplevel POMs 
build-section:
plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdconsumer-maven-plugin/artifactId
  version1.0.0-beta-1-SNAPSHOT/version
/plugin

I hope that the plugin will move out of sandbox and be released soon.

If you have any feedback please let us know (ideally on MOJOs dev mailing list).

 Variables are not replaced into installed pom file
 --

 Key: MNG-2971
 URL: https://jira.codehaus.org/browse/MNG-2971
 Project: Maven 2  3
  Issue Type: Bug
  Components: Deployment, Inheritance and Interpolation
 Environment: Windows, Solaris
 Maven version 2.0.4
Reporter: Laurent Dauvilaire
Assignee: Ralph Goers
 Fix For: Issues to be reviewed for 3.x

 Attachments: pom.xml


 Variables are not replaced into installed pom file.
 Here is a sample pom file
 project xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdcom.xxx.root/groupId
   artifactIdroot/artifactId
   packagingpom/packaging
   version${prop.version}/version
   nameMy Project/name
 ...
   properties
   prop.version3.0.20/prop.version
   /properties
 /project
 The installed pom is into 
 ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
 is the same as the project pom file but the version referenced into the 
 installed pom file is ${prop.version} instead of 3.0.20
 which creates problem to artifacts depending of this one.
 Thanks in advance



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342546#comment-342546
]

Jason van Zyl commented on MNG-5435:

I didn't quite look carefully enough at the snippet in the book. What matters
is that all the repostiory ids match up. We should consider the URL only but we
don't. This is the settings.xml template that I use:

https://gist.github.com/jvanzyl/9411574

Notice that everything uses id = central

Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---

Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip

[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact


[ 
https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342557#comment-342557
 ] 

Jason van Zyl commented on MNG-5255:


This appears to be a problem with the WAR plugin, if I setup a project using 
these dependencies and set them to provided and resolve with runtime scope the 
provided dependencies do not show up:

https://github.com/takari/maven-bugs/tree/master/project-mng5273

This is not a Maven core problem. If I were to make a new WAR plugin using the 
logic of the plugin defined in the POM of the bug project I would not see 
provided artifacts in the final WAR.

 Dependency with 'provided' scope has its transitive dependency included in 
 final artifact
 -

 Key: MNG-5255
 URL: https://jira.codehaus.org/browse/MNG-5255
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: D:\bin\apache-maven-3.0.4
 Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
 Java home: D:\bin\java\jdk1.6.0_27\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Bart Skondin
Assignee: Jason van Zyl
 Attachments: provided-scope-not-working.zip


 Expected: A dependency declared with a scope of 'provided', along with any 
 transitive dependencies, should not be included in the final artifact.
 Actual: I have a dependency, jsp-api, declared with 'provided' scope. This 
 dependency has a dependency of its own, servlet-api. The servlet-api.jar is 
 being included in the web-inf/lib folder of the resultant war file.
 Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem 
 was not witnessed until after the upgrade.
 Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib 
 folder. Notice that the servlet-api.jar has been included.
 Additional Info: It seems that I can only reproduce this behavior when 
 declaring a specific dependency in my pom, spring-ldap. Here is the 
 dependency tree for the given pared-down project (attached):
 --- maven-dependency-plugin:2.1:tree (default-cli) @ 
 provided-scope-not-working ---
 com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT
 +- javax.servlet:jsp-api:jar:2.0:provided
 |  \- javax.servlet:servlet-api:jar:2.4:provided
 \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile
+- commons-logging:commons-logging:jar:1.0.4:compile
+- commons-lang:commons-lang:jar:2.1:compile
+- org.springframework:spring-beans:jar:2.0.6:compile
|  +- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)
|  \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for 
 duplicate)
\- org.springframework:spring-core:jar:2.0.6:compile
   \- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5273) Transitive dependencies with scope provided ending up in the final artifact


[ 
https://jira.codehaus.org/browse/MNG-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342556#comment-342556
 ] 

Jason van Zyl commented on MNG-5273:


This appears to be a problem with the WAR plugin, if I setup a project using 
these dependencies and set them to provided and resolve with runtime scope the 
provided dependencies do not show up:

https://github.com/takari/maven-bugs/tree/master/project-mng5273

This is not a Maven core problem. If I were to make a new WAR plugin using the 
logic of the plugin defined in the POM of the bug project I would not see 
provided artifacts in the final WAR.

 Transitive dependencies with scope provided ending up in the final artifact
 ---

 Key: MNG-5273
 URL: https://jira.codehaus.org/browse/MNG-5273
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0.3, 3.0.4
 Environment: Windows 7, Sun OS 5.1
Reporter: Ian Phipps
Assignee: Jason van Zyl

 Marking jaxws-rt as a provided dependency:
 {noformat}dependency
   groupIdcom.sun.xml.ws/groupId
   artifactIdjaxws-rt/artifactId
   version2.1.4/version
   scopeprovided/scope
 /dependency{noformat}
 Correctly resolves jaxb-impl as a provided dependency (dependency:tree output 
 from 3.0.3 and 3.0.4):
 {noformat}[INFO] +- com.sun.xml.ws:jaxws-rt:jar:2.1.4:provided
 [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:provided
 [INFO] | +- com.sun.xml.stream.buffer:streambuffer:jar:0.7:provided
 [INFO] | +- com.sun.xml.stream:sjsxp:jar:1.0.1:provided
 [INFO] | +- org.jvnet.staxex:stax-ex:jar:1.2:provided
 [INFO] | +- com.sun.org.apache.xml.internal:resolver:jar:20050927:provided
 [INFO] | \- org.jvnet:mimepull:jar:1.2:provided {noformat}
 But for some reason, in Maven 3 (tried 3.0.3 and 3.0.4), using a packaging 
 type of war, jaxb-impl-2.1.7 ends up in the final artifact.
 It is correctly omitted from the final artifact in maven 2.x.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

2014-03-07 Thread Michael Zav'yalov (JIRA)

[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342559#comment-342559
]

Michael Zav'yalov commented on MNG-5435:

Greate!
There was more essential inconsistency in my options, namely - parent pom
defined both repositories as central, but settings.xml defined the same
repository by another name! After providing the same name it works, so it looks
like settings.xml property has higher priority than project ones and different
repository names were used for downloading plugin and usual artifacts.
IMHO such minor difference as different naming of the same repository should
not have so big consequences :-)

Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---

Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip

[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact


[ 
https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342560#comment-342560
 ] 

Jason van Zyl commented on MNG-5255:


This is not a bug in Maven's core resolution. As shown by the sample project 
(https://github.com/takari/maven-bugs/tree/master/project-mng5273) artifacts 
marked as provided to not show up in the final set of resolved artifacts.

 Dependency with 'provided' scope has its transitive dependency included in 
 final artifact
 -

 Key: MNG-5255
 URL: https://jira.codehaus.org/browse/MNG-5255
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: D:\bin\apache-maven-3.0.4
 Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
 Java home: D:\bin\java\jdk1.6.0_27\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Bart Skondin
Assignee: Jason van Zyl
 Attachments: provided-scope-not-working.zip


 Expected: A dependency declared with a scope of 'provided', along with any 
 transitive dependencies, should not be included in the final artifact.
 Actual: I have a dependency, jsp-api, declared with 'provided' scope. This 
 dependency has a dependency of its own, servlet-api. The servlet-api.jar is 
 being included in the web-inf/lib folder of the resultant war file.
 Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem 
 was not witnessed until after the upgrade.
 Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib 
 folder. Notice that the servlet-api.jar has been included.
 Additional Info: It seems that I can only reproduce this behavior when 
 declaring a specific dependency in my pom, spring-ldap. Here is the 
 dependency tree for the given pared-down project (attached):
 --- maven-dependency-plugin:2.1:tree (default-cli) @ 
 provided-scope-not-working ---
 com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT
 +- javax.servlet:jsp-api:jar:2.0:provided
 |  \- javax.servlet:servlet-api:jar:2.4:provided
 \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile
+- commons-logging:commons-logging:jar:1.0.4:compile
+- commons-lang:commons-lang:jar:2.1:compile
+- org.springframework:spring-beans:jar:2.0.6:compile
|  +- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)
|  \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for 
 duplicate)
\- org.springframework:spring-core:jar:2.0.6:compile
   \- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact


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

Jason van Zyl closed MNG-5255.
--

Resolution: Cannot Reproduce

 Dependency with 'provided' scope has its transitive dependency included in 
 final artifact
 -

 Key: MNG-5255
 URL: https://jira.codehaus.org/browse/MNG-5255
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: D:\bin\apache-maven-3.0.4
 Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
 Java home: D:\bin\java\jdk1.6.0_27\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Bart Skondin
Assignee: Jason van Zyl
 Attachments: provided-scope-not-working.zip


 Expected: A dependency declared with a scope of 'provided', along with any 
 transitive dependencies, should not be included in the final artifact.
 Actual: I have a dependency, jsp-api, declared with 'provided' scope. This 
 dependency has a dependency of its own, servlet-api. The servlet-api.jar is 
 being included in the web-inf/lib folder of the resultant war file.
 Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem 
 was not witnessed until after the upgrade.
 Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib 
 folder. Notice that the servlet-api.jar has been included.
 Additional Info: It seems that I can only reproduce this behavior when 
 declaring a specific dependency in my pom, spring-ldap. Here is the 
 dependency tree for the given pared-down project (attached):
 --- maven-dependency-plugin:2.1:tree (default-cli) @ 
 provided-scope-not-working ---
 com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT
 +- javax.servlet:jsp-api:jar:2.0:provided
 |  \- javax.servlet:servlet-api:jar:2.4:provided
 \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile
+- commons-logging:commons-logging:jar:1.0.4:compile
+- commons-lang:commons-lang:jar:2.1:compile
+- org.springframework:spring-beans:jar:2.0.6:compile
|  +- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)
|  \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for 
 duplicate)
\- org.springframework:spring-core:jar:2.0.6:compile
   \- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

2014-03-07 Thread Michael Zav'yalov (JIRA)

[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342562#comment-342562
]

Michael Zav'yalov commented on MNG-5435:

I suspect also that in the case my pom does not define the repository
explicitly and default central one is used and settings.xml redefines one
of repositories only - the same/similar problem can occur.

Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---

Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip

[jira] (MCHECKSTYLE-221) ResourceIncludes default value is wrong

2014-03-07 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MCHECKSTYLE-221.
---

Resolution: Fixed

Documentation was fixed in r1575268.

 ResourceIncludes default value is wrong
 ---

 Key: MCHECKSTYLE-221
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-221
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.11
Reporter: Arlo Louis O'Keeffe
Assignee: Dennis Lundberg
Priority: Minor
 Fix For: 2.12


 The default value for resourceIncludes is supposed to be \*\*\/\*.properties 
 but in fact it is \*\*/\*.properties.
 You can verify in the generated maven site: 
 https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes
 An easy workaround is to simply define resourceIncludes yourself.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCHECKSTYLE-222) Resource-only project is not checked

2014-03-07 Thread Dennis Lundberg (JIRA)

Dennis Lundberg created MCHECKSTYLE-222:
---

 Summary: Resource-only project is not checked
 Key: MCHECKSTYLE-222
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-222
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.11
Reporter: Dennis Lundberg


If a project has resources but no source code, Checkstyle is never run on that 
project. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCHECKSTYLE-222) Resource-only project is not checked

2014-03-07 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MCHECKSTYLE-222.
---

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

Fixed in r1575295.

 Resource-only project is not checked
 

 Key: MCHECKSTYLE-222
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-222
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.11
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
 Fix For: 2.12


 If a project has resources but no source code, Checkstyle is never run on 
 that project. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact

2014-03-07 Thread Roman Arkadijovych Muntyanu (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342565#comment-342565
 ] 

Roman Arkadijovych Muntyanu commented on MNG-5255:
--

Was there a bug reported into WAR plug-in in order to get fixed?

 Dependency with 'provided' scope has its transitive dependency included in 
 final artifact
 -

 Key: MNG-5255
 URL: https://jira.codehaus.org/browse/MNG-5255
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: D:\bin\apache-maven-3.0.4
 Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
 Java home: D:\bin\java\jdk1.6.0_27\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Bart Skondin
Assignee: Jason van Zyl
 Attachments: provided-scope-not-working.zip


 Expected: A dependency declared with a scope of 'provided', along with any 
 transitive dependencies, should not be included in the final artifact.
 Actual: I have a dependency, jsp-api, declared with 'provided' scope. This 
 dependency has a dependency of its own, servlet-api. The servlet-api.jar is 
 being included in the web-inf/lib folder of the resultant war file.
 Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem 
 was not witnessed until after the upgrade.
 Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib 
 folder. Notice that the servlet-api.jar has been included.
 Additional Info: It seems that I can only reproduce this behavior when 
 declaring a specific dependency in my pom, spring-ldap. Here is the 
 dependency tree for the given pared-down project (attached):
 --- maven-dependency-plugin:2.1:tree (default-cli) @ 
 provided-scope-not-working ---
 com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT
 +- javax.servlet:jsp-api:jar:2.0:provided
 |  \- javax.servlet:servlet-api:jar:2.4:provided
 \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile
+- commons-logging:commons-logging:jar:1.0.4:compile
+- commons-lang:commons-lang:jar:2.1:compile
+- org.springframework:spring-beans:jar:2.0.6:compile
|  +- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)
|  \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for 
 duplicate)
\- org.springframework:spring-core:jar:2.0.6:compile
   \- (commons-logging:commons-logging:jar:1.1:compile - omitted for 
 conflict with 1.0.4)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4639) Be able to profile a maven build

2014-03-07 Thread Rod Woo (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342568#comment-342568
 ] 

Rod Woo commented on MNG-4639:
--

Another option is EventSpy. EventSpy is a standard way to extend Maven so you 
can use it with Jenkins/Hudson and so on.

Use-Dmaven.ext.class.path=... or maven/lib/ext/yours.jar to let Maven know 
that you provided an extension. 

You can easily take the code of Alexander Klimetschek and make an EventSpy out 
of it.



 Be able to profile a maven build
 

 Key: MNG-4639
 URL: https://jira.codehaus.org/browse/MNG-4639
 Project: Maven 2  3
  Issue Type: New Feature
Reporter: Baptiste MATHUS
 Fix For: Issues to be reviewed for 3.x

 Attachments: 0001-MNG-4639-Be-able-to-profile-a-maven-build.patch


 A common problem with builds is that they can become quite long to run. As it 
 is a know anti-pattern for CI for example, one has the need to try and 
 optimize their builds.
 The thing is: the current granularity isn't sufficiently precise. In fact, 
 you only only the time spent to build each module. This is a good start, 
 though.
 Maven currently displays something like the following (let's speak only about 
 maven 3):
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 [INFO] p2  SUCCESS [5.750s]
 [INFO] p3  SUCCESS [3:58.488s]
 [INFO] p4  SUCCESS [24.437s]
 [INFO] p5  SUCCESS [1.563s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 5 minutes 46 seconds
 {quote}
 What would be great would be adding an option that would higher the details. 
 Something like -A/--analyze (--profile would be too close to -P/profile 
 option) would add detailed analysis, would print something like. 
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 clean:clean (somepkg.CleanMojo) : 10.3s
 compiler:compile (...) : 50s
 ...
 and so on
 {quote}
 I'm not very well aware the level of details maven 3 API could provide. So 
 the printing above could become irrelevant. In this case, printing a 
 dedicated html or so report might be a better choice.
 Cheers
 PS : Though I'm really not introduced into maven code, if you think it's not 
 too complicated, I could try and contribute on this field if I'm given some 
 hints or good starting points. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4639) Be able to profile a maven build


[ 
https://jira.codehaus.org/browse/MNG-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342574#comment-342574
 ] 

Jason van Zyl commented on MNG-4639:


Here is an event spy implementation:

https://github.com/takari/maven-profiler

 Be able to profile a maven build
 

 Key: MNG-4639
 URL: https://jira.codehaus.org/browse/MNG-4639
 Project: Maven 2  3
  Issue Type: New Feature
Reporter: Baptiste MATHUS
 Fix For: Issues to be reviewed for 3.x

 Attachments: 0001-MNG-4639-Be-able-to-profile-a-maven-build.patch


 A common problem with builds is that they can become quite long to run. As it 
 is a know anti-pattern for CI for example, one has the need to try and 
 optimize their builds.
 The thing is: the current granularity isn't sufficiently precise. In fact, 
 you only only the time spent to build each module. This is a good start, 
 though.
 Maven currently displays something like the following (let's speak only about 
 maven 3):
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 [INFO] p2  SUCCESS [5.750s]
 [INFO] p3  SUCCESS [3:58.488s]
 [INFO] p4  SUCCESS [24.437s]
 [INFO] p5  SUCCESS [1.563s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 5 minutes 46 seconds
 {quote}
 What would be great would be adding an option that would higher the details. 
 Something like -A/--analyze (--profile would be too close to -P/profile 
 option) would add detailed analysis, would print something like. 
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 clean:clean (somepkg.CleanMojo) : 10.3s
 compiler:compile (...) : 50s
 ...
 and so on
 {quote}
 I'm not very well aware the level of details maven 3 API could provide. So 
 the printing above could become irrelevant. In this case, printing a 
 dedicated html or so report might be a better choice.
 Cheers
 PS : Though I'm really not introduced into maven code, if you think it's not 
 too complicated, I could try and contribute on this field if I'm given some 
 hints or good starting points. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory


[ 
https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342575#comment-342575
 ] 

Karl Heinz Marbaise commented on MASSEMBLY-628:
---

First the mentioned warning is not bogues it shows you exactly that something 
is wrong in your build and should be changed, cause you are trying to attach a 
dir as artifacts to your project which is not possible (If you like to add 
other files to your project you might use 
[build-helper-maven-plugin|http://mojo.codehaus.org/build-helper-maven-plugin/]).

The point is if you use 
{code}
formats
  formatdir/format
  formattar.gz/format
/formats
{code}
maven-assembly-plugin can't fulfill your requirements which is expressed by the 
given warning.

If you would have had created a separate execution block for 
maven-assembly-plugin and a separate assembly-descriptor where you have changed 
the configuration
{code}
  configuration
  ...
attachfalse/attach
  /configuration
...
formats
  formatdir/format
/formats
{code}
You won't get a warning and maven-assembly-plugin eased itself, cause you are 
doing it the right way.
And that's the reason why this issue will be left closed and defined as {{Not A 
Bug}}.


 Bogus warning when assembling to a directory
 

 Key: MASSEMBLY-628
 URL: https://jira.codehaus.org/browse/MASSEMBLY-628
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
 Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3
 Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
 Java home: c:\Program Files\Java\jdk1.6.0_32\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
 maven-assembly-plugin:2.3
Reporter: Vinicius Isola
 Attachments: test.zip


 When adding a dir format to the assembly file, it will output a bogus 
 warning like the following:
 [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a 
 regular file (it may be a directory). It cannot be attached to the project 
 build for installation or deployment.
 I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289
 Attached is an example project that can reproduce the problem just running 
 mvn clean install



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory


[ 
https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342575#comment-342575
 ] 

Karl Heinz Marbaise edited comment on MASSEMBLY-628 at 3/7/14 12:38 PM:


First the mentioned warning is not bogus it shows you exactly that something is 
wrong in your build and should be changed, cause you are trying to attach a dir 
as artifacts to your project which is not possible (If you like to add other 
files to your project you might use 
[build-helper-maven-plugin|http://mojo.codehaus.org/build-helper-maven-plugin/]).

The point is if you use 
{code}
formats
  formatdir/format
  formattar.gz/format
/formats
{code}
maven-assembly-plugin can't fulfill your requirements which is expressed by the 
given warning.

If you would have had created a separate execution block for 
maven-assembly-plugin and a separate assembly-descriptor where you have changed 
the configuration
{code}
  configuration
  ...
attachfalse/attach
  /configuration
...
formats
  formatdir/format
/formats
{code}
You won't get a warning and maven-assembly-plugin eased itself, cause you are 
doing it the right way.
And that's the reason why this issue will be left closed and defined as {{Not A 
Bug}}.



was (Author: khmarbaise):
First the mentioned warning is not bogues it shows you exactly that something 
is wrong in your build and should be changed, cause you are trying to attach a 
dir as artifacts to your project which is not possible (If you like to add 
other files to your project you might use 
[build-helper-maven-plugin|http://mojo.codehaus.org/build-helper-maven-plugin/]).

The point is if you use 
{code}
formats
  formatdir/format
  formattar.gz/format
/formats
{code}
maven-assembly-plugin can't fulfill your requirements which is expressed by the 
given warning.

If you would have had created a separate execution block for 
maven-assembly-plugin and a separate assembly-descriptor where you have changed 
the configuration
{code}
  configuration
  ...
attachfalse/attach
  /configuration
...
formats
  formatdir/format
/formats
{code}
You won't get a warning and maven-assembly-plugin eased itself, cause you are 
doing it the right way.
And that's the reason why this issue will be left closed and defined as {{Not A 
Bug}}.


 Bogus warning when assembling to a directory
 

 Key: MASSEMBLY-628
 URL: https://jira.codehaus.org/browse/MASSEMBLY-628
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
 Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3
 Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
 Java home: c:\Program Files\Java\jdk1.6.0_32\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
 maven-assembly-plugin:2.3
Reporter: Vinicius Isola
 Attachments: test.zip


 When adding a dir format to the assembly file, it will output a bogus 
 warning like the following:
 [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a 
 regular file (it may be a directory). It cannot be attached to the project 
 build for installation or deployment.
 I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289
 Attached is an example project that can reproduce the problem just running 
 mvn clean install



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-683) dependencySet includes different versions of same dependency when there is a pom relocation involved

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

Karl Heinz Marbaise closed MASSEMBLY-683.
-

Resolution: Not A Bug
Assignee: Karl Heinz Marbaise

dependencySet includes different versions of same dependency when there is a
pom relocation involved

Key: MASSEMBLY-683
URL: https://jira.codehaus.org/browse/MASSEMBLY-683
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.4
Environment: Embedded Maven 3.0.4 in Eclipse Kepler and Maven 3.0.4
on Jenkins. All on Windows 7 with Oracle JDK 7.
Reporter: Claus Schrammel
Assignee: Karl Heinz Marbaise
Attachments: acme.demo.zip

When dependencySets are resolved, the assembly plugin handles different
versions of the same artifact and provides the same result as Maven built-in
dependency resolution does.
But it fails if the artifact is relocated in its pom. The attached example
shows this for xerces:xerces.
The app depends on lib-a, which itself depends on xerces:xerces:1.4.4.
The app also depends on lib-b, which itself depends on xerces:xerces:2.0.2,
but that is relocated to xerces:xercesImpl.
So the dependencySet on app contains xerces-1.4.4 *and* xercesImpl-2.0.2,
causing problems on the classpath of the actual application.
The demo contains a standard case with 2 different log4j version which is
working fine.
The demo also uses the maven-dependency-plugin that is able to resolve the
dependencies correctly. Only xerces-1.4.4 goes into the target/dependency
folder.

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-683) dependencySet includes different versions of same dependency when there is a pom relocation involved

[
https://jira.codehaus.org/browse/MASSEMBLY-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342576#comment-342576
]

Karl Heinz Marbaise commented on MASSEMBLY-683:
---

The point is that for xerces-1.4.4 no relocation enty in central exists whereas
for xerces-2.0.2 it does.
This can't be solved by maven-assembly-plugin nor by maven.

In that case the groupId/artifactId's are different in the poms which means
having both as a result. Such a warning about relocated artifacts should be
fixed.

Based on the above I can't see a wrong behaviour. So i will closes the issue.
If you have any objections please don't hesitate to reopen the issue.

dependencySet includes different versions of same dependency when there is a
pom relocation involved

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-676) Excluding pom packaging projects in moduleSet


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

Karl Heinz Marbaise closed MASSEMBLY-676.
-

Resolution: Not A Bug

Unfortunately there is no working example so i will close the issue.
If you have an example please add it to the issue and of course reopen the 
issue.

 Excluding pom packaging projects in moduleSet
 -

 Key: MASSEMBLY-676
 URL: https://jira.codehaus.org/browse/MASSEMBLY-676
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: moduleSet
Affects Versions: 2.4
Reporter: Alexander Rotnoff
Priority: Minor

 If a project have pom packaging it will be excluded by 
 module-assembly-plugin, while iterating over projects in moduleSet. So, there 
 is no way to use artifacts, attached to this project.
 Workaround is use this artifacts as dependencies.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

2014-03-07 Thread Chris Wesdorp (JIRA)

[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342578#comment-342578
]

Chris Wesdorp commented on MNG-5435:

What exactly is the relation with -llr and repositories with id central? My
pom xmls don't override central and not repo proxy is used.

Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---

Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip

[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation


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

Karl Heinz Marbaise closed MASSEMBLY-671.
-

Resolution: Not A Bug

I have create a [sample github 
project|https://github.com/khmarbaise/massembly/tree/master/massembly-671] with 
Bensons suggestions. 
The question is in this case if a non existings directory should produce a 
warning or fail. The example just produces an zip which does not contain the 
given directory {{something}} as i would expect it. So from my point of view 
this looks like correct behaviour. I someone has supplementals to the example 
just fork and send pull request so we have a based on which we can discuss this 
issue. From my current point of view i can't reproduce a wrong behaviour so i 
will close the issue. If you have objections please don't hesitate to reopen 
the issue.

 Cryptic debug warning message needs improvement and/or documentation
 

 Key: MASSEMBLY-671
 URL: https://jira.codehaus.org/browse/MASSEMBLY-671
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: component descriptor
Affects Versions: 2.2.1, 2.4
 Environment: irrelevant
Reporter: Steve Cohen

 I have used the assembly plugin both versions 2.4 and 2.2.1.  While the 
 plugin basically works, I have some problems with it, (see MASSEMBLY-670), 
 which I suspect may be related to the following message that shows up when 
 running Maven in debug mode (-X):
 {noformat}
 [DEBUG] All known ContainerDescriptorHandler components: [plexus, 
 metaInf-spring, metaInf-services, file-aggregator]
 [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
 org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
 java.util.NoSuchElementException
   role: org.apache.maven.artifact.resolver.ArtifactResolver
   roleHint: project-cache-aware
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
 at 
 org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
 at 
 com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
 at 
 com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at 
 com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
 at 
 com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
 at 
 org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
 at 
 org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
 at 
 org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at

[jira] (MASSEMBLY-669) dependencySet does not resolve transient dependencies in reactor build


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

Karl Heinz Marbaise closed MASSEMBLY-669.
-

Resolution: Not A Bug

The first problem i see in your example is that your given [version ranges are 
wrong|http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] cause 
what you wrote in your dependencies is:

{{[0,]}} which means 0 = x = ?
So the question is what represent the ?

So in other words i see the error message as a correct one cause an artifact 
with the given version 0..  does not exist only artifacts with versio {{1.0.0}} 
do exist.

Apart from that i would ask why are you using version ranges in that case this 
can simply solved by using {{$\{project.version\}}} so no need for them.
So i will close the issue. If you have further details please don't hesitate to 
reopen the issue.

 dependencySet does not resolve transient dependencies in reactor build
 --

 Key: MASSEMBLY-669
 URL: https://jira.codehaus.org/browse/MASSEMBLY-669
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 2.2-beta-5, 2.4
 Environment: linux
Reporter: Christoph
 Attachments: assembly_bug.tar.gz


 using an assembly descriptor with a dependencySet will fail to resolve 
 transient dependencies that are build in the same reactor.
 having artifacts one, two, three. With a dependeny chain: three - two - one
 Artifact three runs an assembly during package phase. It succeeds in finding 
 the artifact two in the reactor. But the transient dependency pointing to 
 artifact one can't be resolved.
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on 
 project three: Failed to create assembly: Unable to resolve dependencies for 
 assembly 'foo': Failed to resolve dependencies for assembly: No versions are 
 present in the repository for the artifact with a range [0,]
 [ERROR] de.gsi.cs.co.maven.assembly_bug:one:jar:null
 A sample project structure is attached. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation


[ 
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342579#comment-342579
 ] 

Karl Heinz Marbaise edited comment on MASSEMBLY-671 at 3/7/14 1:58 PM:
---

I have created a [sample github 
project|https://github.com/khmarbaise/massembly/tree/master/massembly-671] with 
Bensons suggestions. 
The question is in this case if a non existings directory should produce a 
warning or fail. The example just produces an zip which does not contain the 
given directory {{something}} as i would expect it. So from my point of view 
this looks like correct behaviour. If someone has supplementals to the example 
just fork and send pull request so we have a base on which we can discuss this 
issue. From my current point of view i can't reproduce a wrong behaviour so i 
will close the issue. If you have objections please don't hesitate to reopen 
the issue.


was (Author: khmarbaise):
I have create a [sample github 
project|https://github.com/khmarbaise/massembly/tree/master/massembly-671] with 
Bensons suggestions. 
The question is in this case if a non existings directory should produce a 
warning or fail. The example just produces an zip which does not contain the 
given directory {{something}} as i would expect it. So from my point of view 
this looks like correct behaviour. I someone has supplementals to the example 
just fork and send pull request so we have a based on which we can discuss this 
issue. From my current point of view i can't reproduce a wrong behaviour so i 
will close the issue. If you have objections please don't hesitate to reopen 
the issue.

 Cryptic debug warning message needs improvement and/or documentation
 

 Key: MASSEMBLY-671
 URL: https://jira.codehaus.org/browse/MASSEMBLY-671
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: component descriptor
Affects Versions: 2.2.1, 2.4
 Environment: irrelevant
Reporter: Steve Cohen

 I have used the assembly plugin both versions 2.4 and 2.2.1.  While the 
 plugin basically works, I have some problems with it, (see MASSEMBLY-670), 
 which I suspect may be related to the following message that shows up when 
 running Maven in debug mode (-X):
 {noformat}
 [DEBUG] All known ContainerDescriptorHandler components: [plexus, 
 metaInf-spring, metaInf-services, file-aggregator]
 [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
 org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
 java.util.NoSuchElementException
   role: org.apache.maven.artifact.resolver.ArtifactResolver
   roleHint: project-cache-aware
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
 at 
 org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
 at 
 com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
 at 
 com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at 
 com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
 at 
 com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
 at 
 org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
 at

[jira] (MASSEMBLY-666) assembly plugin does not create directory entry in tar.gz archive if more than one fileset provides content to it.

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

Karl Heinz Marbaise closed MASSEMBLY-666.
-

Resolution: Cannot Reproduce

I have created an appropriate [example project on
github|https://github.com/khmarbaise/massembly/tree/master/massembly-666].
I have just tried to create a {{tar.gz}} which will create the correct layout
as well as the correct permissions.
{code}
$ tar -tvvf massembly-666-0.0.1-SNAPSHOT-massembly-666.tar.gz
drwxrwxr-x 0 0 0 0 Mar 7 21:01
massembly-666-0.0.1-SNAPSHOT/dest/
-rw-rw-r-- 0 kama staff 142 Mar 7 21:01
massembly-666-0.0.1-SNAPSHOT/dest/dom4j-1.1.pom
-rw-rw-r-- 0 kama staff 456913 Mar 7 21:01
massembly-666-0.0.1-SNAPSHOT/dest/dom4j-1.1.jar
Archive Format: POSIX ustar format, Compression: gzip
{code}
and after extracting it onto the local hard drive via {{tar -zxpt
massembly-666-0.0.1-SNAPSHOT-massembly-666.tar.gz}}:
{code}
$ ls -al
total 0
drwxr-xr-x 3 kama staff 102 Mar 7 21:04 .
drwxr-xr-x 6 kama staff 204 Mar 7 21:04 ..
drwxrwxr-x 4 kama staff 136 Mar 7 21:01 dest
$ tree
.
âââ dest
âââ dom4j-1.1.jar
âââ dom4j-1.1.pom

1 directory, 2 files
$ ls -al dest/
total 904
drwxrwxr-x 4 kama staff 136 Mar 7 21:01 .
drwxr-xr-x 3 kama staff 102 Mar 7 21:04 ..
-rw-rw-r-- 1 kama staff 456913 Mar 7 21:01 dom4j-1.1.jar
-rw-rw-r-- 1 kama staff 142 Mar 7 21:01 dom4j-1.1.pom
{code}
This looks as i expect it.
So based on the above i will close the issue. If you have supplementals etc.
just fork on github and of course if have objections please reopen the issue.

assembly plugin does not create directory entry in tar.gz archive if more
than one fileset provides content to it.
--

Key: MASSEMBLY-666
URL: https://jira.codehaus.org/browse/MASSEMBLY-666
Project: Maven Assembly Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.4
Environment: redhat entterpirs linux 5
Reporter: Steven Cohen
Priority: Minor

Given an assembly descriptor that produces an .tar.gz archive,
if more than one fileset provides content feeding into the same output
directory, the archiver does not create a directory entry in the archive.
This means that there is nothing to apply the directoryMode to, and when
the archive is expanded with tar -xp, the default instead of the desired
permissions are used in that output directory.
In other words, given the following:
fileSet
directorysrc/A/directory
outputDirectorydest/outputDirectory
includes
include**/include
/includes
fileMode664/fileMode
directoryMode775/fileMode
/fileSet
fileSet
directorysrc/B/directory
outputDirectorydest/outputDirectory
includes
include**/include
/includes
fileMode664/fileMode
directoryMode775/fileMode
/fileSet
an archive will be produced without a directory entry for dest. When the
archive is expanded (tar -zxpf archive-name) the permissions of the dest
directory will be the default, not 775.

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHARED-316) Can not pass storetype nor storepass to a verify request


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

Tony Chemit reopened MSHARED-316:
-


 Can not pass storetype nor storepass to a verify request
 

 Key: MSHARED-316
 URL: https://jira.codehaus.org/browse/MSHARED-316
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.3.1
Reporter: Tony Chemit
Assignee: Tony Chemit
 Fix For: maven-jarsigner-1.3.2






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342582#comment-342582
]

Jason van Zyl commented on MNG-5435:

The ids for all repositories just have to be the same, the id does not have to
be central, that's just what I happen to have. The -llr option forces Maven
to use the SimpleLocalRepositoryManager as opposed to the default
EnhancedLocalRepositoryManager which employs the _remote.repositories tracking
file. In this case I would say that using the enhanced implementation helped
find a configuration error though it would be more helpful to show users where
the misconfiguration is.

Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---

Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip

[jira] (MJARSIGNER-35) verbose mode shows keystore password in clear text


[ 
https://jira.codehaus.org/browse/MJARSIGNER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342583#comment-342583
 ] 

Tony Chemit commented on MJARSIGNER-35:
---

@S Yes it should also integrates the MJARSIGNER-34.

I will then add -storepass, -storetype and -providerXXX but not -keypass, as I 
don't thing we need it, except if you explain me why? ;)


 verbose mode shows keystore password in clear text
 --

 Key: MJARSIGNER-35
 URL: https://jira.codehaus.org/browse/MJARSIGNER-35
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Marco Speranza
Assignee: Tony Chemit
 Fix For: 1.3.2


 If is enabled verbose output, is printed out to the command line the keystore 
 password in clear text.
 here is an example:
 [INFO] cmd.exe /X /C C:\Program 
 Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore 
 mc-keystore -storepass mypassword



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJARSIGNER-34) The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.


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

Tony Chemit reopened MJARSIGNER-34:
---


 The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.
 

 Key: MJARSIGNER-34
 URL: https://jira.codehaus.org/browse/MJARSIGNER-34
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Christian Schulte
Assignee: Tony Chemit
Priority: Blocker
 Fix For: 1.3.2


 Upgrading the 'maven-jarsigner-plugin' from version 1.2 to version 1.3.1, the 
 plugin stops working. In version 1.2, the 'verify' goal did not pass 
 '-keystore' to 'jarsigner'. As of version 1.3, the 'verify' goal passes 
 '-keystore' to 'jarsigner' but does not pass '-storetype' which makes the 
 'verify' goal fail with:
 jarsigner error: keystore load: Invalid keystore format
 due to
 {xml}
 jarsigner.storetypepkcs12/jarsigner.storetype
 {xml}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHARED-316) Can not pass storetype nor storepass to a verify request


[ 
https://jira.codehaus.org/browse/MSHARED-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342587#comment-342587
 ] 

Tony Chemit commented on MSHARED-316:
-

Done in [r1575435|http://svn.apache.org/r1575435]

 Can not pass storetype nor storepass to a verify request
 

 Key: MSHARED-316
 URL: https://jira.codehaus.org/browse/MSHARED-316
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.3.1
Reporter: Tony Chemit
Assignee: Tony Chemit
 Fix For: maven-jarsigner-1.3.2






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHARED-316) Can not pass storetype nor storepass to a verify request


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

Tony Chemit closed MSHARED-316.
---

Resolution: Fixed

 Can not pass storetype nor storepass to a verify request
 

 Key: MSHARED-316
 URL: https://jira.codehaus.org/browse/MSHARED-316
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.3.1
Reporter: Tony Chemit
Assignee: Tony Chemit
 Fix For: maven-jarsigner-1.3.2






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJARSIGNER-34) The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.


[ 
https://jira.codehaus.org/browse/MJARSIGNER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342588#comment-342588
 ] 

Tony Chemit commented on MJARSIGNER-34:
---

Done in [r1575440|http://svn.apache.org/r1575440]

 The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.
 

 Key: MJARSIGNER-34
 URL: https://jira.codehaus.org/browse/MJARSIGNER-34
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Christian Schulte
Assignee: Tony Chemit
Priority: Blocker
 Fix For: 1.3.2


 Upgrading the 'maven-jarsigner-plugin' from version 1.2 to version 1.3.1, the 
 plugin stops working. In version 1.2, the 'verify' goal did not pass 
 '-keystore' to 'jarsigner'. As of version 1.3, the 'verify' goal passes 
 '-keystore' to 'jarsigner' but does not pass '-storetype' which makes the 
 'verify' goal fail with:
 jarsigner error: keystore load: Invalid keystore format
 due to
 {xml}
 jarsigner.storetypepkcs12/jarsigner.storetype
 {xml}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJARSIGNER-34) The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.


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

Tony Chemit closed MJARSIGNER-34.
-

Resolution: Fixed

 The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.
 

 Key: MJARSIGNER-34
 URL: https://jira.codehaus.org/browse/MJARSIGNER-34
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Christian Schulte
Assignee: Tony Chemit
Priority: Blocker
 Fix For: 1.3.2


 Upgrading the 'maven-jarsigner-plugin' from version 1.2 to version 1.3.1, the 
 plugin stops working. In version 1.2, the 'verify' goal did not pass 
 '-keystore' to 'jarsigner'. As of version 1.3, the 'verify' goal passes 
 '-keystore' to 'jarsigner' but does not pass '-storetype' which makes the 
 'verify' goal fail with:
 jarsigner error: keystore load: Invalid keystore format
 due to
 {xml}
 jarsigner.storetypepkcs12/jarsigner.storetype
 {xml}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJARSIGNER-35) verbose mode shows keystore password in clear text


[ 
https://jira.codehaus.org/browse/MJARSIGNER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342590#comment-342590
 ] 

Tony Chemit commented on MJARSIGNER-35:
---

I just deployed a new snapshot, feel free to test it.

I will if everything ok, plan a new release next week.

 verbose mode shows keystore password in clear text
 --

 Key: MJARSIGNER-35
 URL: https://jira.codehaus.org/browse/MJARSIGNER-35
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Marco Speranza
Assignee: Tony Chemit
 Fix For: 1.3.2


 If is enabled verbose output, is printed out to the command line the keystore 
 password in clear text.
 here is an example:
 [INFO] cmd.exe /X /C C:\Program 
 Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore 
 mc-keystore -storepass mypassword



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4161) possibility to omit version in dependency of same project (and fill in on install/deploy)

[
https://jira.codehaus.org/browse/MNG-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342589#comment-342589
]

Jörg Hohwiller commented on MNG-4161:
-

For those that still suffer with maven and version maintenance there is new
hope:
https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin
Please note that the plugin will move out of sandbox in the future so try mojo
instead of sandbox if the link stopped working:
https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin

What you can now do is defining the versions in the dependencyManagement of
your parent POM and then omit them in your child POMs. When you install or
deploy your child POMs consumer-maven-plugin will resolve the versions and fill
them into the consumer POM that gets installed/deployed instead of the original
POM. If you like to, you can keep the parent POM version fixed and never
release the parent POM as the parent is also removed from the
consumer-maven-plugin in its generated POM. Therefore we have a perfect
workaround for this feature request.

Simply check-out and install this plugin. Then add this to your toplevel POMs
build-section:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdconsumer-maven-plugin/artifactId
version1.0.0-beta-1-SNAPSHOT/version
/plugin

I hope that the plugin will move out of sandbox and be released soon.

If you have any feedback please let us know (ideally on MOJOs dev mailing list).

possibility to omit version in dependency of same project (and fill in on
install/deploy)
-

Key: MNG-4161
URL: https://jira.codehaus.org/browse/MNG-4161
Project: Maven 2 3
Issue Type: New Feature
Components: Dependencies, Deployment
Reporter: Jörg Hohwiller
Fix For: Issues to be reviewed for 3.x

I want to suggest a feature discussed on dev-list:
A dependency currently must have groupId, artifactId and version.
If you have a complex multi-module project you typically have lots of project
internal dependencies.
Typically these dependencies point to the same version that is currently
active (on disc/head).
So for the main usecase you have the version of a module redundant (a lot!)
causing lots of maintenance overhead, that might be covered by release-plugin
but might be not (in my case and there are others as well).
Following the principle Conventions over Configuration, a coming version of
maven should allow
to omit the version of a dependency if a pom.xml is loaded for a build (NOT
from repository)
AND the reactor contains a module that has the same groupId and artifactId.
In that
case maven will behave as if the version was declared in the pom.xml with the
version-value of
the module in the reactor. In any other case maven will fail.
The feature can be combined with MNG-2576 so that it also makes sense if just
a single
module or a sub-tree of the project is to be build.
Additionally the ArtifactInstaller and ArtifactDeployer have to guarantee,
that when the pom.xml
is installed or deployed, that the omitted version(s) are automatically
filled in.
This feature will therefore be 100% compatible with older versions of maven
and will never
be visible in the repository. If a pom is loaded from any repository
(including local repo)
maven should NOT accept it in order to avoid accidental usage or even miss
usage of this feature.
Besides it is just an option that would NOT hurt anybody not interested in
the feature.
But for those that get crazy maintaining large projects and for some reason
do NOT follow
the philosophy of release-plugin, this feature would bring final freedom!

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4223) Resolve expressions in POM artifact coordinates


[ 
https://jira.codehaus.org/browse/MNG-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342591#comment-342591
 ] 

Jörg Hohwiller commented on MNG-4223:
-

There is great news for this issue:
https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin
Please note that the plugin will move out of sandbox in the future so try mojo 
instead of sandbox if the link stopped working:
https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin

Simply check-out and install this plugin. Then add this to your toplevel POMs 
build-section:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdconsumer-maven-plugin/artifactId
version1.0.0-beta-1-SNAPSHOT/version
/plugin

I hope that the plugin will move out of sandbox and be released soon.

If you have any feedback please let us know (ideally on MOJOs dev mailing list).

 Resolve expressions in POM artifact coordinates
 ---

 Key: MNG-4223
 URL: https://jira.codehaus.org/browse/MNG-4223
 Project: Maven 2  3
  Issue Type: Bug
  Components: POM
Affects Versions: 2.2.0
Reporter: John Casey
 Fix For: Issues to be reviewed for 3.x


 See: 
 http://docs.codehaus.org/display/MAVEN/Artifact-Coordinate+Expression+Transformation
 See also: MNG-3057, MNG-4167
 We need to resolve artifact coordinates in the POM, including project 
 coordinate, dependencies, plugins, reports, etc. but NOT plugin configuration 
 sections. These coordinates need to be resolved prior to plugins like GPG 
 being executed, and prior to install/deploy steps, to ensure that signatures 
 and derivatives (shade plugin output, for instance), along with installed and 
 deployed copies, contain resolved values.
 We attempted this for version expressions in 2.1.0, but this had several 
 problems, including not being in place for plugin executions, and resolving 
 version expressions within plugin configurations. When we tried to remedy 
 this in 2.2.0, a bunch of more subtle issues sprang up, which are described 
 in the link at the top of this description. In short, we can't really solve 
 this adequately in 2.2.0 without performing major surgery, and even then I'm 
 not sure it'd work. We need to consider this as a design requirement for 
 Maven 3.x, where we can design it into the system instead of trying to 
 retrofit...



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-624) automatic parent versioning