[jira] [Commented] (MDEP-551) recursive dep:tree format dot just appends

[Paul Hammant (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970423#comment-15970423
 ] 

Paul Hammant commented on MDEP-551:
---

So the plugin (using the settings I showed above) makes a file ending in .dot 
that no single application built to .dot files can actually load? 

Really? I ask you to reconsider your "works as designed" assessment, Michael.

> recursive dep:tree format dot just appends
> --
>
> Key: MDEP-551
> URL: https://issues.apache.org/jira/browse/MDEP-551
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: tree
>Reporter: Paul Hammant
> Fix For: waiting-for-feedback
>
>
> For a multi-module build..
> mvn dependency:tree -DappendOutput=true -DoutputType=dot 
> -DoutputFile=/path/to/file.dot
> ... just appends multiple dot files together rather than composes a cohesive 
> large dot (graphviz) file. 
> No graphviz capable tool can load the output :(



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEP-551) recursive dep:tree format dot just appends

[Paul Hammant (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970499#comment-15970499
 ] 

Paul Hammant commented on MDEP-551:
---

I will try the `dependency:tree-aggregate` goal, as you suggest.

In answer to your question, I was expecting to see one giant tree of sub-module 
deps.  Like this 
https://github.com/paul-hammant/jooby-monorepo-experiment/blob/master/mr/dependency-graph.dot
 for the modules in https://github.com/paul-hammant/jooby-monorepo-experiment 
that I made for this 
https://paulhammant.com/2017/02/08/further-experiments-with-expanding-contracting-monorepos/
 blog entry.



> recursive dep:tree format dot just appends
> --
>
> Key: MDEP-551
> URL: https://issues.apache.org/jira/browse/MDEP-551
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: tree
>Reporter: Paul Hammant
> Fix For: waiting-for-feedback
>
>
> For a multi-module build..
> mvn dependency:tree -DappendOutput=true -DoutputType=dot 
> -DoutputFile=/path/to/file.dot
> ... just appends multiple dot files together rather than composes a cohesive 
> large dot (graphviz) file. 
> No graphviz capable tool can load the output :(



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEP-551) recursive dep:tree format dot just appends

[Paul Hammant (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970964#comment-15970964
 ] 

Paul Hammant commented on MDEP-551:
---

The dot graph I made for that monorepo experiment was via 
https://github.com/ferstl/depgraph-maven-plugin which can make an integral 
(only one 'digraph { ... }' section per .dot file).

If I was to reduce my complaint to the smallest it could be, I'd say that the 
MDEP plugin should not allow -DappendOutput=true -DoutputType=dot to be used 
together for a multi-pom situation. It'll complete, but make a .dot file that 
can't be loaded.


> recursive dep:tree format dot just appends
> --
>
> Key: MDEP-551
> URL: https://issues.apache.org/jira/browse/MDEP-551
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: tree
>Reporter: Paul Hammant
> Fix For: waiting-for-feedback
>
>
> For a multi-module build..
> mvn dependency:tree -DappendOutput=true -DoutputType=dot 
> -DoutputFile=/path/to/file.dot
> ... just appends multiple dot files together rather than composes a cohesive 
> large dot (graphviz) file. 
> No graphviz capable tool can load the output :(



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MDEP-551) recursive dep:tree format dot just appends

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MDEP-551:
--

You mean old fashioned patch, as there's no GH repo
, right ?

Sure.

On Mon, Apr 17, 2017 at 3:35 PM, Michael Osipov (JIRA) 



> recursive dep:tree format dot just appends
> --
>
> Key: MDEP-551
> URL: https://issues.apache.org/jira/browse/MDEP-551
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: tree
>Reporter: Paul Hammant
> Fix For: waiting-for-feedback
>
>
> For a multi-module build..
> {noformat}mvn dependency:tree -DappendOutput=true -DoutputType=dot 
> -DoutputFile=/path/to/file.dot{noformat}
> ... just appends multiple dot files together rather than composes a cohesive 
> large dot (graphviz) file. 
> No graphviz capable tool can load the output :(



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MDEP-570) Extending the copy-deps feature a little

[Paul Hammant (JIRA)]

Paul Hammant created MDEP-570:
-

 Summary: Extending the copy-deps feature a little
 Key: MDEP-570
 URL: https://issues.apache.org/jira/browse/MDEP-570
 Project: Maven Dependency Plugin
  Issue Type: Improvement
  Components: copy-dependencies
Reporter: Paul Hammant
Priority: Minor


There's a three command sequence to download an Maven artifact and all its 
transitive deps to a directory:

{code}
mvn dependency:get -Dartifact=org.eclipse.jetty:jetty-servlets:9.4.5.v20170502 
-Dtransitive=true
mvn dependency:copy-dependencies -f 
~/.m2/repository/org/eclipse/jetty/jetty-servlets/9.4.5.v20170502/jetty-servlets-9.4.5.v20170502.pom
 -DoutputDirectory=$(pwd)/foo/ -DincludeScope=compile
cp 
~/.m2/repository/org/eclipse/jetty/jetty-servlet/9.4.5.v20170502/jetty-servlet-9.4.5.v20170502.jar
 foo/
{code}

It would be great if there were a single maven-dependency goal to do the above 
in one operation :) 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

Paul Hammant created MGPG-59:


 Summary: GPG Plugin: "gpg: signing failed: Inappropriate ioctl for 
device"
 Key: MGPG-59
 URL: https://issues.apache.org/jira/browse/MGPG-59
 Project: Maven GPG Plugin
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Paul Hammant


Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice.

"gpg: signing failed: Inappropriate ioctl for device"  

*The remedy *is for the user to do something with gpg on the command line 
*before* going into mvn-release:prepare. Something that will allow gpg to 
remember (for a period of time) the passphrase entered in that interactive UI, 
that the maven invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice.

"gpg: signing failed: Inappropriate ioctl for device"  

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice.

"gpg: signing failed: Inappropriate ioctl for device"  

*The remedy *is for the user to do something with gpg on the command line 
*before* going into mvn-release:prepare. Something that will allow gpg to 
remember (for a period of time) the passphrase entered in that interactive UI, 
that the maven invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice.
> "gpg: signing failed: Inappropriate ioctl for device"  
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  


*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice.

"gpg: signing failed: Inappropriate ioctl for device"  

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> "gpg: signing failed: Inappropriate ioctl for device"  
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Attachment: screenshot-1.png

> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> "gpg: signing failed: Inappropriate ioctl for device"  
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  

!screenshot-1.jpg!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  


*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> "gpg: signing failed: Inappropriate ioctl for device"  
> !screenshot-1.jpg!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  

!screenshot-1.jpg!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> "gpg: signing failed: Inappropriate ioctl for device"  
> !screenshot-1.png!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device"}}

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device" }}

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> {{"gpg: signing failed: Inappropriate ioctl for device"}}
> !screenshot-1.png!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above, perhaps 
> even suggesting the command to run:
> {{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device" }}

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device"  
}}
!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml
}}


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> {{"gpg: signing failed: Inappropriate ioctl for device" }}
> !screenshot-1.png!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above, perhaps 
> even suggesting the command to run:
> {{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device"  
}}
!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml
}}

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

"gpg: signing failed: Inappropriate ioctl for device"  

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above.


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> {{"gpg: signing failed: Inappropriate ioctl for device"  
> }}
> !screenshot-1.png!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above, perhaps 
> even suggesting the command to run:
> {{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml
> }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MGPG-59) GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"

[Paul Hammant (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MGPG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Hammant updated MGPG-59:
-
Description: 
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{*gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect}}
{{"gpg: signing failed: Inappropriate ioctl for device"}}

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}

  was:
Some versions and configurations of GPG want to pop an interactive UI, which 
the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
quits without much advice:

{{"gpg: signing failed: Inappropriate ioctl for device"}}

!screenshot-1.png!

*The remedy is for the user to do something with gpg on the command line before 
going into mvn-release:prepare*. Something that will allow gpg to remember (for 
a period of time) the passphrase entered in that interactive UI, that the maven 
invocation of gpg can take advantage of afterwards.

Historically there was a gpg option '--no-use-agent', but not all gpg 
implementations support that today, not will going forwards as it is being 
removed.

Suggestion: On command error, System.out.println the remedy above, perhaps even 
suggesting the command to run:

{{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}


> GPG Plugin: "gpg: signing failed: Inappropriate ioctl for device"
> -
>
> Key: MGPG-59
> URL: https://issues.apache.org/jira/browse/MGPG-59
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Paul Hammant
> Attachments: screenshot-1.png
>
>
> Some versions and configurations of GPG want to pop an interactive UI, which 
> the maven-gpg-plugin cannot handle.  This appears in the log, before Maven 
> quits without much advice:
> {{*gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect}}
> {{"gpg: signing failed: Inappropriate ioctl for device"}}
> !screenshot-1.png!
> *The remedy is for the user to do something with gpg on the command line 
> before going into mvn-release:prepare*. Something that will allow gpg to 
> remember (for a period of time) the passphrase entered in that interactive 
> UI, that the maven invocation of gpg can take advantage of afterwards.
> Historically there was a gpg option '--no-use-agent', but not all gpg 
> implementations support that today, not will going forwards as it is being 
> removed.
> Suggestion: On command error, System.out.println the remedy above, perhaps 
> even suggesting the command to run:
> {{gpg --use-agent --armor --detach-sign  --output $(mktemp) pom.xml}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MJAR-257) Option to strip non-deterministic aspects of jars post-reation

[Paul Hammant (JIRA)]

Paul Hammant created MJAR-257:
-

 Summary: Option to strip non-deterministic aspects of jars 
post-reation
 Key: MJAR-257
 URL: https://issues.apache.org/jira/browse/MJAR-257
 Project: Maven JAR Plugin
  Issue Type: New Feature
Reporter: Paul Hammant


[https://github.com/esoule/strip-nondeterminism] is a Perl script to do the 
same.

These things could be replicated in Java, and it would be good for the 
community to attempt to chase some of the features of other build technologies, 
and initiatives.

Optional of course: true 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDEP-551) recursive dep:tree format dot just appends

[Paul Hammant (JIRA)]

Paul Hammant created MDEP-551:
-

 Summary: recursive dep:tree format dot just appends
 Key: MDEP-551
 URL: https://issues.apache.org/jira/browse/MDEP-551
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: tree
Reporter: Paul Hammant


For a multi-module build..

mvn dependency:tree -DappendOutput=true -DoutputType=dot 
-DoutputFile=/path/to/file.dot

... just appends multiple dot files together rather than composes a cohesive 
large dot (graphviz) file. 

No graphviz capable tool can load the output :(



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1502) Forking fails on OS/X

[Paul Hammant (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437375#comment-16437375
 ] 

Paul Hammant commented on SUREFIRE-1502:


Can we disambiguate what "OS/X 10" is please.

These are the correct verion names/numbers for macOS (as it is known as today):

 
|[OS X 10.8|https://simple.wikipedia.org/wiki/OS_X_Mountain_Lion]|Mountain 
Lion|February 16, 
2012^[[17]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-16-02-17]^|July 
25, 
2012^[[18]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-25-07-18]^|10.8.5
 (12F45) (October 3, 2013)|
|[OS X 10.9|https://simple.wikipedia.org/wiki/OS_X_Mavericks]|Mavericks|June 
10, 
2013^[[19]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-10-06-19]^|October
 22, 2013|10.9.5 (13F1112) (September 18, 2014)|
|[OS X 10.10|https://simple.wikipedia.org/wiki/OS_X_Yosemite]|Yosemite|June 2, 
2014|October 16, 2014|10.10.5 (14F27) (August 13, 2015)|
|[OS X 10.11|https://simple.wikipedia.org/wiki/OS_X_El_Capitan]|El Capitan|June 
8, 2015|September 30, 2015|10.11.6 (15G1510) (May 15, 2017)|
|[macOS 
10.12|https://simple.wikipedia.org/w/index.php?title=MacOS_10.12&action=edit&redlink=1]|Sierra|June
 13, 2016|September 20, 2016|10.12.6 (16G1212) (Jul 19, 2017)|
|macOS 10.13|High Sierra|June 5, 2017|September 25, 2017|10.13.4 (17E150g) 
(March 29, 2018)|

> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp, 
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_ 
> on version 2.21.0 as well as 2.20.1.  It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon 
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
>  ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider 
> (AbstractSurefireMojo.java:1148)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
>  (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute 
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleM

[jira] [Created] (MNG-7075) mvnDebug --version should only show version info

[Paul Hammant (Jira)]

Paul Hammant created MNG-7075:
-

 Summary: mvnDebug --version should only show version info
 Key: MNG-7075
 URL: https://issues.apache.org/jira/browse/MNG-7075
 Project: Maven
  Issue Type: New Feature
  Components: Bootstrap & Build
Reporter: Paul Hammant


{{$ mvnDebug --version }}{{Preparing to execute Maven in debug 
mode}}{{Listening for transport dt_socket at address: 8000}}

Should really only spit out the same info as:

{{$ mvn --version }}{{Apache Maven 3.6.3 
(cecedd343002696d0abb50b32b541b8a6ba2883f)}}{{Maven home: 
/usr/local/Cellar/maven/3.6.3_1/libexec}}{{Java version: 11.0.9, vendor: Oracle 
Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk-11.0.9.jdk/Contents/Home}}{{Default 
locale: en_US, platform encoding: UTF-8}}{{OS name: "mac os x", version: 
"10.14.6", arch: "x86_64", family: "mac"}}

In other words {{mvnDebug }}should *not* listen on the remote debugger port in 
this {{ --version}}{{ usage}}

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MNG-7076) Allow .mavenrc file in project working directory to override the one in $HOME

[Paul Hammant (Jira)]

Paul Hammant created MNG-7076:
-

 Summary: Allow .mavenrc file in project working directory to 
override the one in $HOME
 Key: MNG-7076
 URL: https://issues.apache.org/jira/browse/MNG-7076
 Project: Maven
  Issue Type: New Feature
  Components: Bootstrap & Build
Affects Versions: 3.6.3
Reporter: Paul Hammant


One wouldn't check it in cos it has platform specific paths in it, but it would 
be great to have a .mavenrc file used in a *project workspace root*.

I could set JDK 8 for one project, and otherwise have JDK 14 for my default 
machine choice in $HOME/.mavenrc

Of course, the one in the project root would be used in preference to the one 
in $HOME



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7076) Allow .mavenrc file in project working directory to override the one in $HOME

[Paul Hammant (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17267171#comment-17267171
 ] 

Paul Hammant commented on MNG-7076:
---

Is there a link to _Toolchains_ ?

> Allow .mavenrc file in project working directory to override the one in $HOME
> -
>
> Key: MNG-7076
> URL: https://issues.apache.org/jira/browse/MNG-7076
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Paul Hammant
>Priority: Minor
>
> One wouldn't check it in cos it has platform specific paths in it, but it 
> would be great to have a .mavenrc file used in a *project workspace root*.
> I could set JDK 8 for one project, and otherwise have JDK 14 for my default 
> machine choice in $HOME/.mavenrc
> Of course, the one in the project root would be used in preference to the one 
> in $HOME



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7076) Allow .mavenrc file in project working directory to override the one in $HOME

[Paul Hammant (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17267189#comment-17267189
 ] 

Paul Hammant commented on MNG-7076:
---

OK, I see. That doesn't mention ~/.mavenrc, but overrides it. Cool.

> Allow .mavenrc file in project working directory to override the one in $HOME
> -
>
> Key: MNG-7076
> URL: https://issues.apache.org/jira/browse/MNG-7076
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Paul Hammant
>Priority: Minor
>
> One wouldn't check it in cos it has platform specific paths in it, but it 
> would be great to have a .mavenrc file used in a *project workspace root*.
> I could set JDK 8 for one project, and otherwise have JDK 14 for my default 
> machine choice in $HOME/.mavenrc
> Of course, the one in the project root would be used in preference to the one 
> in $HOME



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] Created: (MDEP-327) Quiet mode for downloads of artifacts

[Paul Hammant (JIRA)]

Quiet mode for downloads of artifacts
-

 Key: MDEP-327
 URL: https://jira.codehaus.org/browse/MDEP-327
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: resolve
Reporter: Paul Hammant
Assignee: Brian Fox
Priority: Minor


Especially for Build-Machines, could we have less noise on the output of 
downloaded artifacts:

1K downloaded  (json-20080701.pom)
Downloading: 
http://mynexus:8080/nexus/content/groups/public/org/apache/httpcomponents/httpclient/4.0.2/httpclient-4.0.2.pom
4/7K
7/7K
7K downloaded  (httpclient-4.0.2.pom)
Downloading: 
http://mynexus:8080/nexus/content/groups/public/org/apache/httpcomponents/httpcomponents-client/4.0.2/httpcomponents-client-4.0.2.pom
4/8K
8/8K
8/8K
8K downloaded  (httpcomponents-client-4.0.2.pom)
Downloading: 
http://mynexus:8080/nexus/content/groups/public/org/apache/httpcomponents/project/4.1/project-4.1.pom
4/15K
8/15K
12/15K
15/15K

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-4970) DefaultArtifactVersioning.getNextIntegerToken() in maven-artifact-plugin causes lots of IllegalArgumentException on startup

[Paul Hammant (JIRA)]

DefaultArtifactVersioning.getNextIntegerToken() in maven-artifact-plugin causes 
lots of IllegalArgumentException on startup
---

 Key: MNG-4970
 URL: http://jira.codehaus.org/browse/MNG-4970
 Project: Maven 2 & 3
  Issue Type: Improvement
  Components: Bootstrap & Build
Affects Versions: 2.2.1
Reporter: Paul Hammant


This is because it calls Integer.parseInt().  Of course it catches that, but 
I'm trying to debug in IDEA other causes of IllegalArgumentException in my app, 
and your zillion throw/catch/consume is not helping me.

Perhaps you could do a string.charAt(i).isDigit() mechanism instead please ?

-- 
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-228) Try and unable to resolve org.apache.maven.skins:maven-default-skin:jar:RELEASE when another skin is specified

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258758#action_258758
 ] 

Paul Hammant commented on MSITE-228:


This hack worked for me: 
https://github.com/jbehave/jbehave-core/commit/492d4ea213d7bdc5a2a3f522c4af4aa2aeed2cb4

> Try and unable to resolve 
> org.apache.maven.skins:maven-default-skin:jar:RELEASE when another skin is 
> specified
> --
>
> Key: MSITE-228
> URL: http://jira.codehaus.org/browse/MSITE-228
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Stefano Bagnara
>
> 1) My project does not use external repositories for dependencies but only 
> for plugins.
> 2) For dependencies I have a "stage" folder that is a "legacy structured" 
> local repository I reference this way:
> {code}
>   local-james-stage-m1
>   Local James stage repository
>   file://c:/lab/void/projects/server-trunk-modular/stage
>   legacy
>   
> true
> ignore
>   
>   
> true
> ignore
>   
> {code}
> 3) in my site.xml I have this:
> {code}
> org.apache.james
> maven-skin
> 1.1-SNAPSHOT
>   {code}
> 4) and in my local stage repository I have the 
> org.apache.james/poms/maven-skin-1.1-SNAPSHOT.pom and 
> org.apache.james/jars/maven-skin-1.1-SNAPSHOT.jar files.
> If I try to build the project, package it, run tests and everything else it 
> works, but when I try to build "mvn site" if fails with this error:
> {code}
> [DEBUG] maven-default-skin: using locally installed snapshot
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] The skin does not exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins 
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
>   org.apache.maven.skins:maven-default-skin:jar:RELEASE
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.BuildFailureException: The skin does not exist: Unable to 
> determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins 
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
>   org.apache.maven.skins:maven-default-skin:jar:RELEASE
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoFailureException: The skin does not 
> exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins 
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
>   org.apache.maven.skins:maven-default-skin:jar:RELEASE
> at 
> org.a

[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upperlimits for comma-separated list of tests)

[Paul Hammant (JIRA)]

Paul Hammant created SUREFIRE-1134:
--

 Summary: Take list of tests from file (-Dtest has upperlimits for 
comma-separated list of tests)
 Key: SUREFIRE-1134
 URL: https://jira.codehaus.org/browse/SUREFIRE-1134
 Project: Maven Surefire
  Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor


-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:

   -DtestListFile=testsToRun.txt

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/





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

[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)

[Paul Hammant (JIRA)]

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

Paul Hammant updated SUREFIRE-1134:
---

Description: 
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:

   -DtestListFile=testsToRun.txt

Also for Failsafe:

   -Dit.testListFile=testsToRun.txt

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



  was:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:

   -DtestListFile=testsToRun.txt

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



Summary: Take list of tests from file (-Dtest has upper limits for 
comma-separated list of tests)  (was: Take list of tests from file (-Dtest has 
upperlimits for comma-separated list of tests))

> Take list of tests from file (-Dtest has upper limits for comma-separated 
> list of tests)
> 
>
> Key: SUREFIRE-1134
> URL: https://jira.codehaus.org/browse/SUREFIRE-1134
> Project: Maven Surefire
>  Issue Type: New Feature
>Reporter: Paul Hammant
>Priority: Minor
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a 
> list of tests.  There are upper limits to that in the context of command line 
> arguments.
> Could we additionally have:
>-DtestListFile=testsToRun.txt
> Also for Failsafe:
>-Dit.testListFile=testsToRun.txt
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
> Maven.
> Refer 
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



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

[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)

[Paul Hammant (JIRA)]

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

Paul Hammant updated SUREFIRE-1134:
---

Description: 
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:
{panel:title=Example mvn 
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}

Also for Failsafe:

{panel:title=Example mvn 
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



  was:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:
{panel:title=Example mvn param}
-DtestListFile=testsToRun.txt
{panel}

Also for Failsafe:

{panel:title=Example mvn param}
-Dit.testListFile=testsToRun.txt
{panel}

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/




> Take list of tests from file (-Dtest has upper limits for comma-separated 
> list of tests)
> 
>
> Key: SUREFIRE-1134
> URL: https://jira.codehaus.org/browse/SUREFIRE-1134
> Project: Maven Surefire
>  Issue Type: New Feature
>Reporter: Paul Hammant
>Priority: Minor
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a 
> list of tests.  There are upper limits to that in the context of command line 
> arguments.
> Could we additionally have:
> {panel:title=Example mvn 
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn 
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
> Maven.
> Refer 
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



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

[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)

[Paul Hammant (JIRA)]

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

Paul Hammant updated SUREFIRE-1134:
---

Description: 
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:
{panel:title=Example mvn param}
-DtestListFile=testsToRun.txt
{panel}

Also for Failsafe:

{panel:title=Example mvn param}
-Dit.testListFile=testsToRun.txt
{panel}

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



  was:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list 
of tests.  There are upper limits to that in the context of command line 
arguments.

Could we additionally have:

   -DtestListFile=testsToRun.txt

Also for Failsafe:

   -Dit.testListFile=testsToRun.txt

Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
Maven.

Refer 
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/




> Take list of tests from file (-Dtest has upper limits for comma-separated 
> list of tests)
> 
>
> Key: SUREFIRE-1134
> URL: https://jira.codehaus.org/browse/SUREFIRE-1134
> Project: Maven Surefire
>  Issue Type: New Feature
>Reporter: Paul Hammant
>Priority: Minor
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a 
> list of tests.  There are upper limits to that in the context of command line 
> arguments.
> Could we additionally have:
> {panel:title=Example mvn param}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn param}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking 
> Maven.
> Refer 
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/



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

[jira] Created: (MREPOSITORY-21) 'project.scm.url must be present' error message typo - should be 'project.scm.connection must be present'

[Paul Hammant (JIRA)]

'project.scm.url must be present' error message typo - should be 
'project.scm.connection must be present'
-

 Key: MREPOSITORY-21
 URL: http://jira.codehaus.org/browse/MREPOSITORY-21
 Project: Maven 2.x Repository Plugin
  Issue Type: Bug
Reporter: Paul Hammant


http://svn.apache.org/viewvc/maven/plugins/trunk/maven-repository-plugin/src/main/java/org/apache/maven/plugins/repository/BundleCreateMojo.java?revision=820163&view=markup

This is an error message twice in the source :- 
   project.scm.url must be present

cut/paste error I suspect.

- Paul

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

[jira] Created: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

JSR330 @Inject TCK (official release) 1
---

 Key: MAVENUPLOAD-2738
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Paul Hammant


I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
for that project.

paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (MNG-3139) The skin does not exist: Unable to determine the release version

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=211718#action_211718
 ] 

Paul Hammant commented on MNG-3139:
---

Yup, two days after a successful release and site deployment, I try another 
minor release (Java == same, Maven == same, Project Checkout == same, bar a CPE 
bugfix) and builds with site fail now.

   > [INFO] SiteToolException: ArtifactNotFoundException: The skin does not 
exist: Unable to determine the release version

I'm guessing that I have an unfixed dependency somewhere, that if I fix to a 
prior version, it'll work again.  I've tried the following but it does not work 
:-

org.apache.maven.plugins:maven-site-plugin:2.1

- Paul

> The skin does not exist: Unable to determine the release version
> 
>
> Key: MNG-3139
> URL: http://jira.codehaus.org/browse/MNG-3139
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: eyal david
>Assignee: John Casey
> Fix For: 2.0.11, 2.1.0, 3.0-alpha-3
>
> Attachments: cached-metadata.patch, mvn_site_debug.zip
>
>
> hi I have problem generating site when im using the command mvn site
> it performs all stagegs and when it came to site generation the message is 
> shown :
> The skin does not exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins 
> -DartifactId=maven
> -default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
>   org.apache.maven.skins:maven-default-skin:jar:RELEASE
> do u have an idea what is the problem ?
> p.s the jar is registered in my local repository and in the remote repository 
> thank u 

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

[jira] Commented: (MNG-3139) The skin does not exist: Unable to determine the release version

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=211800#action_211800
 ] 

Paul Hammant commented on MNG-3139:
---

Blowing away the LOCAL-REPO/org/apache/maven/skins/* worked.

In the past I've seen maven artifacts downloaded in hotels/cafes over wifi 
screw up the local repo because the wifi software is wanting your to buy 
service or click-thru some forms before it's return actual pages rather than 
intercept.  Maven is (or was) unable to see that foo.jar coming down over these 
services is actually intercepted HTML from T-Mobile or other.

> The skin does not exist: Unable to determine the release version
> 
>
> Key: MNG-3139
> URL: http://jira.codehaus.org/browse/MNG-3139
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: eyal david
>Assignee: John Casey
> Fix For: 2.0.11, 2.1.0, 3.0-alpha-3
>
> Attachments: cached-metadata.patch, mvn_site_debug.zip
>
>
> hi I have problem generating site when im using the command mvn site
> it performs all stagegs and when it came to site generation the message is 
> shown :
> The skin does not exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins 
> -DartifactId=maven
> -default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
>   org.apache.maven.skins:maven-default-skin:jar:RELEASE
> do u have an idea what is the problem ?
> p.s the jar is registered in my local repository and in the remote repository 
> thank u 

-- 
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: (MREPOSITORY-22) repository:bundle-create ignores -f directive (different pom.xml file)

[Paul Hammant (JIRA)]

repository:bundle-create  ignores -f directive (different pom.xml file)
---

 Key: MREPOSITORY-22
 URL: http://jira.codehaus.org/browse/MREPOSITORY-22
 Project: Maven 2.x Repository Plugin
  Issue Type: Bug
Reporter: Paul Hammant


MAVENUPLOAD-2738 details a case where the bundle creator attempted to make a 
bundle for JSR-330's TCK.

To repo..

1) svn checkout http://atinject.googlecode.com/svn/trunk/ atinject-read-only
2) cd atinject-read-only
3) mvn repository:bundle-create -f tck-pom.xml

(example jar bundle's pom.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] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

I've just been through the learning curve for gpg signing for mockpico, I'll 
give it another go.

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

I have applied for upload rights :- https://issues.sonatype.org/browse/OSSRH-509

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

OK, I've updated the tck pom. See 
http://atinject.googlecode.com/svn/trunk/tck-pom.xml
I'm inspired by my recent success with release/gpg to sonatype (Github rather 
that googlecode) exemplified here :- 
http://github.com/paul-hammant/mockpico/blob/master/pom.xml

Question to the Mavenistas: will the release:prepare/perform stuff work with a 
pom file not called pom.xml OR does it have the same bug as 
http://jira.codehaus.org/browse/MREPOSITORY-22 (the -f directive is ignored).

If yes, I can temporarily overwrite the pom.xml file in svn with the tck one, 
do the release, then revert the change in svn (even though that's kinda dirty 
workaround) 

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

Bob Lee (the lead for JSR330) will never in his remaining years on this planet 
ever use Maven.  Those of us that like Maven, will have to live with non-module 
organization of the source for the @Inject project.  That means two pom files 
that are in the same directory :- http://atinject.googlecode.com/svn/trunk/

> I don't think you can use an alternative pom to do release 

I will try. If it does not work, I will raise an issue on codehaus for the 
release plugin

> but why you want to overwrite pom.xml with another projects' pom? I don't get 
> it 

This is my workaround if the alternate-pom side of the release plugin has that 
issue.
 

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

-- 
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-568) Release plugin (in perform phase) ignore -f directive (non-default pom.xml file)

[Paul Hammant (JIRA)]

Release plugin (in perform phase) ignore -f directive (non-default pom.xml file)


 Key: MRELEASE-568
 URL: http://jira.codehaus.org/browse/MRELEASE-568
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Reporter: Paul Hammant


mvn -f alternate-pom.xml release:perform

 [ time passes ]

[INFO] Working directory: /scm/oss/atinject/target
[INFO] Executing goals 'deploy'...
[INFO] Executing: /bin/sh -c cd /scm/oss/atinject/target/checkout && 
/Installed/apache-maven-2.2.1/bin/mvn deploy --no-plugin-updates 
-DperformRelease=true -f pom.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] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

As suspected, the alternate-pom bug in the release plugin exists :- 
http://jira.codehaus.org/browse/MRELEASE-568

I will try the second approach I outlined.

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

-- 
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-569) Inadequate explanation of "BUILD ERROR: .... Return Code is 401"

[Paul Hammant (JIRA)]

Inadequate explanation of "BUILD ERROR:  Return Code is 401"


 Key: MRELEASE-569
 URL: http://jira.codehaus.org/browse/MRELEASE-569
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Reporter: Paul Hammant


That this return code (and perhaps all return codes) are HTTP response codes is 
not clear.

I lack authority to the remote directory apparently.



 [INFO] [deploy:deploy {execution: default-deploy}]
Uploading: 
http://oss.sonatype.org/service/local/staging/deploy/maven2//javax/inject/javax.inject-tck/1/javax.inject-tck-1.jar
[INFO] 

[ERROR] BUILD ERROR
[INFO] 

[INFO] Error deploying artifact: Failed to transfer file: 
http://oss.sonatype.org/service/local/staging/deploy/maven2/javax/inject/javax.inject-tck/1/javax.inject-tck-1.jar.
 Return code is: 401


-- 
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-569) Inadequate explanation of "BUILD ERROR: .... Return Code is 401"

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223972#action_223972
 ] 

Paul Hammant commented on MRELEASE-569:
---

I think the error message should say:

  Return code for HTTP operation is: 401

Or:

  Return code for HTTP operation is: 401.  Check HTTP status codes here 
http://www.w3.org/Protocols/HTTP/HTRESP.html

Instead of the following as it is vague:

  Return code is: 401

> Inadequate explanation of "BUILD ERROR:  Return Code is 401"
> 
>
> Key: MRELEASE-569
> URL: http://jira.codehaus.org/browse/MRELEASE-569
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Reporter: Paul Hammant
>
> That this return code (and perhaps all return codes) are HTTP response codes 
> is not clear.
> I lack authority to the remote directory apparently.
>  [INFO] [deploy:deploy {execution: default-deploy}]
> Uploading: 
> http://oss.sonatype.org/service/local/staging/deploy/maven2//javax/inject/javax.inject-tck/1/javax.inject-tck-1.jar
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error deploying artifact: Failed to transfer file: 
> http://oss.sonatype.org/service/local/staging/deploy/maven2/javax/inject/javax.inject-tck/1/javax.inject-tck-1.jar.
>  Return code is: 401

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

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

Brett, are you talking about the javax.inject TCK already uploaded to a repo ?  
I can't find it quickly to link to it presently.  The problem with it is, that 
it was released before the TCK was finished.  It's not complete in respect of 
methods.  It was also uploaded through a JBoss (?) channel, rather than some 
thing associated with the actual JSR-330 team.

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

> and http://repository.sonatype.org/content/repositories/third-party is not 
> synced to central

I'm confused.  How is that relevant to this issue?

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

-- 
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: (MGPG-28) Should be able to use gpg2 that MacPorts will install

[Paul Hammant (JIRA)]

Should be able to use gpg2 that MacPorts will install
-

 Key: MGPG-28
 URL: http://jira.codehaus.org/browse/MGPG-28
 Project: Maven 2.x GPG Plugin
  Issue Type: New Feature
Reporter: Paul Hammant


On Mac, should be able to use gpg2 or gpg.

paul$ gpg --version 
gpg (GnuPG) 1.4.10
Copyright (C) 2008 Free Software Foundation, Inc.

paul$ gpg2 --version 
gpg (GnuPG) 2.0.13
libgcrypt 1.4.4
Copyright (C) 2009 Free Software Foundation, Inc.


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

[jira] Created: (SCM-556) Vague error message from git-scm-plugin prevents release:prepare

[Paul Hammant (JIRA)]

Vague error message from git-scm-plugin prevents release:prepare


 Key: SCM-556
 URL: http://jira.codehaus.org/browse/SCM-556
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-git
Affects Versions: 1.3
Reporter: Paul Hammant


"Unable to commit files" is vague I think.

The only special thing I'm trying to do is commit from a branch that is not 
master.  Yes, the branch has remote representation (fully pushed) as well as 
local.

For the record the project is paranamer on codehaus, which was flipped from 
Subversion to Git. http://xircles.codehaus.org/projects/paranamer/repo/git/repo 
  real_asm branch.

-e -X console output :

[DEBUG] # On branch real_asm
[DEBUG] # Untracked files:
[DEBUG] #   (use "git add ..." to include in what will be committed)
[DEBUG] #
[DEBUG] #   pom.xml.releaseBackup
[DEBUG] #   release.properties
[DEBUG] nothing added to commit but untracked files present (use "git add" to 
track)
[INFO] nothing added to commit but untracked files present (use "git add" to 
track)
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git commit 
--verbose -F 
/var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-890989155.commit 
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Unable to commit files
Provider message:
The git-commit command failed.
Command output:

[INFO] 
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The git-commit command failed.
Command output:

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
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: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.MojoFailureException: Unable to commit files
Provider message:
The git-commit command failed.
Command output:

at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219)
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)
... 17 more
Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: 
Unable to commit files
Provider message:
The git-commit command failed.
Command output:

at 
org.apache.maven.shared.release.phase.ScmCommitPhase.checkin(ScmCommitPhase.java:133)
at 
org.apache.maven.shared.release.phase.ScmCommitPhase.execute(ScmCommitPhase.java:109)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
... 20 more
[INFO] -

[jira] Created: (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)

[Paul Hammant (JIRA)]

ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
-

 Key: SCM-557
 URL: http://jira.codehaus.org/browse/SCM-557
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-git
Affects Versions: 1.3
Reporter: Paul Hammant


Trying to run the release plugin for a git project 
http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch real_asm). 
 In the prepare phase it barfs like so :

[INFO] [INFO] 

[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO] 

[INFO] [INFO] Total time: 11 seconds
[INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010
[INFO] [INFO] Final Memory: 39M/81M
[INFO] [INFO] 

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add -- 
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[DEBUG] # On branch real_asm
[DEBUG] # Changes to be committed:
[DEBUG] #   (use "git reset HEAD ..." to unstage)
[DEBUG] #
[DEBUG] #   modified:   pom.xml
[DEBUG] #
[DEBUG] # Untracked files:
[DEBUG] #   (use "git add ..." to include in what will be committed)
[DEBUG] #
[DEBUG] #   pom.xml.releaseBackup
[DEBUG] #   release.properties
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git commit 
--verbose -F 
/var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit 
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git 
symbolic-ref HEAD
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push 
ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##

ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly

[INFO] 
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##

ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
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:597)
at org.codehaus.classworlds

[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1

[Paul Hammant (JIRA)]

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

Paul Hammant commented on MAVENUPLOAD-2738:
---

OK, my workaround worked.  The -f direct of of Maven is ignored by selected 
plugins.  If releasing, you need to (until fixed) use the main pom.xml.  In the 
case of the @Inject project that meant overwriting the main pom and commiting 
to subvsersion.  There was a small permissions issue on oss.sonatype.org that 
prevented me from pushing to it over webdav, but Juven fixed that for me, and 
it's all done now (barring sync to central).  *This* issue can be closed, 
thanks for all for help.

> JSR330 @Inject TCK (official release) 1
> ---
>
> Key: MAVENUPLOAD-2738
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Paul Hammant
>Assignee: Juven Xu
>
> I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page 
> for that project.
> paul / codehaus == PaulHammant / GoogleCode.

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

[jira] Commented: (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225928#action_225928
 ] 

Paul Hammant commented on SCM-557:
--

So after the fail of this, and before I tidy up working copy, I can experiment 
some


ph-mbp:paranamer paul$ git push ssh://g...@git.codehaus.org/paranamer.git/ 
real_asm:real_asm
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##

ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
ph-mbp:paranamer paul$ git push ssh://g...@git.codehaus.org/paranamer.git/ 
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##

ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
ph-mbp:paranamer paul$ git push codehaus  
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##

Counting objects: 42, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 1.99 KiB, done.
Total 22 (delta 10), reused 0 (delta 0)
To ssh://g...@git.codehaus.org/paranamer-git.git
   e216419..48f1052  master -> master
   b222639..24a42e5  real_asm -> real_asm

Me again -
Is there a reason that the git-scm plugin needs to be so anal with respect to 
commands ?
Surely it could verify which branch it is on:

>  ph-mbp:paranamer paul$ git branch -a 
>  master
>  real_am
> * real_asm
>  remotes/codehaus/master
>  remotes/codehaus/real_asm
>  remotes/github/master
>  remotes/github/real_asm

I'm not using 'origin' to denote origin.  'codehaus' is my origin, 'github' is 
a mirror.

> ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
> -
>
> Key: SCM-557
> URL: http://jira.codehaus.org/browse/SCM-557
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-git
>Affects Versions: 1.3
>Reporter: Paul Hammant
>
> Trying to run the release plugin for a git project 
> http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch 
> real_asm).  In the prepare phase it barfs like so :
> [INFO] [INFO] 
> 
> [INFO] [INFO] BUILD SUCCESSFUL
> [INFO] [INFO] 
> 
> [INFO] [INFO] Total time: 11 seconds
> [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010
> [INFO] [INFO] Final Memory: 39M/81M
> [INFO] [INFO] 
> 
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add 
> -- pom.xml
> [INFO] Working directory: /scm/oss/paranamer-git/paranamer
> [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status
> [INFO] Working directory: /scm/oss/paranamer-git/paranamer
> [DEBUG] # On branch real_asm
> [DEBUG] # Changes to be committed:
> [DEBUG] #   (use "git reset HEAD ..." to unstage)
> [DEBUG] #
> [DEBUG] # modified:   pom.xml
> [DEBUG] #
> [DEBUG] # Untracked files:
> [DEBUG] #   (use "git add ..." to include in what will be committed)
> [DEBUG] #
> [DEBUG] # pom.xml.releaseBackup
> [DEBUG] # release.properties
> [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git 
> commit --verbose -F 
> /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit 
> pom.xml
> [INFO] Working directory: /scm/oss/paranamer-git/paranamer
> [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git 
> symbolic-ref HEAD
> [INFO] Working directory: /scm/oss/paranamer-git/paranamer
> [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push 
> ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm
> [INFO] Working directory: /scm/oss/paranamer-git/paranamer
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 

[jira] (SUREFIRE-1039) Running TestNG tests (specific group) skips @BeforeMethod methods

[Paul Hammant (JIRA)]

Paul Hammant created SUREFIRE-1039:
--

 Summary: Running TestNG tests (specific group) skips @BeforeMethod 
methods
 Key: SUREFIRE-1039
 URL: https://jira.codehaus.org/browse/SUREFIRE-1039
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.16
 Environment: Mac 10.8.5, Maven 3.1.0, Java version: 1.7.0_09
Reporter: Paul Hammant


1. In Intellij right-click run-test executes the test method immediately after 
the setup method (marked @BeforeMethod). 

2. Running on the command line (mvn) the same two methods are executed.

3. After making a group, and putting the group in a profile (as per 
http://stackoverflow.com/questions/7150302/excluding-testng-groups-from-maven) 
the test method is invoked, but the @BeforeMethod method was not invoked before 
it.

I was going to debug it, so that I could tell you root cause defect, but IDEA 
conspires to now show me all the breakpoints of the plugin before the actual 
test invocation.

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

[jira] (SUREFIRE-1039) Running TestNG tests (specific group) skips @BeforeMethod methods

[Paul Hammant (JIRA)]

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

Paul Hammant commented on SUREFIRE-1039:


Darn it - my fault - you need to have the same groups thingy for the 
@BeforeMethod annotation as you do for the @Test method. There's no implicit 
'all' for @BeforeMethod

> Running TestNG tests (specific group) skips @BeforeMethod methods
> -
>
> Key: SUREFIRE-1039
> URL: https://jira.codehaus.org/browse/SUREFIRE-1039
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 2.16
> Environment: Mac 10.8.5, Maven 3.1.0, Java version: 1.7.0_09
>Reporter: Paul Hammant
>
> 1. In Intellij right-click run-test executes the test method immediately 
> after the setup method (marked @BeforeMethod). 
> 2. Running on the command line (mvn) the same two methods are executed.
> 3. After making a group, and putting the group in a profile (as per 
> http://stackoverflow.com/questions/7150302/excluding-testng-groups-from-maven)
>  the test method is invoked, but the @BeforeMethod method was not invoked 
> before it.
> I was going to debug it, so that I could tell you root cause defect, but IDEA 
> conspires to now show me all the breakpoints of the plugin before the actual 
> test invocation.

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

[jira] Commented: (MSHADE-2) Make prefix configurable in SimpleRelocator

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MSHADE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108954
 ] 

Paul Hammant commented on MSHADE-2:
---

Would love it to be sophisticated :

org.objectweb.asm.*

goes to :

org.myproject.asm.*

for classes in that dir, and recursive.

-ph

> Make prefix configurable in SimpleRelocator
> ---
>
> Key: MSHADE-2
> URL: http://jira.codehaus.org/browse/MSHADE-2
> Project: Maven 2.x Shade Plugin
>  Issue Type: Improvement
>Reporter: Mauro Talevi
>Assignee: Mauro Talevi
>Priority: Minor
>
> Currency SimpleRelocator prefixes class name with "hidden".  This behaviour, 
> while adeguate as default, should be configurable.

-- 
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: (MSHADE-4) Extraneous directories and uneeded files included after shading

[Paul Hammant (JIRA)]

Extraneous directories and uneeded files included after shading
---

 Key: MSHADE-4
 URL: http://jira.codehaus.org/browse/MSHADE-4
 Project: Maven 2.x Shade Plugin
  Issue Type: Bug
Reporter: Paul Hammant


Refer build of 
https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/pom.xml

Makes a jar that containes ...

 0 Fri Oct 05 09:32:28 PDT 2007 META-INF/
   123 Fri Oct 05 09:32:28 PDT 2007 META-INF/MANIFEST.MF
 0 Fri Oct 05 09:32:28 PDT 2007 org/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/containers/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/injectors/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/lifecycle/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/monitors/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/parameters/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/references/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/security/
 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/visitors/
  3766 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/adapters/AbstractAdapter.class
  4113 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/adapters/InstanceAdapter.class
   391 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Cache.class
   408 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Inject.class
   387 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/Behavior.class
   689 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/BehaviorFactory.class
  4770 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/AbstractBehavior.class
  3737 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/AbstractBehaviorFactory.class
  5132 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/AdaptiveBehavior.class
   745 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automated.class
  1742 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automatic.class
  1024 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Behaviors.class
  1037 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Cached.class
  2685 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Caching.class
  1344 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/HiddenImplementation$1.class
  4079 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/HiddenImplementation.class
  1862 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/ImplementationHiding.class
   457 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Intercepted$Controller.class
  1360 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Intercepted$ControllerImpl.class
  1933 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Intercepted$ControllerWrapper.class
   686 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Intercepted$InterceptorThreadLocal.class
  3617 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Intercepted.class
  1507 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/Interception.class
  1143 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locked.class
  1687 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locking.class
  1797 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/OptInCaching.class
  1130 Fri Oct 05 09:32:28 PDT 2007 
org/picocontainer/behaviors/PropertyApplicator$1.class
 10001 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/PropertyApplicator.class
  2436 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/PropertyApplying.class
  3011 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Stored.class
   562 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/Storing$StoreThreadLocal.class
   814 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/Storing$StoreWrapper.class
  4043 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing.class
   842 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/Synchronized.class
  1660 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/Synchronizing.class
  1013 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/ThreadCached.class
  1806 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/behaviors/ThreadCaching.class
   940 Fri Oct 05 09:32:30 PDT 2007 
org/picocontainer/Characteristics$ImmutableProperties.class
  2039 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/Characteristics.class
   993 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentAdapter.class
   689 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentFactory.class
  1504 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentMonitor.class
   279 Fri Oct 05 09:32:30 PDT 2007 

[jira] Created: (MEV-606) New version of Prefuse to upload - beta-20071021

[Paul Hammant (JIRA)]

New version of Prefuse to upload - beta-20071021 
-

 Key: MEV-606
 URL: http://jira.codehaus.org/browse/MEV-606
 Project: Maven Evangelism
  Issue Type: Wish
Reporter: Paul Hammant


Following on from http://jira.codehaus.org/browse/MEV-523 , the is a newer 
version of Prefuse for the repo :

http://sourceforge.net/project/showfiles.php?group_id=98962&package_id=106038&release_id=548630

The zip there contains the project ready to build.  
   'ant all' makes a jar and a source jar.
   'ant api' makes Javadoc in doc/ 

Java 1.4 is the minimum level for Prefuse, so watch out when building.

-- 
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-3361) Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit

[Paul Hammant (JIRA)]

Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit


 Key: MNG-3361
 URL: http://jira.codehaus.org/browse/MNG-3361
 Project: Maven 2
  Issue Type: Bug
  Components: Deployment
Affects Versions: 2.0.8
Reporter: Paul Hammant


[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 3 minutes 25 seconds
[INFO] Finished at: Fri Jan 11 08:49:42 PST 2008
[INFO] Final Memory: 14M/29M
[INFO] 

[INFO] Checking in modified POMs...
[INFO] Executing: svn --non-interactive commit --file 
/tmp/maven-scm-1359802395.commit --targets /tmp/maven-scm-28211-targets
[INFO] Working directory: /scm/oss/jremoting/root/trunk
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: MKACTIVITY of '/jremoting/!svn/act/c136e17a-8ec7-44c4-a326-b2611ec72ffc': 
authorization failed (https://svn.codehaus.org)



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

[jira] Commented: (MNG-3361) Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127334
 ] 

Paul Hammant commented on MNG-3361:
---

I'm guessing there is going to be a standoff between the Svn team Tigris at 
Apple.

Can the maven team work around it ?  i.e. step back from --non-interactive for 
leopard users with a warning about it ?

Or do we have to keep a Tiger Mac handy for deployments before this is resolved 
?

- Paul

> Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit
> 
>
> Key: MNG-3361
> URL: http://jira.codehaus.org/browse/MNG-3361
> Project: Maven 2
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 2.0.8
>Reporter: Paul Hammant
>
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 3 minutes 25 seconds
> [INFO] Finished at: Fri Jan 11 08:49:42 PST 2008
> [INFO] Final Memory: 14M/29M
> [INFO] 
> 
> [INFO] Checking in modified POMs...
> [INFO] Executing: svn --non-interactive commit --file 
> /tmp/maven-scm-1359802395.commit --targets /tmp/maven-scm-28211-targets
> [INFO] Working directory: /scm/oss/jremoting/root/trunk
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: MKACTIVITY of 
> '/jremoting/!svn/act/c136e17a-8ec7-44c4-a326-b2611ec72ffc': authorization 
> failed (https://svn.codehaus.org)

-- 
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-3570) Jetty plugin dodo is bad

[Paul Hammant (JIRA)]

Jetty plugin dodo is bad


 Key: MNG-3570
 URL: http://jira.codehaus.org/browse/MNG-3570
 Project: Maven 2
  Issue Type: Bug
  Components: Documentation:  General
Reporter: Paul Hammant


Which of these is correct - 
http://mojo.codehaus.org/jetty-maven-plugin/usage.html and 
http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin ?

Both result in 

[ERROR] BUILD ERROR
[INFO] 
[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist 
or no valid version could be found
[INFO] 

or thereabouts.

-- 
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: (MAVEN-1831) Ibiblio Repository access that has items marked as '301: Moved permanently' causes maven to barf.

[Paul Hammant (JIRA)]

Ibiblio Repository access that has items marked as '301: Moved permanently' 
causes maven to barf.
-

 Key: MAVEN-1831
 URL: http://jira.codehaus.org/browse/MAVEN-1831
 Project: Maven 1.x
  Issue Type: Bug
 Environment: Maven 1.0.2 on Mac, Java build 1.5.0_06-113
Reporter: Paul Hammant


To reproduce, refer to QDox trunk -

  svn co https://svn.codehaus.org/qdox/trunk/

Try to build default goal for qdox/ module

If your setup is the same as mine, you get...

  WARNING: Failed to download ant-1.5.1.jar.
  Attempting to download junit-3.8.1.jar.
  Error retrieving artifact from 
[http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar]: java.io.IOException: 
Unknown error downloading; status code was: 301
  WARNING: Failed to download junit-3.8.1.jar.
  The build cannot continue because of the following unsatisfied dependencies:

  ant-1.5.1.jar
  junit-3.8.1.jar

  Total time: 2 seconds
  Finished at: Wed Jan 31 06:31:03 GMT 2007

WGET process differently for me ...

  paul-hammants-computer:~/scm/oss/qdox/trunk/qdox paul$ wget 
http://www.ibiblio.org/maven/jmock/jars/jmock-1.0.0.jar
  --06:31:17--  http://www.ibiblio.org/maven/jmock/jars/jmock-1.0.0.jar
   => `jmock-1.0.0.jar'
  Resolving www.ibiblio.org... done.
  Connecting to www.ibiblio.org[152.46.7.80]:80... connected.
  HTTP request sent, awaiting response... 301 Moved Permanently
  Location: 
http://mirrors.ibiblio.org/pub/mirrors/maven2/jmock/jmock/1.0.0/jmock-1.0.0.jar 
[following]
  --06:31:17--  
http://mirrors.ibiblio.org/pub/mirrors/maven2/jmock/jmock/1.0.0/jmock-1.0.0.jar
   => `jmock-1.0.0.jar'
  Resolving mirrors.ibiblio.org... done.
  Connecting to mirrors.ibiblio.org[152.46.7.65]:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 69,251 [text/plain]

  
100%[=>]
 69,251   101.24K/sETA 00:00 

It could be that these forwards are sensitive to your TCP/IP location (I'm 
presently in Scotland)

-- 
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-480) perform goal checks out wrong tag to target/checkout

[Paul Hammant (JIRA)]

perform goal checks out wrong tag to target/checkout


 Key: MRELEASE-480
 URL: http://jira.codehaus.org/browse/MRELEASE-480
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: Paul Hammant


Snow Leopard / Maven 2.2.0 / Svn 1.6.3 (via macports)

After a failed release (due to an uncommitted file), as second attempt from 
trunk -

version 1.10
tag foo-1.10-attempt2
next version 1.11-SNAPSHOT

here's the bug - the 'perform' stage tried to checkout from foo-1.10, not 
foo-1.10-attempt2 as was wanted.

I was able to repeat this three times.

- Paul


-- 
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-481) prepare goal no longer errors on subversion files

[Paul Hammant (JIRA)]

prepare goal  no longer errors on subversion files 
---

 Key: MRELEASE-481
 URL: http://jira.codehaus.org/browse/MRELEASE-481
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: Paul Hammant


Snow Leopard / Maven 2.2.0 / Svn 1.6.3 (via macports)

release:prepare used to error telling you that you had files not checked in.

It no longer does, or no longer does by default :-(

-ph

-- 
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: (MSHADE-62) We need an element - to TRULY exclude classes from resulting jar

[Paul Hammant (JIRA)]

We need an  element - to TRULY exclude classes from resulting jar 
---

 Key: MSHADE-62
 URL: http://jira.codehaus.org/browse/MSHADE-62
 Project: Maven 2.x Shade Plugin
  Issue Type: New Feature
Reporter: Paul Hammant


'exclusions' is misnamed - it should be 'leaveAsIs' or somesuch.

I want to totally exclude some packages or classes from the resulting jar.  As 
in leave them out, or kill them, or don't have them at all in the resulting 
jar.  Neither as their original class name nor their potential new class name.

Perforce has an 'obliterate' concept, given exclude is already used in shade, 
maybe obliterate is the new element for this essential feature.

-- 
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: (MSHADE-62) We need an element - to TRULY exclude classes from resulting jar

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MSHADE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=190011#action_190011
 ] 

Paul Hammant commented on MSHADE-62:


I thought I could exclude classes that would never be used by PicoContainer 
like so :-
{noformat} 
  
org.apache.maven.plugins
maven-shade-plugin
1.2.1

  
package

  shade


  picocontainer
  

  javax.annotation:jsr250-api

  
  

  com.thoughtworks.paranamer
  org.picocontainer.paranamer
  

com.thoughtworks.paranamer.JavadocParanamer
  

  

  

  
{noformat} 

Unfortunately, exclude does not mean exclude it means "don't re-package" .

{noformat} 
ph-mbp:container paul$ jar -tvf target/picocontainer-2.9-SNAPSHOT.jar | grep 
paranamer
 0 Sun Sep 06 11:06:50 CDT 2009 org/picocontainer/paranamer/
  3150 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/AdaptiveParanamer.class
   809 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer$1.class
  7803 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer$ClassReader.class
  2977 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer$MethodCollector.class
  4662 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer$Type.class
  6262 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer$TypeCollector.class
  6198 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/BytecodeReadingParanamer.class
  2535 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/CachingParanamer.class
  5336 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/DefaultParanamer.class
 0 Sun Sep 06 11:06:50 CDT 2009 com/thoughtworks/paranamer/
 10630 Sun Sep 06 11:06:50 CDT 2009 
com/thoughtworks/paranamer/JavadocParanamer.class
  1432 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/NullParanamer.class
   964 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/ParameterNamesNotFoundException.class
   762 Sun Sep 06 11:06:50 CDT 2009 org/picocontainer/paranamer/Paranamer.class
   549 Sun Sep 06 11:06:50 CDT 2009 
org/picocontainer/paranamer/ParanamerConstants.class
 0 Sun Sep 06 11:06:50 CDT 2009 META-INF/maven/com.thoughtworks.paranamer/
 0 Sun Sep 06 11:06:50 CDT 2009 
META-INF/maven/com.thoughtworks.paranamer/paranamer/
  1290 Sun Sep 06 11:06:50 CDT 2009 
META-INF/maven/com.thoughtworks.paranamer/paranamer/pom.xml
   127 Sun Sep 06 11:06:50 CDT 2009 
META-INF/maven/com.thoughtworks.paranamer/paranamer/pom.properties
{noformat} 

Specifically, its these two lines that I'd rather were left out completely (not 
in the jar, not in the jar in re-packaged form) ..

{noformat} 
 0 Sun Sep 06 11:06:50 CDT 2009 com/thoughtworks/paranamer/
 10630 Sun Sep 06 11:06:50 CDT 2009 
com/thoughtworks/paranamer/JavadocParanamer.class
{noformat} 

Also, I'd rather do without the pom.xml stuff for paranamer too, but that's a 
different issue.

- Paul




> We need an  element - to TRULY exclude classes from resulting 
> jar 
> ---
>
> Key: MSHADE-62
> URL: http://jira.codehaus.org/browse/MSHADE-62
> Project: Maven 2.x Shade Plugin
>  Issue Type: New Feature
>Reporter: Paul Hammant
>
> 'exclusions' is misnamed - it should be 'leaveAsIs' or somesuch.
> I want to totally exclude some packages or classes from the resulting jar.  
> As in leave them out, or kill them, or don't have them at all in the 
> resulting jar.  Neither as their original class name nor their potential new 
> class name.
> Perforce has an 'obliterate' concept, given exclude is already used in shade, 
> maybe obliterate is the new element for this essential feature.

-- 
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: (MSHADE-62) We need an element - to TRULY exclude classes from resulting jar

[Paul Hammant (JIRA)]

[ 
http://jira.codehaus.org/browse/MSHADE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=190014#action_190014
 ] 

Paul Hammant commented on MSHADE-62:


You're right Ben, the following was what I wanted ...
{noformat}
  
org.apache.maven.plugins
maven-shade-plugin
1.2.1

  
package

  shade


  picocontainer



com.thoughtworks.paranamer:paranamer


com/thoughtworks/paranamer/Javadoc*




  
com.thoughtworks.paranamer
org.picocontainer.paranamer
  
  

  

  
{noformat}

This bug can be closed - sorry for wasting your time

> We need an  element - to TRULY exclude classes from resulting 
> jar 
> ---
>
> Key: MSHADE-62
> URL: http://jira.codehaus.org/browse/MSHADE-62
> Project: Maven 2.x Shade Plugin
>  Issue Type: New Feature
>Reporter: Paul Hammant
>
> 'exclusions' is misnamed - it should be 'leaveAsIs' or somesuch.
> I want to totally exclude some packages or classes from the resulting jar.  
> As in leave them out, or kill them, or don't have them at all in the 
> resulting jar.  Neither as their original class name nor their potential new 
> class name.
> Perforce has an 'obliterate' concept, given exclude is already used in shade, 
> maybe obliterate is the new element for this essential feature.

-- 
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] (MSHADE-402) Shading produces empty test jar

[Paul Hammant (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914073#comment-17914073
 ] 

Paul Hammant commented on MSHADE-402:
-

Bug reproduced in a repo - https://github.com/paul-hammant/shadeTestDepsBug

> Shading produces empty test jar
> ---
>
> Key: MSHADE-402
> URL: https://issues.apache.org/jira/browse/MSHADE-402
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Cédric Champeau
>Priority: Major
>
> Dear maintainers,
> I'm working with the shade plugin in the context of a workaround for a 
> Windows bug: when invoking a CLI in Windows, there's a maximum length that 
> you can use. The GraalVM `native-image` is invoked on CLI with a "classpath" 
> argument which easily exceeds that limit. There are several options to 
> workaround this but in this context, the most promising, which worked for the 
> Gradle plugin, was to use _shading_.
> For the main artifact, this technique works properly: we can use the "shade" 
> plugin to generate a shaded jar which is then passed to `native-image`. 
> However, we also have support for _unit test_ execution "as a native image", 
> which means that we need to build a native image which includes test classes 
> and the test runtime (e.g JUnit Platform).
> Unfortunately, this technique doesn't work for Maven. First of all, let's see 
> how the build is configured:
> {code:xml}
> 
>org.apache.maven.plugins
>maven-shade-plugin
>3.2.4
>
>
>package
>
>shade
>
>
>
>
>true
>true
>
> 
> {code}
> As you can see, I'm using `shadeTestJar`, but if you run the package phase, 
> you will see that the resulting jar is _empty_. After trying to figure out 
> why, it turns out there are 2 different reasons:
>  * the first one seems to be that you _must_ generate a test jar before hand. 
> This isn't mentioned in the docs, but I could get a _non empty_ jar by adding 
> this:
> {code:xml}
>  
> org.apache.maven.plugins
> maven-jar-plugin
> 3.2.0
> 
>   
> 
>   test-jar
> 
>   
> 
>   
> {code}
>  * the second problem is that the shaded generated test jar doesn't include 
> the test dependencies
> After debugging, I noticed that the `project.getDependencies()` method did 
> **not** return the test dependencies. The javadocs for this method state that 
> they _should_ include the test dependencies, since when this code is 
> executed, the "test" phase has been executed. Debugging showed me that the 
> "resolved dependencies" cache was correct, but that a filter only kept the 
> "runtime" dependencies. The mojo descriptor mentions:
> @Mojo( name = "shade", defaultPhase = LifecyclePhase.PACKAGE, threadSafe = 
> true, requiresDependencyResolution = ResolutionScope.RUNTIME )
> So I guess the problem comes from the "requiresDependencyResolution" value, 
> which should be set to "TEST" for the test jar to include test dependencies.
> However, I suspect that by changing this parameter to TEST, then the _main_ 
> jar would suddenly start including test dependencies, which isn't expected.
> Let me know if my analysis is correct. I'm open to suggestions on how to 
> workaround this problem.
> Thanks!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MDEP-975) Command-line use of copy-dependencies does excludeTransitive=true when pom based use has that as false by default

[Paul Hammant (Jira)]

Paul Hammant created MDEP-975:
-

 Summary: Command-line use of copy-dependencies does 
excludeTransitive=true when pom based use has that as false by default
 Key: MDEP-975
 URL: https://issues.apache.org/jira/browse/MDEP-975
 Project: Maven Dependency Plugin
  Issue Type: Improvement
  Components: copy-dependencies
Affects Versions: 3.8.1
Reporter: Paul Hammant


[https://maven.apache.org/components/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive]
 - suggests false is default.


Command line use ( I have a project that has okhttp as  test dep):

 ```
mvn -q dependency:copy-dependencies -DincludeScope=test 
-DincludeArtifactIds=okhttp -DoutputDirectory=target/libs_for_test
```

This should have copied okio, kotlin-stdlib and okio-jvm, too, but did not.

I think the command line use of copy-dependencies  should match the defaults of 
the pom/xml based use of the same



--
This message was sent by Atlassian Jira
(v8.20.10#820010)