date:20110228


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

Benjamin Bentmann updated MNG-5028:
---

Component/s: (was: Plugin Requests)
 Plugins and Lifecycle

> Obey generics in plugin collection parameters when populating them
> --
>
> Key: MNG-5028
> URL: http://jira.codehaus.org/browse/MNG-5028
> Project: Maven 2 & 3
>  Issue Type: Improvement
>  Components: Plugins and Lifecycle
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> Right now, when determining the target type for a collection item to convert 
> POM configuration to, Maven/Plexus uses some heuristics based on the XML 
> element name and the mojo package name and eventually falls back to 
> {{String}}. The current approach requires plugin authors to either put their 
> parameter bean classes into the same package as the mojo or requires users to 
> explicitly use the {{implementation}} attribute in the POM. These troubles 
> can be avoided if Maven would recognize the generic type of a parameter 
> declaration {{List}}, thereby aligning collections with arrays 
> regarding the ease of configuration/use.

-- 
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-5028) Obey generics in plugin collection parameters when populating them

Obey generics in plugin collection parameters when populating them
--

 Key: MNG-5028
 URL: http://jira.codehaus.org/browse/MNG-5028
 Project: Maven 2 & 3
  Issue Type: Improvement
  Components: Plugin Requests
Reporter: Benjamin Bentmann
Priority: Minor


Right now, when determining the target type for a collection item to convert 
POM configuration to, Maven/Plexus uses some heuristics based on the XML 
element name and the mojo package name and eventually falls back to {{String}}. 
The current approach requires plugin authors to either put their parameter bean 
classes into the same package as the mojo or requires users to explicitly use 
the {{implementation}} attribute in the POM. These troubles can be avoided if 
Maven would recognize the generic type of a parameter declaration 
{{List}}, thereby aligning collections with arrays regarding the ease of 
configuration/use.

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

[jira] Closed: (MNG-5028) Obey generics in plugin collection parameters when populating them


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

Benjamin Bentmann closed MNG-5028.
--

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

Done in [r1070102|http://svn.apache.org/viewvc?view=revision&revision=1070102].

> Obey generics in plugin collection parameters when populating them
> --
>
> Key: MNG-5028
> URL: http://jira.codehaus.org/browse/MNG-5028
> Project: Maven 2 & 3
>  Issue Type: Improvement
>  Components: Plugins and Lifecycle
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0.3
>
>
> Right now, when determining the target type for a collection item to convert 
> POM configuration to, Maven/Plexus uses some heuristics based on the XML 
> element name and the mojo package name and eventually falls back to 
> {{String}}. The current approach requires plugin authors to either put their 
> parameter bean classes into the same package as the mojo or requires users to 
> explicitly use the {{implementation}} attribute in the POM. These troubles 
> can be avoided if Maven would recognize the generic type of a parameter 
> declaration {{List}}, thereby aligning collections with arrays 
> regarding the ease of configuration/use.

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

[jira] Closed: (MNG-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1


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

Benjamin Bentmann closed MNG-5027.
--

Resolution: Not A Bug
  Assignee: Benjamin Bentmann

>From the forked sources, 
>[SurefirePlugin.java#588|https://github.com/kabir/jboss-modules-surefire-plugin/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L588]
{code:java}
private List roots;
{code}
and from 
[SurefirePlugin.java#1377|https://github.com/kabir/jboss-modules-surefire-plugin/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L1377]
{code:java}
for (Iterator it = roots.iterator() ; it.hasNext() ; ) {
File file = new File((String)it.next());
{code}

This is where the compiler and IDE usually point out some issue with 
type-safety. The field {{roots}} is declared as {{List}} yet the 
{{Iterator}} usage assumes {{List}}. The newly added support for 
generics in MNG-5028 makes this programming error show up now.

Assuming the plugin fork should be compatible with older Maven versions, the 
field {{roots}} should be declared of type {{List}}.

> Problem executing custom surefire implementation in Maven 3.0.3-RC1
> ---
>
> Key: MNG-5027
> URL: http://jira.codehaus.org/browse/MNG-5027
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Reporter: Paul Gier
>Assignee: Benjamin Bentmann
> Attachments: build.log
>
>
> There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1.  When 
> executing the jboss-as build [1] the build fails during execution of our 
> custom implementation of the surefire plugin [2].
> [1]https://github.com/jbossas/jboss-as
> [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin

-- 
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-658) tagBase parameter for release plugin is partially ignored

2011-02-28 Thread David Bilge (JIRA)

tagBase parameter for release plugin is partially ignored
-

 Key: MRELEASE-658
 URL: http://jira.codehaus.org/browse/MRELEASE-658
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.1
 Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_21, vendor: Sun Microsystems Inc.
Java home: C:\Program Files (x86)\Java\jdk1.6.0_21\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
Reporter: David Bilge


Using a different directory layout (tags/project instead of project/tags) I 
configured the tagBase as described on the maven site:


org.apache.maven.plugins
maven-release-plugin
2.1

http://[pathToSvnRepo]/tags/projectName/



Calling release:prepare, everything works correctly; even the scm info is 
changed exactly as expected. But, when the commit to create the tag is 
executed, it fails with an error like "path 
http://[pathToSvnRepo]/trunk/projectName/tags/1.7 does not exist" (wording 
might be different).

Using maven 2 works flawlessly.

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

[jira] Commented: (SUREFIRE-704) maven surefire Error while executing forked tests.; nested exception is java.lang.IllegalStateException: testSetStarting called twice


[ 
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257957#action_257957
 ] 

Kristian Rosenvold commented on SUREFIRE-704:
-

I have isolated the cause of this issue and it happens because the last line 
being printed to System.out/err does not contain a linefeed.

So as a temporary fix until 2.8 is released, you can add a linefeed after the 
last test before finishing each test class:

@AfterClass
public static void tempFix(){
   System.out.println();
System.err.println();
}


> maven surefire Error while executing forked tests.; nested exception is 
> java.lang.IllegalStateException: testSetStarting called twice
> -
>
> Key: SUREFIRE-704
> URL: http://jira.codehaus.org/browse/SUREFIRE-704
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support
>Affects Versions: 2.7.2
> Environment: Windows/Linux/SunOS
>Reporter: S Daigle
> Attachments: surefire.txt
>
>
> We want to upgrade from our current 2.5 version of the maven-surefire-plugin 
> to something newer but cannot get past the error below. We've tried versions 
> 2.6, 2.7 up to and including 2.7.3-SNAPSHOT but they all fail.
> When setting forkmode to "once" and redirectTestOutputToFile to "true", we 
> get the following error on multiple tests:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.3-SNAPSHOT:test 
> (default-test) on project api: Error while executing forked tests.; nested 
> exception is java.lang.IllegalStateException: testSetStarting called twice -> 
> [Help 1]
> Please see the attachment for full "mvn -e test" output.
> If we set the redirectTestOutputToFile to false, it works but we need this 
> option set to true.
> Thanks

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

[jira] Commented: (SUREFIRE-704) maven surefire Error while executing forked tests.; nested exception is java.lang.IllegalStateException: testSetStarting called twice

2011-02-28 Thread S Daigle (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257959#action_257959
 ] 

S Daigle commented on SUREFIRE-704:
---

Hi Kristian,

The error looks identical between 2.7.2 and the latest 2.7.3-SNAPSHOT versions. 
I attached a surefire-272.txt so you can see the stack. We do print a lot of 
output to stdout/stderr for many tests and if I make redirectTestOutputToFile 
false, the tests pass. We can also set our forkmode from once to always to get 
around this issue however a small test run that takes approx. 20 seconds to 
complete will take almost 2 minutes. We have over 16,000 tests so this is not 
an option for us.

Thanks,
Shell

> maven surefire Error while executing forked tests.; nested exception is 
> java.lang.IllegalStateException: testSetStarting called twice
> -
>
> Key: SUREFIRE-704
> URL: http://jira.codehaus.org/browse/SUREFIRE-704
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support
>Affects Versions: 2.7.2
> Environment: Windows/Linux/SunOS
>Reporter: S Daigle
> Attachments: surefire.txt
>
>
> We want to upgrade from our current 2.5 version of the maven-surefire-plugin 
> to something newer but cannot get past the error below. We've tried versions 
> 2.6, 2.7 up to and including 2.7.3-SNAPSHOT but they all fail.
> When setting forkmode to "once" and redirectTestOutputToFile to "true", we 
> get the following error on multiple tests:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.3-SNAPSHOT:test 
> (default-test) on project api: Error while executing forked tests.; nested 
> exception is java.lang.IllegalStateException: testSetStarting called twice -> 
> [Help 1]
> Please see the attachment for full "mvn -e test" output.
> If we set the redirectTestOutputToFile to false, it works but we need this 
> option set to true.
> Thanks

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

[jira] Updated: (SUREFIRE-704) maven surefire Error while executing forked tests.; nested exception is java.lang.IllegalStateException: testSetStarting called twice

2011-02-28 Thread S Daigle (JIRA)


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

S Daigle updated SUREFIRE-704:
--

Attachment: surefire-272.txt

> maven surefire Error while executing forked tests.; nested exception is 
> java.lang.IllegalStateException: testSetStarting called twice
> -
>
> Key: SUREFIRE-704
> URL: http://jira.codehaus.org/browse/SUREFIRE-704
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support
>Affects Versions: 2.7.2
> Environment: Windows/Linux/SunOS
>Reporter: S Daigle
> Attachments: surefire-272.txt, surefire.txt
>
>
> We want to upgrade from our current 2.5 version of the maven-surefire-plugin 
> to something newer but cannot get past the error below. We've tried versions 
> 2.6, 2.7 up to and including 2.7.3-SNAPSHOT but they all fail.
> When setting forkmode to "once" and redirectTestOutputToFile to "true", we 
> get the following error on multiple tests:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.3-SNAPSHOT:test 
> (default-test) on project api: Error while executing forked tests.; nested 
> exception is java.lang.IllegalStateException: testSetStarting called twice -> 
> [Help 1]
> Please see the attachment for full "mvn -e test" output.
> If we set the redirectTestOutputToFile to false, it works but we need this 
> option set to true.
> Thanks

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

[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds


[ 
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257966#action_257966
 ] 

Kristian Rosenvold commented on SUREFIRE-690:
-

Are you setting the "forkTimeout" parameter in your surefire settings ? We have 
identified a (rare) race condition that could occur if the forked process times 
out while still outputting to stdout/stderr. Just setting "forkTimeout" is 
actually enough to trigger this, it would happen even with "forkMode=never" as 
long as forkTimeout is set.



> testSetCompleted called before testSetStarting when using m3 parallel builds
> 
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
> Fix For: 2.7.3
>
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on 
> project hornet-stinger: Error while executing forked tests.; nested exception 
> is java.lang.IllegalStateException: testSetCompleted called before 
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously

-- 
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] Issue Comment Edited: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds


[ 
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257966#action_257966
 ] 

Kristian Rosenvold edited comment on SUREFIRE-690 at 2/28/11 7:48 AM:
--

Are you setting the "forkTimeout" parameter in your surefire settings ? We have 
identified a race condition that could occur if the forked process times out 
while still outputting to stdout/stderr. Just setting "forkTimeout" is actually 
enough to trigger 
this, it would happen even with "forkMode=never" as long as forkTimeout is set.

Actually the issue would probably happen quite frequently as long as the 
process outputs to stderr/stdout at the exact time it times out with 
"forkTimeout". 


  was (Author: krosenvold):
Are you setting the "forkTimeout" parameter in your surefire settings ? We 
have identified a (rare) race condition that could occur if the forked process 
times out while still outputting to stdout/stderr. Just setting "forkTimeout" 
is actually enough to trigger this, it would happen even with "forkMode=never" 
as long as forkTimeout is set.


  
> testSetCompleted called before testSetStarting when using m3 parallel builds
> 
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
> Fix For: 2.7.3
>
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on 
> project hornet-stinger: Error while executing forked tests.; nested exception 
> is java.lang.IllegalStateException: testSetCompleted called before 
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously

-- 
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-659) snapshot dependency check on preparation of release: check artifacts WITH versions

2011-02-28 Thread Stephan Krull (JIRA)

snapshot dependency check on preparation of release: check artifacts WITH
versions
--

Key: MRELEASE-659
URL: http://jira.codehaus.org/browse/MRELEASE-659
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.0
Environment: maven 2.2.1, jdk1.6, release-plugin 2.1,
preparationGoals="clean compile", goals="clean install", maven call: "clean
dependency:resolve release:prepare release:perform"
Reporter: Stephan Krull

running a release on a project with the following dependency declaration:
{noformat}

abc
myartifact
1.0.0-SNAPSHOT

abc
myartifact
1.0.0
test-jar
test

{noformat}

we all would expect the plugin to fail the release because the dependency
snapshot detection should find the SNAPSHOT artifact. with further checks i
found that when using "dependency:resolve" no snapshot-artifact will be found
in the checking phase. i did some more analysis and think that the cause is in
"org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(Artifact,
Map, Map, ReleaseDescriptor)". there the artifact to check is again
initialized by getting it from the "ArtifactUtils.artifactMapByVersionlessId(
project.getArtifacts() )"-Map. this map, unfortunately, doesn't keep both
dependencies from above. so the check fails and the release plugin wrongly
succeedes.

i guess that there is more than this pain with dependency resolution. just want
to let you know. as a workaround i just skip executing the "dependency:resolve"
goal while releasing.

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

[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds

2011-02-28 Thread Gin-Ting Chen (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257971#action_257971
 ] 

Gin-Ting Chen commented on SUREFIRE-690:


yes I am. more specifically {{forkedProcessTimeoutInSeconds}}.

> testSetCompleted called before testSetStarting when using m3 parallel builds
> 
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
> Fix For: 2.7.3
>
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on 
> project hornet-stinger: Error while executing forked tests.; nested exception 
> is java.lang.IllegalStateException: testSetCompleted called before 
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously

-- 
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: (MJARSIGNER-13) signing in multi-module project fails on windows

2011-02-28 Thread Anna Gadomska (JIRA)

signing in multi-module project fails on windows


 Key: MJARSIGNER-13
 URL: http://jira.codehaus.org/browse/MJARSIGNER-13
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Windows XP, android sdk 
Reporter: Anna Gadomska
 Attachments: pom.xml

I got multi-module (6 modules) android project with .pom file and "sign" 
profile defined. When I execute with 'sign' profile:
- in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
(mv  -rf) it signs another 3 modules and fails again. The reason for 
failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig failed.
- in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
"error code 1"


However, I tried the same .pom - everything works perfectly in Linux (Ubuntu). 

I was afraid that it might be the issue with spaces, so I hardcoded the paths - 
the error I got from maven than was:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
MyProject: Failed executing 'cmd.exe /X /C 
"C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
"C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
'*'debugkey"' - exitcode 1 -> [Help 1]


Attaching pom file which I am using.
Please help?

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

[jira] Created: (SUREFIRE-706) Global lock to serialize tests even if maven runs in parallel mode

2011-02-28 Thread Frank Meilinger (JIRA)

Global lock to serialize tests even if maven runs in parallel mode
--

 Key: SUREFIRE-706
 URL: http://jira.codehaus.org/browse/SUREFIRE-706
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
 Environment: all
Reporter: Frank Meilinger


It would be nice to serialize unit tests globally in the surefire plugin, even 
if maven 3 runs with parallel mode. I know that some test providers are able to 
do parallel testing itself (e.g. Junit47 provider) without running maven in 
parallel or not. These test provider parallel mode can be configured with 
surefire plugin configuration. E.g. none can be used to 
serialize unit tests even if using the JUnit47 provider. But when running maven 
3 with -T  option, the tests are still running in parallel, depending on the 
parallel decision of maven 3. For code which is not able to run in parallel 
(while unit tests are running, this will happen), this is a problem. In this 
case the provider option none won't help. I think it would 
be great (and maybe easy to implement) to have a global surefire plugin option 
to globally lock the surefire plugin's execute() method to serialize all unit 
tests over all parallel maven builds. 

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

[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds


[ 
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257980#action_257980
 ] 

Kristian Rosenvold commented on SUREFIRE-690:
-

And can you confirm that either
A) The exception always happens when the tests were supposed to time out
B) Increasing the timeout seems to help ;) (Say doubling its current value)


> testSetCompleted called before testSetStarting when using m3 parallel builds
> 
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
> Fix For: 2.7.3
>
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on 
> project hornet-stinger: Error while executing forked tests.; nested exception 
> is java.lang.IllegalStateException: testSetCompleted called before 
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously

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

[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds

2011-02-28 Thread Gin-Ting Chen (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257984#action_257984
 ] 

Gin-Ting Chen commented on SUREFIRE-690:


For now I'm testing with the value off but I can try it by using a lower value 
than I know a verbose (lots of output) test takes.

> testSetCompleted called before testSetStarting when using m3 parallel builds
> 
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
> Fix For: 2.7.3
>
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on 
> project hornet-stinger: Error while executing forked tests.; nested exception 
> is java.lang.IllegalStateException: testSetCompleted called before 
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously

-- 
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-318) Release plugin throws NullPointerException when using version range for dependency

2011-02-28 Thread Elliot Metsger (JIRA)


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

Elliot Metsger commented on MRELEASE-318:
-

I'm still getting an NPE with Maven 2.2.1 and Release Plugin 2.1.

Relavent POM snip:
  


  commons-codec
  commons-codec
  [1.2,)


...
  

Output:
mvn org.apache.maven.plugins:maven-release-plugin:2.1:prepare 
-DreleaseVersion=1.0.1-y2pilot -DdevelopmentVersion=1.0.2-y2pilot-SNAPSHOT 
-Dtag=1.0.1-y2pilot -DdryRun=true
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   common-services
[INFO]   dcs-id-api
[INFO]   dcs-id-impl
[INFO]   dcs-notify-api
[INFO]   dcs-notify-impl
[INFO]   Common DCS utilities
[INFO]   dcs-id-impl-hibernate
[INFO] 
[INFO] Building common-services
[INFO]task-segment: 
[org.apache.maven.plugins:maven-release-plugin:2.1:prepare] (aggregator-style)
[INFO] 
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO]   ignoring changes on: pom.xml.next, release.properties, 
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: /bin/sh -c cd 
/Users/esm/dc-svn/common-services/branches/y2pilot && svn --non-interactive 
status
[INFO] Working directory: /Users/esm/dc-svn/common-services/branches/y2pilot
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.
: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 
Dependency 'org.dataconservancy:project-pom' is a snapshot 
(1.0.1-y2pilot-SNAPSHOT)
: Which release version should it be set to? 1.0.1-y2pilot: : 
What version should the dependency be reset to for development? 1.0.1-y2pilot: 
: 1.0.2-y2pilot-SNAPSHOT
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] version was null for commons-codec:commons-codec
[INFO] 
[INFO] Trace
java.lang.NullPointerException: version was null for commons-codec:commons-codec
at 
org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at 
org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
at 
org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
at 
org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
at 
org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
at 
org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
at 
org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.simulate(CheckDependencySnapshotsPhase.java:290)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)

[jira] Commented: (MRELEASE-620) NPE on a range dependency

2011-02-28 Thread Elliot Metsger (JIRA)


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

Elliot Metsger commented on MRELEASE-620:
-

See my comment on MRELEASE-318: 
http://jira.codehaus.org/browse/MRELEASE-318?focusedCommentId=257983&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_257983

I still get an NPE with Maven 2.2.1 and Release plugin 2.1

> NPE on a range dependency
> -
>
> Key: MRELEASE-620
> URL: http://jira.codehaus.org/browse/MRELEASE-620
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: maven 2.2.1
>Reporter: Michal Politowski
> Attachments: pom.xml
>
>
> The symptoms are similar to MRELEASE-318 but using the 2.1 version which 
> should have it fixed.
> With the attached very minimal project
> mvn org.apache.maven.plugins:maven-release-plugin:2.1:prepare -DdryRun=true
> results in
> java.lang.NullPointerException: version was null for org.mortbay.jetty:jetty
> at 
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
> at 
> org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
> at 
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
> at 
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
> at 
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
> at 
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
> at 
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.simulate(CheckDependencySnapshotsPhase.java:290)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
> at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
> at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> 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)

-- 
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: (MECLIPSE-681) Bug while using addVersionToProjectName property

2011-02-28 Thread Ulrich Vachon (JIRA)

Bug while using addVersionToProjectName property


 Key: MECLIPSE-681
 URL: http://jira.codehaus.org/browse/MECLIPSE-681
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: Unbuntu 10.4, JDK-1.6.0_24, Eclipse Helios Service 
Release 1
Reporter: Ulrich Vachon
 Attachments: pom-all.xml

I had a side effect when I wanted to set to false the "addVersionToProjectName" 
plugin property. In fact, if the property is set to false, my Eclipse projects 
doesn't contains the version in project name, but the projects referenced 
contains the version.



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

[jira] Updated: (MECLIPSE-681) Bug while using addVersionToProjectName property

2011-02-28 Thread Ulrich Vachon (JIRA)


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

Ulrich Vachon updated MECLIPSE-681:
---

Attachment: project

> Bug while using addVersionToProjectName property
> 
>
> Key: MECLIPSE-681
> URL: http://jira.codehaus.org/browse/MECLIPSE-681
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.8
> Environment: Unbuntu 10.4, JDK-1.6.0_24, Eclipse Helios Service 
> Release 1
>Reporter: Ulrich Vachon
> Attachments: pom-all.xml, project
>
>
> I had a side effect when I wanted to set to false the 
> "addVersionToProjectName" plugin property. In fact, if the property is set to 
> false, my Eclipse projects doesn't contains the version in project name, but 
> the projects referenced contains the version.

-- 
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: (MECLIPSE-681) Bug while using addVersionToProjectName property

2011-02-28 Thread Ulrich Vachon (JIRA)


[ 
http://jira.codehaus.org/browse/MECLIPSE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257987#action_257987
 ] 

Ulrich Vachon commented on MECLIPSE-681:


ignore the pom-all.xml (attachment error)

> Bug while using addVersionToProjectName property
> 
>
> Key: MECLIPSE-681
> URL: http://jira.codehaus.org/browse/MECLIPSE-681
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.8
> Environment: Unbuntu 10.4, JDK-1.6.0_24, Eclipse Helios Service 
> Release 1
>Reporter: Ulrich Vachon
> Attachments: pom-all.xml, project
>
>
> I had a side effect when I wanted to set to false the 
> "addVersionToProjectName" plugin property. In fact, if the property is set to 
> false, my Eclipse projects doesn't contains the version in project name, but 
> the projects referenced contains the version.

-- 
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: (SUREFIRE-707) NullPointerException in ConcurrentReporterManager on testSkipped (@Ignore on test class)

2011-02-28 Thread Mark Renouf (JIRA)

NullPointerException in ConcurrentReporterManager on testSkipped (@Ignore on 
test class)


 Key: SUREFIRE-707
 URL: http://jira.codehaus.org/browse/SUREFIRE-707
 Project: Maven Surefire
  Issue Type: Bug
  Components: Junit 4.7+ (parallel) support
Affects Versions: 2.7.2
 Environment: $ mvn -version
Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500)
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"

Reporter: Mark Renouf


Captured using a custom RunListener, tracing to a file:

2011-02-28-13:30:02.137 TEST_FAILED   - Test mechanism: null
java.lang.NullPointerException
at 
org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testSkipped(ConcurrentReporterManager.java:107)
at 
org.apache.maven.surefire.common.junit4.JUnit4RunListener.testIgnored(JUnit4RunListener.java:68)
at 
org.junit.runner.notification.RunNotifier$6.notifyListener(RunNotifier.java:130)
at 
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at 
org.junit.runner.notification.RunNotifier.fireTestIgnored(RunNotifier.java:127)
at 
org.junit.internal.builders.IgnoredClassRunner.run(IgnoredClassRunner.java:19)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at 
org.apache.maven.surefire.junitcore.ConfigurableParallelComputer$AsynchronousRunner$1.call(ConfigurableParallelComputer.java:185)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)


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

[jira] Updated: (MJARSIGNER-13) signing in multi-module project fails on windows


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

Dennis Lundberg updated MJARSIGNER-13:
--

Description: 
I got multi-module (6 modules) android project with .pom file and "sign" 
profile defined. When I execute with 'sign' profile:
- in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
(mv  -rf) it signs another 3 modules and fails again. The reason for 
failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig failed.
- in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
"error code 1"


However, I tried the same .pom - everything works perfectly in Linux (Ubuntu). 

I was afraid that it might be the issue with spaces, so I hardcoded the paths - 
the error I got from maven than was:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
MyProject: Failed executing 'cmd.exe /X /C 
"C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
"C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
'*'debugkey"' - exitcode 1 -> [Help 1]
{noformat}


Attaching pom file which I am using.
Please help?

  was:
I got multi-module (6 modules) android project with .pom file and "sign" 
profile defined. When I execute with 'sign' profile:
- in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
(mv  -rf) it signs another 3 modules and fails again. The reason for 
failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig failed.
- in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
"error code 1"


However, I tried the same .pom - everything works perfectly in Linux (Ubuntu). 

I was afraid that it might be the issue with spaces, so I hardcoded the paths - 
the error I got from maven than was:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
MyProject: Failed executing 'cmd.exe /X /C 
"C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
"C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
'*'debugkey"' - exitcode 1 -> [Help 1]


Attaching pom file which I am using.
Please help?


> signing in multi-module project fails on windows
> 
>
> Key: MJARSIGNER-13
> URL: http://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk 
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign" 
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
> (mv  -rf) it signs another 3 modules and fails again. The reason for 
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig 
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux 
> (Ubuntu). 
> I was afraid that it might be the issue with spaces, so I hardcoded the paths 
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
> MyProject: Failed executing 'cmd.exe /X /C 
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?

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

[jira] Commented: (MJARSIGNER-13) signing in multi-module project fails on windows


[ 
http://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258008#action_258008
 ] 

Dennis Lundberg commented on MJARSIGNER-13:
---

What is the error message you get from jarsigner if you run it directly from 
the command line?

{noformat}
cmd.exe /X /C "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe 
-verbose -keystore "C:\tmp\debug.keystore" -storepass '*' -keypass '*' 
xxx.jar '*'debugkey"
{noformat}
 

> signing in multi-module project fails on windows
> 
>
> Key: MJARSIGNER-13
> URL: http://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk 
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign" 
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
> (mv  -rf) it signs another 3 modules and fails again. The reason for 
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig 
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux 
> (Ubuntu). 
> I was afraid that it might be the issue with spaces, so I hardcoded the paths 
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
> MyProject: Failed executing 'cmd.exe /X /C 
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?

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

[jira] Commented: (MJARSIGNER-13) signing in multi-module project fails on windows

2011-02-28 Thread Anna Gadomska (JIRA)


[ 
http://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258010#action_258010
 ] 

Anna Gadomska commented on MJARSIGNER-13:
-

Dennis, it works fine when I call it from command line, separately for every 
module

> signing in multi-module project fails on windows
> 
>
> Key: MJARSIGNER-13
> URL: http://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk 
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign" 
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
> (mv  -rf) it signs another 3 modules and fails again. The reason for 
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig 
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux 
> (Ubuntu). 
> I was afraid that it might be the issue with spaces, so I hardcoded the paths 
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
> MyProject: Failed executing 'cmd.exe /X /C 
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?

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

[jira] Commented: (MJARSIGNER-13) signing in multi-module project fails on windows


[ 
http://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258013#action_258013
 ] 

Dennis Lundberg commented on MJARSIGNER-13:
---

OK, what about from the parent?

> signing in multi-module project fails on windows
> 
>
> Key: MJARSIGNER-13
> URL: http://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk 
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign" 
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
> (mv  -rf) it signs another 3 modules and fails again. The reason for 
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig 
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux 
> (Ubuntu). 
> I was afraid that it might be the issue with spaces, so I hardcoded the paths 
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
> MyProject: Failed executing 'cmd.exe /X /C 
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?

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

[jira] Commented: (MJARSIGNER-13) signing in multi-module project fails on windows


[ 
http://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258015#action_258015
 ] 

Dennis Lundberg commented on MJARSIGNER-13:
---

Also you can try to run mvn with the -X command line option to run in debug 
mode. Hopefully you'll get a helpful error message or stack trace at the end.

> signing in multi-module project fails on windows
> 
>
> Key: MJARSIGNER-13
> URL: http://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk 
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign" 
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution 
> (mv  -rf) it signs another 3 modules and fails again. The reason for 
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig 
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns 
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux 
> (Ubuntu). 
> I was afraid that it might be the issue with spaces, so I hardcoded the paths 
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project 
> MyProject: Failed executing 'cmd.exe /X /C 
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore 
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar 
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?

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

[jira] Created: (MNG-5029) Defining a mirror invalidates local repository content

2011-02-28 Thread Henrik Lynggaard (JIRA)

Defining a mirror invalidates local repository content
--

 Key: MNG-5029
 URL: http://jira.codehaus.org/browse/MNG-5029
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0.2
 Environment: ubuntu, maven 3.0.2
Reporter: Henrik Lynggaard
Priority: Critical


If I define a mirror in settings.xml, maven can no longer find artifacts which 
are allready in the local repository.

Steps to reproduce.
1. Create simple pom like
http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
  4.0.0
  dk.hlyh.par
  par
  1.0
  pom
  par


2. make sure  setting.xml has no mirrors
3. build using mvn -o install (which completes succssfully, hence all artifacts 
available locally)

4. add mirror to settings.xml (mirror must be of * or central)
5. rebuild using mvn -o install

expected result:
* the build completes without error

actual result:
Build fails with:
[ERROR] Plugin org.apache.maven.plugins:maven-install-plugin:2.3.1 or one of 
its dependencies could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-install-plugin:jar:2.3.1: The repository system 
is offline but the artifact 
org.apache.maven.plugins:maven-install-plugin:pom:2.3.1 is not available in the 
local repository.

but given step 3 above I know all required artifacts are available locally, 
hence the build should not fail.




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

[jira] Closed: (MNG-5029) Defining a mirror invalidates local repository content


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

Benjamin Bentmann closed MNG-5029.
--

Resolution: Not A Bug
  Assignee: Benjamin Bentmann

This works as intended. A mirror is technically a different repository. Until 
Maven has verified that it actually provides the artifacts in question (i.e. by 
running an online build using the mirror), the artifacts that have previously 
cached from the original repository won't be accessible to the build.

> Defining a mirror invalidates local repository content
> --
>
> Key: MNG-5029
> URL: http://jira.codehaus.org/browse/MNG-5029
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.2
> Environment: ubuntu, maven 3.0.2
>Reporter: Henrik Lynggaard
>Assignee: Benjamin Bentmann
>Priority: Critical
>
> If I define a mirror in settings.xml, maven can no longer find artifacts 
> which are allready in the local repository.
> Steps to reproduce.
> 1. Create simple pom like
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
>   dk.hlyh.par
>   par
>   1.0
>   pom
>   par
> 
> 2. make sure  setting.xml has no mirrors
> 3. build using mvn -o install (which completes succssfully, hence all 
> artifacts available locally)
> 4. add mirror to settings.xml (mirror must be of * or central)
> 5. rebuild using mvn -o install
> expected result:
> * the build completes without error
> actual result:
> Build fails with:
> [ERROR] Plugin org.apache.maven.plugins:maven-install-plugin:2.3.1 or one of 
> its dependencies could not be resolved: Failed to read artifact descriptor 
> for org.apache.maven.plugins:maven-install-plugin:jar:2.3.1: The repository 
> system is offline but the artifact 
> org.apache.maven.plugins:maven-install-plugin:pom:2.3.1 is not available in 
> the local repository.
> but given step 3 above I know all required artifacts are available locally, 
> hence the build should not fail.

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

[jira] Closed: (SCM-611) AccuRev - call replica sync before export

2011-02-28 Thread Olivier Lamy (JIRA)


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

Olivier Lamy closed SCM-611.


Resolution: Fixed

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

> AccuRev - call replica sync before export
> -
>
> Key: SCM-611
> URL: http://jira.codehaus.org/browse/SCM-611
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-provider-accurev
>Affects Versions: 1.5
>Reporter: Grant Gardner
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SCM-611.patch
>
>
> When using the AccuRev 4.9 feature that allows export of a specific version 
> (transaction id), this will fail if you are using a replica server where this 
> transaction is not available.
> This appears for me in the[Bamboo maven scm 
> integration|https://studio.plugins.atlassian.com/wiki/display/BMSCM/Home] 
> since Bamboo does its change detection against the AccuRev master server and 
> passes the top transaction id to an agent which exports the code from an 
> AccuRev replica.
> Unfortunately there isn't a nice way to detect if you are using a replica, 
> apart from seeing a warning message when you try to sync so fix is to just 
> always call replica sync and ignore any errors.

-- 
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-5030) Provide a way to get a raw XML for plugin to read

2011-02-28 Thread Evgeny Goldin (JIRA)

Provide a way to get a raw  XML for plugin to read
-

 Key: MNG-5030
 URL: http://jira.codehaus.org/browse/MNG-5030
 Project: Maven 2 & 3
  Issue Type: New Feature
  Components: Plugin API
Affects Versions: 3.0.2
Reporter: Evgeny Goldin


As a plugin author I may need to read its *{{}}* slightly 
different than Maven does it. It would be very nice to get a raw XML as an 
alternative to standard fields injection.

-- 
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-5030) Provide a way to get a raw XML for plugin to read