[jira] Created: (MNG-2135) multi-project build that creates it's own plugins needs bootstrapping

[Frank Cornelis (JIRA)]

multi-project build that creates it's own plugins needs bootstrapping
-

 Key: MNG-2135
 URL: http://jira.codehaus.org/browse/MNG-2135
 Project: Maven 2
Type: Bug

  Components: Dependencies  
Versions: 2.0.2
Reporter: Frank Cornelis


I have a multi-project build. Some of the artifacts are maven-plugins. Other 
artifacts depends on these plugins. For some reason the current Maven2 is not 
correctly doing the dependency check before building to see whether the 
artifacts in the multi-project build depend on other maven-plugin artifacts 
within the same multi-project build. 
For now I solved the issue by using a second parent pom to bootstrap the build. 
This bootstrap parent pom is creating all the plugins. Afterwards, I can use my 
normal parent pom to build all artifacts.
It would be nice that Maven2 could do the 'bootstrap build' himself.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Emmanuel Venisse (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60445 ] 

Emmanuel Venisse commented on MNG-2127:
---

choice command is available only with ms resource kit

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Fix For: 2.0.3
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Christian Schulte (JIRA)]

Surefire forkMode not working on windows [patch attached]
-

 Key: MSUREFIRE-76
 URL: http://jira.codehaus.org/browse/MSUREFIRE-76
 Project: Maven 2.x Surefire Plugin
Type: Bug

Reporter: Christian Schulte
 Attachments: win.patch

On windows all forkModes other than none are not working. This is because 
surefire-booter writes the classpath into some property file using ':' as the 
separator. This is not working since on windows all absolute paths contain the 
drive letter followed by ':'. The attached patch changes ':' to '^'. After 
applying forkMode starts working on windows.


-- 
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: (MPMULTIPROJECT-64) goal multiproject:create-nav seems to have lost pom.id

[Benoit Xhenseval (JIRA)]

[ 
http://jira.codehaus.org/browse/MPMULTIPROJECT-64?page=comments#action_60447 ] 

Benoit Xhenseval commented on MPMULTIPROJECT-64:


Hi Lukas

It happens with both.

multiproject:create-nav:
[echo] POM.id INSIDE create-nav objectlab:gui and multi [Troy Common, Troy 
JBoss Ext, Troy Persist, Troy Server, Troy EJB, Troy EJB Acceptance, Troy GUI]
[echo] You must exclude objectlab:gui (the top level project) from the 
subproject set
[echo] Producing independent navigation...
[echo] Producing user supplied navigation...

Benoit

> goal multiproject:create-nav seems to have lost pom.id
> --
>
>  Key: MPMULTIPROJECT-64
>  URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-64
>  Project: maven-multiproject-plugin
> Type: Bug

> Versions: 1.4.1
>  Environment: maven 1.0.2 but with a couple of plugins upgraded to latest 
> HEAD.
> Reporter: Benoit Xhenseval

>
>
> Today I have upgraded the checkstyle plugin to 3.0 from 2.6
> This seems to have downloaded a couple of libraries and I now have a strange 
> behaviour for multiproject.
> I have also upgraded PMD to 1.8-SNAPSHOT but the following issue appeared 
> before:
> When I run "maven multiproject:site", the reactor goes through all 
> sub-projects ok BUT when it reaches the call to  name="multiproject:create-nav"/>, it seems to lose the pom.id and declares 
> that I must exclude the  (the top level project" (see line 140 in th 
> eplugin.jelly).
> , which is the pom.id, is replaced by the LAST project contained in the 
> variable ${multiprojects}.
> the pom.id seems to have changed between the line just BEFORE the call to 
> multiproject:create-nav and the FIRST line inside create-nav.
> If I modify the code to add some log:
> POM.id before calling create-nav ${pom.id}
> 
> ...
>  
>prereqs="multiproject:site-init">
>  
> POM.id INSIDE create-nav ${pom.id} and multi ${multiprojects}
> 
> POM.id INSIDE LOOP create-nav ${pom.id} and current 
> ${reactorProject.id}
>   
> 
>   
> 
>  
> The pom.id has changed between the first 2 echos.  it then matches the last 
> reactorProject.id and th ewhole process fails.
> I do not understand why the pom.id is changed somewhere in 
> multiproject:site-init...
> My current workaround is to change the  process can finish (but it does not generate a proper navigation.xml)
> There is obviously something wrong introduced by the latest download of a 
> couple of plugin, I still have maven 1.0.2
> Is there a way I could list all plugins and version?  I would post it here...
> Thanks for looking into it.
> Benoit

-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Dan Tran (JIRA)]

[ http://jira.codehaus.org/browse/MSUREFIRE-76?page=comments#action_60450 ] 

Dan Tran commented on MSUREFIRE-76:
---

http://jira.codehaus.org/browse/SUREFIRE-30 related?


> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
>  Attachments: win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

-- 
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: (MPRELEASE-18) Wrong username during release:prepare tagging

[Niclas Hedhman (JIRA)]

Wrong username during release:prepare tagging
-

 Key: MPRELEASE-18
 URL: http://jira.codehaus.org/browse/MPRELEASE-18
 Project: maven-release-plugin
Type: Bug

Reporter: Niclas Hedhman


If I my Svn repository requires a different username than the login name, and I 
issue 

   mvn [EMAIL PROTECTED] release:prepare

The first phase (checking in modified POMs) will succeed with that username.

Then somewhere between that point and writing out the release.properties file, 
the user name falls back to the login name (in my case "niclas"), which is 
written into the release.properties file, and used during the tagging of the 
repository.

Now, looking at the source, I think that is unwise to keep a username both in 
the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that 
there is some type of sequencing problem in there.

WORKAROUND;
Before starting the release:prepare, create a release.properties file manually 
which contains

  [EMAIL PROTECTED]

and everything will work.


-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Grzegorz Slowikowski (JIRA)]

[ http://jira.codehaus.org/browse/MSUREFIRE-76?page=comments#action_60456 ] 

Grzegorz Slowikowski commented on MSUREFIRE-76:
---

Yes, it is the same issue

> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
>  Attachments: win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

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

[jira] Moved: (MRELEASE-83) Wrong username during release:prepare tagging

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MRELEASE-83?page=all ]

Lukas Theussl moved MPRELEASE-18 to MRELEASE-83:


Workflow: Maven  (was: jira)
 Key: MRELEASE-83  (was: MPRELEASE-18)
 Project: Maven 2.x Release Plugin  (was: maven-release-plugin)

> Wrong username during release:prepare tagging
> -
>
>  Key: MRELEASE-83
>  URL: http://jira.codehaus.org/browse/MRELEASE-83
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Reporter: Niclas Hedhman

>
>
> If I my Svn repository requires a different username than the login name, and 
> I issue 
>mvn [EMAIL PROTECTED] release:prepare
> The first phase (checking in modified POMs) will succeed with that username.
> Then somewhere between that point and writing out the release.properties 
> file, the user name falls back to the login name (in my case "niclas"), which 
> is written into the release.properties file, and used during the tagging of 
> the repository.
> Now, looking at the source, I think that is unwise to keep a username both in 
> the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that 
> there is some type of sequencing problem in there.
> WORKAROUND;
> Before starting the release:prepare, create a release.properties file 
> manually which contains
>   [EMAIL PROTECTED]
> and everything will work.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2127?page=all ]
 
Brett Porter closed MNG-2127:
-

 Resolution: Won't Fix
Fix Version: (was: 2.0.3)

this is a misunderstanding. I'm assuming you tested your fix by checking if 
errorlevel 1 echo something

the missing if errorlevel 1 was already added to svn, and I've fixed the 
location of the original setting of ERROR_CODE. Not using ERROR_CODE still 
works, setting the errorlevel correctly, but should the script change to have 
an intervening command that resets it this would be lost so it is good to keep, 
plus it allows returning "1" for the failure to set JAVA_HOME, etc.

Emmanuel was entirely correct, and you'll find running the new script inside 
Ant still succeeds, as does running Ant inside Ant. The reason for this is that 
batch files are called like this:
cmd /c mvn.bat

The exit code of mvn.bat is swallowed by cmd.exe. However, if you use the 
"exit" command, cmd.exe is terminated with the correct exit code. There doesn't 
appear to be any alternative to this at this point. I'll keep looking.

I test this on both XP SP2 and XP SP1a. We don't support Win9x.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60459 ] 

Brett Porter commented on MNG-2127:
---

Ant should be using:

cmd /C call mvn.bat

instead, though it doesn't know that it's a batch file, I assume.

Emmanuel, can we do this in Continuum to ensure the correct result?

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60460 ] 

Brett Porter commented on MNG-2127:
---

It looks like we could add that to setDefaultShell() in plexus utils for 
continuum to fix it permanently.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Emmanuel Venisse (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60461 ] 

Emmanuel Venisse commented on MNG-2127:
---

ant doesn't use cmd /C call ...

it use cmd /C cd DIR && command for Windows XP/2000/NT
and it use an external launcher (antrun.bat for windows 95/98

http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java

I'm not sure cmd /C call ... will return the correct result and in continuum we 
always get the correct result.


> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[Vincent Massol (JIRA)]

Active profile in profiles.xml prevents active profile in pom.xml to be 
triggered automatically
---

 Key: MNG-2136
 URL: http://jira.codehaus.org/browse/MNG-2136
 Project: Maven 2
Type: Bug

  Components: POM  
Versions: 2.0.3
Reporter: Vincent Massol


If there's a profiles.xml with an active profile in it, then the active profile 
defined in the pom.xml is ignored and not triggered.


-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60462 ] 

Brett Porter commented on MNG-2127:
---

I know ant doesn't, and I'm saying ant doesn't work here either. cmd /C still 
swallows the result.

Continuum works by setting the TERMINATE_CMD, without requiring any user 
intervention? What about if it calls m1, or ant?

I think cmd /c call is cleaner if that works...

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Emmanuel Venisse (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60464 ] 

Emmanuel Venisse commented on MNG-2127:
---

ok, i'll look at it.

Actually,  Continuum works by setting the MAVEN_TERMINATE_CMD, without 
requiring any user intervention. For ant, we have a modified script on 
continuum site. m1 script use MAVEN_TERMINATE_CMD

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Christian Schulte (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-76?page=all ]
 
Christian Schulte closed MSUREFIRE-76:
--

Resolution: Duplicate

SUREFIRE-30

> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
>  Attachments: win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Christian Schulte (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-76?page=all ]

Christian Schulte updated MSUREFIRE-76:
---

Attachment: system.getproperty.path.separator.patch

> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
>  Attachments: system.getproperty.path.separator.patch, win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

-- 
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] Reopened: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Christian Schulte (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-76?page=all ]
 
Christian Schulte reopened MSUREFIRE-76:



Attached a patch using System.getProperty("path.separator") as the separator.

> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
>  Attachments: system.getproperty.path.separator.patch, win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

-- 
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: (MSUREFIRE-77) Service providers are not available during unit testing when defined by dependencies

[Christian Schulte (JIRA)]

Service providers are not available during unit testing when defined by 
dependencies


 Key: MSUREFIRE-77
 URL: http://jira.codehaus.org/browse/MSUREFIRE-77
 Project: Maven 2.x Surefire Plugin
Type: Bug

Reporter: Christian Schulte


If a dependency defines some service provider by e.g. a file like  
META-INF/services/java.nio.charset.spi.CharsetProvider these providers are not 
available during unit testing. For this example an UnsupportedEncodingException 
would be thrown when using a charset defined in the file during unit testing. 
For Reference see: 
 or 
.


-- 
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: (MPMULTIPROJECT-64) goal multiproject:create-nav seems to have lost pom.id

[Lukas Theussl (JIRA)]

[ 
http://jira.codehaus.org/browse/MPMULTIPROJECT-64?page=comments#action_60469 ] 

Lukas Theussl commented on MPMULTIPROJECT-64:
-

Any chance that you could attach a small test project? I remember having seen 
this issue once but I can't reproduce it anymore now.

> goal multiproject:create-nav seems to have lost pom.id
> --
>
>  Key: MPMULTIPROJECT-64
>  URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-64
>  Project: maven-multiproject-plugin
> Type: Bug

> Versions: 1.4.1
>  Environment: maven 1.0.2 but with a couple of plugins upgraded to latest 
> HEAD.
> Reporter: Benoit Xhenseval

>
>
> Today I have upgraded the checkstyle plugin to 3.0 from 2.6
> This seems to have downloaded a couple of libraries and I now have a strange 
> behaviour for multiproject.
> I have also upgraded PMD to 1.8-SNAPSHOT but the following issue appeared 
> before:
> When I run "maven multiproject:site", the reactor goes through all 
> sub-projects ok BUT when it reaches the call to  name="multiproject:create-nav"/>, it seems to lose the pom.id and declares 
> that I must exclude the  (the top level project" (see line 140 in th 
> eplugin.jelly).
> , which is the pom.id, is replaced by the LAST project contained in the 
> variable ${multiprojects}.
> the pom.id seems to have changed between the line just BEFORE the call to 
> multiproject:create-nav and the FIRST line inside create-nav.
> If I modify the code to add some log:
> POM.id before calling create-nav ${pom.id}
> 
> ...
>  
>prereqs="multiproject:site-init">
>  
> POM.id INSIDE create-nav ${pom.id} and multi ${multiprojects}
> 
> POM.id INSIDE LOOP create-nav ${pom.id} and current 
> ${reactorProject.id}
>   
> 
>   
> 
>  
> The pom.id has changed between the first 2 echos.  it then matches the last 
> reactorProject.id and th ewhole process fails.
> I do not understand why the pom.id is changed somewhere in 
> multiproject:site-init...
> My current workaround is to change the  process can finish (but it does not generate a proper navigation.xml)
> There is obviously something wrong introduced by the latest download of a 
> couple of plugin, I still have maven 1.0.2
> Is there a way I could list all plugins and version?  I would post it here...
> Thanks for looking into it.
> Benoit

-- 
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: (WAGONSSH-43) SFTP as used by site-deploy, causes mkdir command to be executed

[Stephen Duncan Jr (JIRA)]

SFTP as used by site-deploy, causes mkdir command to be executed


 Key: WAGONSSH-43
 URL: http://jira.codehaus.org/browse/WAGONSSH-43
 Project: wagon-ssh
Type: Improvement

Versions: 1.0-alpha-6
Reporter: Stephen Duncan Jr
Priority: Critical


I'm trying to run mvn site-deploy with an sftp:// url.  The remote system 
provided a limited shell for my user account that allows cvs & sftp.  This 
works for mvn deploy to deploy jars, etc., even when it needs to create a 
directory to copy the file up.  The site plugin, however, must call a different 
wagon method that causes the following command to be executed:

Executing command: mkdir -p 
/var/www/sites/cdcie-parent-core/cdcie-parent-webapp/cdcie-webapp-troubletickets/.

To be able to deploy my site, I need an sftp:// url to strictly use only sftp 
as is done by mvn deploy.  

-- 
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: (MPMULTIPROJECT-64) goal multiproject:create-nav seems to have lost pom.id

[Arnaud Heritier (JIRA)]

[ 
http://jira.codehaus.org/browse/MPMULTIPROJECT-64?page=comments#action_60471 ] 

Arnaud Heritier commented on MPMULTIPROJECT-64:
---

I encountered it just before http://jira.codehaus.org/browse/MAVEN-1750
I think that you can reproduce it if you run multiproject:site in the 
plugins-site project
The last plugin fails saying "You must exclude ..."

> goal multiproject:create-nav seems to have lost pom.id
> --
>
>  Key: MPMULTIPROJECT-64
>  URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-64
>  Project: maven-multiproject-plugin
> Type: Bug

> Versions: 1.4.1
>  Environment: maven 1.0.2 but with a couple of plugins upgraded to latest 
> HEAD.
> Reporter: Benoit Xhenseval

>
>
> Today I have upgraded the checkstyle plugin to 3.0 from 2.6
> This seems to have downloaded a couple of libraries and I now have a strange 
> behaviour for multiproject.
> I have also upgraded PMD to 1.8-SNAPSHOT but the following issue appeared 
> before:
> When I run "maven multiproject:site", the reactor goes through all 
> sub-projects ok BUT when it reaches the call to  name="multiproject:create-nav"/>, it seems to lose the pom.id and declares 
> that I must exclude the  (the top level project" (see line 140 in th 
> eplugin.jelly).
> , which is the pom.id, is replaced by the LAST project contained in the 
> variable ${multiprojects}.
> the pom.id seems to have changed between the line just BEFORE the call to 
> multiproject:create-nav and the FIRST line inside create-nav.
> If I modify the code to add some log:
> POM.id before calling create-nav ${pom.id}
> 
> ...
>  
>prereqs="multiproject:site-init">
>  
> POM.id INSIDE create-nav ${pom.id} and multi ${multiprojects}
> 
> POM.id INSIDE LOOP create-nav ${pom.id} and current 
> ${reactorProject.id}
>   
> 
>   
> 
>  
> The pom.id has changed between the first 2 echos.  it then matches the last 
> reactorProject.id and th ewhole process fails.
> I do not understand why the pom.id is changed somewhere in 
> multiproject:site-init...
> My current workaround is to change the  process can finish (but it does not generate a proper navigation.xml)
> There is obviously something wrong introduced by the latest download of a 
> couple of plugin, I still have maven 1.0.2
> Is there a way I could list all plugins and version?  I would post it here...
> Thanks for looking into it.
> Benoit

-- 
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-2137) Allow plugin-registry.xml path to be specified on command line or via settings.xml

[John Allen (JIRA)]

Allow plugin-registry.xml path to be specified on command line or via 
settings.xml
--

 Key: MNG-2137
 URL: http://jira.codehaus.org/browse/MNG-2137
 Project: Maven 2
Type: Improvement

Reporter: John Allen
Priority: Minor




-- 
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-92) site:stage fails, goal not found

[Nicolas Peeters (JIRA)]

[ http://jira.codehaus.org/browse/MSITE-92?page=comments#action_60473 ] 

Nicolas Peeters commented on MSITE-92:
--

Hi,

Any idea in which release that feature will be avaible?
Thank you.

Nicolas

> site:stage fails, goal not found
> 
>
>  Key: MSITE-92
>  URL: http://jira.codehaus.org/browse/MSITE-92
>  Project: Maven 2.x Site Plugin
> Type: Bug

>  Environment: Maven 2.0.2
> Reporter: Howard M. Lewis Ship
> Assignee: Brett Porter

>
>
> The documentation for "site:stage" is unclear; it appears to be something 
> that will build my site to a particular directory?  In trying to test it out, 
> to see what it does, I found out that it does not work.
> bash-3.00$ mvn site:stage
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'site'.
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Required goal not found: site:stage
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Feb 16 18:57:01 PST 2006
> [INFO] Final Memory: 2M/5M
> [INFO] 
> 
> bash-3.00$

-- 
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: (MNG-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[John Casey (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2136?page=all ]

John Casey updated MNG-2136:


   Priority: Blocker  (was: Major)
Fix Version: 2.0.3

upgrading to blocker to make sure this is resolved before we release.

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
> Priority: Blocker
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[John Casey (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2136?page=comments#action_60474 ] 

John Casey commented on MNG-2136:
-

do these two profiles have the same id? How is the profile in the POM triggered?

Can you provide a test case, so we know when this is fixed?

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[Vincent Massol (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2136?page=comments#action_60477 ] 

Vincent Massol commented on MNG-2136:
-

Heer's the profiles.xml:

{code:xml}

  

  vmassol
  
c:/apps/cargo-installs
  

  
  
vmassol
  

{code}

Here's a portion of the pom.xml:

{code:xml}
[...]
  


  jboss4x
  
true
  
  
jboss4x
  
  

  
org.codehaus.cargo
cargo-maven2-plugin

  

  
http://ovh.dl.sourceforge.net/sourceforge/jboss/jboss-4.0.2.zip
  ${installDir}

  

  

  

[...]
{code}

if I type "mvn install" the jboss4x profile is not activated. Removing 
profiles.xml makes it work. Forcing it using -Pjboss4x makes it active too (as 
would be expected).

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
> Priority: Blocker
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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: (CONTINUUM-610) Add section about building recursively from parent to FAQ and provide more information on adding shell projects

[Mang Lau (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-610?page=all ]

Mang Lau updated CONTINUUM-610:
---

Attachment: shell-info.patch

> Add section about building recursively from parent to FAQ and provide more 
> information on adding shell projects
> ---
>
>  Key: CONTINUUM-610
>  URL: http://jira.codehaus.org/browse/CONTINUUM-610
>  Project: Continuum
> Type: Improvement

>   Components: Documentation
> Reporter: Mang Lau
> Priority: Minor
>  Attachments: shell-info.patch, site-changes.patch
>
>
> Updated the following:
> about.fml
> - updated "How do I write documentation for Continuum?" section
> faq.fml
> - added section about building recursively from parent
> *Note:* I had the same [issue|http://jira.codehaus.org/browse/CONTINUUM-506] 
> as Dennis when generating the site.
> getting started - index.apt
> - provided more detail on adding shell projects

-- 
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-2037) Strange NPE with profile and injectPlugins

[Renaud Julienne (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2037?page=comments#action_60479 ] 

Renaud Julienne commented on MNG-2037:
--

I had the same issue and found a workaround.
In the profile build section, just add an empty pluginManagement section.

>From org.apache.maven.project.injection.DefaultProfileInjector
122 injectPlugins( profileBuild, modelBuild );
123 
124 // Plugin management :: aggregate
125 PluginManagement profilePM = 
profileBuild.getPluginManagement();  /** ==> this is what leads to 
NullPointerException in the following injectPlugins call **/
126 PluginManagement modelPM = modelBuild.getPluginManagement();
127 
128 if ( modelPM == null )
129 {
130 modelBuild.setPluginManagement( profilePM );
131 }
132 else
133 {
134 injectPlugins( profilePM, modelPM );
135 }

> Strange NPE with profile and injectPlugins
> --
>
>  Key: MNG-2037
>  URL: http://jira.codehaus.org/browse/MNG-2037
>  Project: Maven 2
> Type: Bug

> Versions: 2.0.2
>  Environment: solaris and windowns
> Reporter: Olivier Lamy
> Assignee: John Casey
> Priority: Blocker
>  Fix For: 2.0.3
>  Attachments: fullstack.log, pom_changeip.xml
>
>
> I use the war plugin with a default configuration :
> 
>   maven-war-plugin
>   
>  implementation="java.io.File">${basedir}/src/main/web
> ${basedir}/src/main/resources/war/web.xml 
>  implementation="java.io.File">${basedir}/webappdir
>   
>  
> And a profile with only 
> 
>   rec-ap2
>   
> 
>   
> maven-war-plugin
> 
>implementation="java.io.File">/local/tomcat/jakarta-tomcat-5.5.9/webapps/SLSTester
> 
>   
>  
>
> 
> mvn -P rec-ap2 -X -e war:exploded generate the NPE :
> + Error stacktraces are turned on. 
> [DEBUG] Building Maven user-level plugin registry from: 
> '/local/tomcat/.m2/plugin-registry.xml' 
> [DEBUG] Building Maven global-level plugin registry from: 
> '/local/maven/maven-2.0.2/conf/plugin-registry.xml' 
> [INFO] Scanning for projects... 
> [INFO] 
>  
> [ERROR] FATAL ERROR 
> [INFO] 
>  
> [INFO] null 
> [INFO] 
>  
> [DEBUG] Trace 
> java.lang.NullPointerException 
> at 
> org.apache.maven.project.injection.DefaultProfileInjector.injectPlugins(DefaultProfileInjector.java:147)
>  
> at 
> org.apache.maven.project.injection.DefaultProfileInjector.injectBuild(DefaultProfileInjector.java:134)
>  
> at 
> org.apache.maven.project.injection.DefaultProfileInjector.inject(DefaultProfileInjector.java:80)
>  
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.injectActiveProfiles(DefaultMavenProjectBuilder.java:1035)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:836)
>  
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:593)
>  
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:303)
>  
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274)
>  
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) 
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) 
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) 
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) 
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) 
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 
> 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) 
> [INFO] 
>  
> [INFO] Total time: < 1 second 
> [INFO] Finished at: Fri Feb 03 23:39:41 MET 2006 
> [INFO] Final Memory: 2M/126M 
> [INFO] 
> ---

[jira] Created: (MPECLIPSE-112) Resource targetPath is relative to the project's output directory.

[Emanuel Bulic (JIRA)]

Resource targetPath is relative to the project's output directory.
--

 Key: MPECLIPSE-112
 URL: http://jira.codehaus.org/browse/MPECLIPSE-112
 Project: maven-eclipse-plugin
Type: Bug

Reporter: Emanuel Bulic


I am using the following resource:
  

  
data/core/beanconfig
.

   *target/**



  

Also, the eclipse plugin is configured to use a different outputDirectory:
  
maven-eclipse-plugin

  eclipse-target   

  

The classpath entry for the resource above should be relative to the project's 
output path:
  

The pluging generates the wrong entry:
  

The output classpath entry is correct:
  



-- 
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: (MPECLIPSE-112) Resource targetPath is relative to the project's output directory.

[Emanuel Bulic (JIRA)]

[ http://jira.codehaus.org/browse/MPECLIPSE-112?page=comments#action_60481 
] 

Emanuel Bulic commented on MPECLIPSE-112:
-

I traced the issue to org.apache.maven.plugin.eclipse.EclipseUtils.

> Resource targetPath is relative to the project's output directory.
> --
>
>  Key: MPECLIPSE-112
>  URL: http://jira.codehaus.org/browse/MPECLIPSE-112
>  Project: maven-eclipse-plugin
> Type: Bug

> Reporter: Emanuel Bulic

>
>
> I am using the following resource:
>   
> 
>   
> data/core/beanconfig
> .
> 
>*target/**
> 
> 
> 
>   
> Also, the eclipse plugin is configured to use a different outputDirectory:
>   
> maven-eclipse-plugin
> 
>   eclipse-target   
> 
>   
> The classpath entry for the resource above should be relative to the 
> project's output path:
>output="eclipse-target/data/core/beanconfig"/>
> The pluging generates the wrong entry:
>   
> The output classpath entry is correct:
>   

-- 
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: (CONTINUUM-620) Changes section in Continuum build result and build e-mail only show blank columns and file names

[Emmanuel Venisse (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-620?page=all ]
 
Emmanuel Venisse closed CONTINUUM-620:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Fixed in maven-SCM. I'm not sure for Starteam because we don't have a TCK for 
it.

> Changes section in Continuum build result and build e-mail only show blank 
> columns and file names
> -
>
>  Key: CONTINUUM-620
>  URL: http://jira.codehaus.org/browse/CONTINUUM-620
>  Project: Continuum
> Type: Bug

>   Components: Web interface, Core system
> Versions: 1.0.3
>  Environment: Using the version from continuum-20060306.143000.tar.gz
> Windows XP SP2
> Reporter: Mang Lau
> Assignee: Emmanuel Venisse
>  Fix For: 1.0.3

>
>
> The Changes section in the build results screen show 3 blank columns and the 
> name of the changed file in the 4th column.  This is also true in the build 
> e-mail Continuum sends out after the build.  I believe that the columns are 
> supposed to show the author and any check-in comments from the SCM.

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

[jira] Moved: (MECLIPSE-77) Resource targetPath is relative to the project's output directory.

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MECLIPSE-77?page=all ]

Lukas Theussl moved MPECLIPSE-112 to MECLIPSE-77:
-

Workflow: Maven  (was: jira)
 Key: MECLIPSE-77  (was: MPECLIPSE-112)
 Project: Maven 2.x Eclipse Plugin  (was: maven-eclipse-plugin)

> Resource targetPath is relative to the project's output directory.
> --
>
>  Key: MECLIPSE-77
>  URL: http://jira.codehaus.org/browse/MECLIPSE-77
>  Project: Maven 2.x Eclipse Plugin
> Type: Bug

> Reporter: Emanuel Bulic

>
>
> I am using the following resource:
>   
> 
>   
> data/core/beanconfig
> .
> 
>*target/**
> 
> 
> 
>   
> Also, the eclipse plugin is configured to use a different outputDirectory:
>   
> maven-eclipse-plugin
> 
>   eclipse-target   
> 
>   
> The classpath entry for the resource above should be relative to the 
> project's output path:
>output="eclipse-target/data/core/beanconfig"/>
> The pluging generates the wrong entry:
>   
> The output classpath entry is correct:
>   

-- 
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-2124) Incorrect resolution of parent POM properties

[John Casey (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2124?page=all ]
 
John Casey closed MNG-2124:
---

Resolution: Fixed

see it0088 and it0100 (it0100 has the test case provided in this report, 
slightly modified to fit the integration testing framework).

> Incorrect resolution of parent POM properties
> -
>
>  Key: MNG-2124
>  URL: http://jira.codehaus.org/browse/MNG-2124
>  Project: Maven 2
> Type: Bug

>   Components: Inheritence and Interpolation
> Versions: 2.0.2
>  Environment: Windows XP, JDK 1.4.2_11
> Reporter: Kjetil Ødegaard
> Assignee: John Casey
> Priority: Blocker
>  Fix For: 2.0.3
>  Attachments: maven-bug.zip
>
>
> Unzip maven-bug to current dir and cd to maven-bug/artifact.
> Now, Maven 2.0.1 handles things correctly (irrelevant output removed):
> {code}[echo] Parent: parentartifact, project: artifact{code}
> But Maven 2.0.2 has a bug:
> {code}[echo] Parent: artifact, project: artifact{code}

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

[jira] Commented: (ARCHETYPE-25) images gif/jpgs etc seem to get corrupted when copied by archetype

[Chris Funk (JIRA)]

[ http://jira.codehaus.org/browse/ARCHETYPE-25?page=comments#action_60487 ] 

Chris Funk commented on ARCHETYPE-25:
-

I think it is a bit more complicated than that.

I did the following primitive hack to the process template method and still 
have the same issue, it seems there might be something about copying images out 
of a jar resource.  Don't know didn't spend too much time on it:

if (template.endsWith(".jpg") || template.endsWith(".gif")) {
try {
template = ARCHETYPE_RESOURCES + "/" + template;
InputStream is = getStream(template, Thread.currentThread()
.getContextClassLoader());
OutputStream os = new FileOutputStream(f);
int ch; // the buffer
while ((ch = is.read()) != -1) {
os.write(ch);
}
is.close();
os.close();

} catch (Exception e) {
getLogger().error("Could not copy image " + e.getMessage());
}
return;
}

this had the exact same result


> images gif/jpgs etc seem to get corrupted when copied by archetype
> --
>
>  Key: ARCHETYPE-25
>  URL: http://jira.codehaus.org/browse/ARCHETYPE-25
>  Project: Maven Archetype
> Type: Bug

>   Components: maven-archetype-plugin
>  Environment: windows XP
> Reporter: Chris Funk
> Assignee: Jason van Zyl
> Priority: Minor

>
>
> I created a web archetype to include images in the src/main/webapp directory.
> They seem to copy over correctly and there size is reatined, but oddly the 
> images view as blank when displayed in browser or image viewer.
> I double checked to make sure the images I was using were ok and manually 
> copied them over and everything worked fine.  I have the images in the 
> resources section in archetype.xml.  Could be an encoding issue?

-- 
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-1337) Interpolation of POM values needs to be improved

[John Casey (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-1337?page=all ]
 
John Casey closed MNG-1337:
---

  Assign To: John Casey
 Resolution: Fixed
Fix Version: (was: 2.1)
 2.0.3

See MNG-2124...this is fixed, and tested in it0100. Also, in 
RegexBasedModelInterpolatorTest.testShouldInterpolateOrganizationNameCorrectly()

> Interpolation of POM values needs to be improved
> 
>
>  Key: MNG-1337
>  URL: http://jira.codehaus.org/browse/MNG-1337
>  Project: Maven 2
> Type: Bug

>   Components: Plugins and Lifecycle
> Reporter: Jason van Zyl
> Assignee: John Casey
>  Fix For: 2.0.3

>
>
> Currently there are a few problems with POM interpolation:
> 1) Things like ${pom.organization.name} show with the ${pom.name}
> 2) ${pom.build.directory} is always null
> I think using velocity like interpolation here would be better but 
> performance might be an issue.

-- 
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: (CONTINUUM-621) Company logo does not appear

[Mang Lau (JIRA)]

Company logo does not appear


 Key: CONTINUUM-621
 URL: http://jira.codehaus.org/browse/CONTINUUM-621
 Project: Continuum
Type: Bug

  Components: Web interface, Core system  
Versions: 1.0.3, 1.0.2
 Environment: Mozilla Firefox 1.5.0.1
Windows XP SP2
Reporter: Mang Lau
Priority: Minor
 Fix For: 1.0.3


The company logo does not appear on the Continuum web interface.  The logo 
shows in IE but in Firefox, nothing shows up.  It works if you use http 
protocol but doesn't work with the file protocol.  I've tried with and without 
specifying the file protocol.

Snippet of page source here:
{code:html}
http://www.otpp.com/";>


{code}

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

[jira] Commented: (CONTINUUM-621) Company logo does not appear

[Dan Tran (JIRA)]

[ http://jira.codehaus.org/browse/CONTINUUM-621?page=comments#action_60497 
] 

Dan Tran commented on CONTINUUM-621:


due to security concern, firefox does not like file protocol and ignore

> Company logo does not appear
> 
>
>  Key: CONTINUUM-621
>  URL: http://jira.codehaus.org/browse/CONTINUUM-621
>  Project: Continuum
> Type: Bug

>   Components: Web interface, Core system
> Versions: 1.0.3, 1.0.2
>  Environment: Mozilla Firefox 1.5.0.1
> Windows XP SP2
> Reporter: Mang Lau
> Priority: Minor
>  Fix For: 1.0.3

>
>
> The company logo does not appear on the Continuum web interface.  The logo 
> shows in IE but in Firefox, nothing shows up.  It works if you use http 
> protocol but doesn't work with the file protocol.  I've tried with and 
> without specifying the file protocol.
> Snippet of page source here:
> {code:html}
> http://www.otpp.com/";>
>  title="Ontario Teachers' Pension Plan"  border="0">
> 
> {code}

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

[jira] Commented: (CONTINUUM-621) Company logo does not appear

[Mang Lau (JIRA)]

[ http://jira.codehaus.org/browse/CONTINUUM-621?page=comments#action_60498 
] 

Mang Lau commented on CONTINUUM-621:


Upon further testing, it works when I do a "View Source", copy the entire 
contents and paste it in another html file.  When I open up this other file, 
the logo shows up.  I don't know why it doesn't show up otherwise.

> Company logo does not appear
> 
>
>  Key: CONTINUUM-621
>  URL: http://jira.codehaus.org/browse/CONTINUUM-621
>  Project: Continuum
> Type: Bug

>   Components: Web interface, Core system
> Versions: 1.0.3, 1.0.2
>  Environment: Mozilla Firefox 1.5.0.1
> Windows XP SP2
> Reporter: Mang Lau
> Priority: Minor
>  Fix For: 1.0.3

>
>
> The company logo does not appear on the Continuum web interface.  The logo 
> shows in IE but in Firefox, nothing shows up.  It works if you use http 
> protocol but doesn't work with the file protocol.  I've tried with and 
> without specifying the file protocol.
> Snippet of page source here:
> {code:html}
> http://www.otpp.com/";>
>  title="Ontario Teachers' Pension Plan"  border="0">
> 
> {code}

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

[jira] Commented: (MNG-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[John Casey (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2136?page=comments#action_60499 ] 

John Casey commented on MNG-2136:
-

The above example is working as designed. The  element is 
meant to specify that this profile will be activated if no other profiles are 
active in the build. Therefore, specific activation of any profile will cause 
this one to be deactivated. The issue with using the logic that the profile 
should always be applied is this:

1. If it's always applied, why not put it in the POM?
2. If it's active-unless-deactivated, how do you deactivate it?

Changing this feature right now might not make a huge impact on the user 
community, but it would break backwards compatibility in the strictest sense. 
Also, it requires defining some mechanism for deactivating profiles. We have 
one undocumented feature for this, which is:

-P -jboss4x

which would explicitly deactivate the jboss4x profileId, but this is not well 
tested, and IMO is pretty specific...I'd say that we would need something akin 
to:


  


where the user can specify conditions that will deactivate the profile. 
Alternately, we could add an element to simply invert the activation 
logic...meaning the profile is active by default if this element is set, but 
anything triggered in the activation section will DEACTIVATE the profile...

I dunno which way we should go with this, but my feeling is that it might have 
to wait for 2.1.

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
> Priority: Blocker
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[John Casey (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2136?page=comments#action_60500 ] 

John Casey commented on MNG-2136:
-

BTW, can't you add a secondary activation condition that will result in this 
profile being activated despite the outcome of  ? If you 
cannot, I'd consider *that* a bug.

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
> Priority: Blocker
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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-2138) Exclusions in dependencies should not exclude a direct dependency

[Bruce Brouwer (JIRA)]

Exclusions in dependencies should not exclude a direct dependency
-

 Key: MNG-2138
 URL: http://jira.codehaus.org/browse/MNG-2138
 Project: Maven 2
Type: Bug

  Components: Ant tasks  
Versions: 2.0, 2.0.1, 2.0.2
 Environment: Any (tested on windows)
Reporter: Bruce Brouwer
Priority: Minor


Here's the situation: My pom declares a dependency on artifact B, but excludes 
the transitive dependency on C. This same pom also directly depends on C. When 
getting the dependencies, C does not show up in the list, even though it is a 
direct dependency. Here is the relevant section of the pom:


  

  groupB
  artifactB
  

  groupC
  artifactC

  


  groupC
  artifactC

  


Then using that ant task:


-- 
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-2052) Transitive system deps are not interpolated correctly thus rendering them invalid

[John Casey (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2052?page=all ]
 
John Casey closed MNG-2052:
---

  Assign To: John Casey
 Resolution: Fixed
Fix Version: 2.0.3

Fixed along with MNG-2124. Verified in it0101.

> Transitive system deps are not interpolated correctly thus rendering them 
> invalid
> -
>
>  Key: MNG-2052
>  URL: http://jira.codehaus.org/browse/MNG-2052
>  Project: Maven 2
> Type: Bug

>   Components: POM, Artifacts and Repositories
>  Environment: Windows XP, Java 1.5
> Reporter: Chris Stevenson
> Assignee: John Casey
>  Fix For: 2.0.3

>
>
> When a library is loaded as a dependency if its dependencies contain one of 
> type system which has a variable in the path the variable is not interpolated 
> so that ${appHome}/lib/... is not an absolute path, 
> rendering the dependency invalid.
> ex
> Lib A
>   |-->Lib B
>|-->Lib C (System Dep, path=$appHome}/lib/jar)
> When resolving deps for lib B's pom will throw an error because path is not 
> interpolated.

-- 
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-2136) Active profile in profiles.xml prevents active profile in pom.xml to be triggered automatically

[Vincent Massol (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2136?page=comments#action_60503 ] 

Vincent Massol commented on MNG-2136:
-

Thanks John

> 1. If it's always applied, why not put it in the POM?

I fail to undestand this. The reason I have a profiles.xml file is because it 
contains user-specific properties that cannot be shared with other users. 
That's the rasion d'etre of profiles.xml, isn't it?

> 2. If it's active-unless-deactivated, how do you deactivate it?

I don't want to deactivate it. I want jboss4x to be the default profile so that 
there's always a container defined by default and I want to let the user define 
where the containers are installed.

Is that an invalid use case?

If it's valid, then how do I implement it? Or are you simply saying that such a 
use case (which I think it pretty common and simple) is not supported?

> Active profile in profiles.xml prevents active profile in pom.xml to be 
> triggered automatically
> ---
>
>  Key: MNG-2136
>  URL: http://jira.codehaus.org/browse/MNG-2136
>  Project: Maven 2
> Type: Bug

>   Components: POM
> Versions: 2.0.3
> Reporter: Vincent Massol
> Assignee: John Casey
> Priority: Blocker
>  Fix For: 2.0.3

>
>
> If there's a profiles.xml with an active profile in it, then the active 
> profile defined in the pom.xml is ignored and not triggered.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Dan Fabulich (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60505 ] 

Dan Fabulich commented on MNG-2127:
---

Wow... I'm definitely surprised to see that ant.bat suffers from this same 
problem.  Let that teach me a valuable lesson.  :-)

I'm definitely surprised to hear that we don't support Win9x, because there's a 
bunch of code in this batch script designed to handle Win9x, including a batch 
label called :Win9xApp, which only triggers when %OS% is not equal to 
Windows_NT, which is always true on Windows_NT, Windows 2000, Windows XP, and 
Windows 2003.  Is any of that code necessary?

Anyway, using the current latest mvn.bat from SVN (384215) helps quite a bit.
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-core/src/bin/mvn.bat?rev=384215&view=markup

With that said, on line 154, it says "exit /b %ERROR_CODE%".  This breaks on 
Windows NT... the batch script always returns 1, because that's an invalid 
command on NT.  Does Maven support Windows NT?

Interestingly, since the latest SVN mvn.bat uses exit /b, but includes the "if 
errorlevel 1 goto error" fix, it works properly in Ant on Windows 2003 even 
without the MAVEN_TERMINATE_CMD environment variable.  Here's my test, which 
works on Windows 2003, but not on Windows XP:













Anyway, I think I can live with this.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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: (MAVENUPLOAD-771) Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23

[Ceki Gulcu (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-771?page=all ]

Ceki Gulcu updated MAVENUPLOAD-771:
---

Attachment: slf4j-log4j12-1.0-bundle.jar

> Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23
> --
>
>  Key: MAVENUPLOAD-771
>  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-771
>  Project: maven-upload-requests
> Type: Task

> Reporter: Ceki Gulcu
>  Attachments: jcl104-over-slf4j-1.0-bundle.jar, slf4j-jcl-1.0-bundle.jar, 
> slf4j-jdk14-1.0-bundle.jar, slf4j-log4j12-1.0-bundle.jar, 
> slf4j-log4j13-1.0-bundle.jar, slf4j-nop-1.0-bundle.jar, 
> slf4j-simple-1.0-bundle.jar
>
>
> The SLF4J project recently released version 1.0 of the SLF4J API and NLOG4J 
> 1.2.23. Please kindly add the attached files to ibiblio's maven repository.

-- 
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-771) Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23

[Ceki Gulcu (JIRA)]

Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23
--

 Key: MAVENUPLOAD-771
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-771
 Project: maven-upload-requests
Type: Task

Reporter: Ceki Gulcu
 Attachments: jcl104-over-slf4j-1.0-bundle.jar, slf4j-jcl-1.0-bundle.jar, 
slf4j-jdk14-1.0-bundle.jar, slf4j-log4j12-1.0-bundle.jar, 
slf4j-log4j13-1.0-bundle.jar, slf4j-nop-1.0-bundle.jar, 
slf4j-simple-1.0-bundle.jar

The SLF4J project recently released version 1.0 of the SLF4J API and NLOG4J 
1.2.23. Please kindly add the attached files to ibiblio's maven repository.

-- 
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: (MAVENUPLOAD-771) Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23

[Ceki Gulcu (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-771?page=all ]

Ceki Gulcu updated MAVENUPLOAD-771:
---

Attachment: slf4j-simple-1.0-bundle.jar
slf4j-nop-1.0-bundle.jar
slf4j-log4j13-1.0-bundle.jar

> Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23
> --
>
>  Key: MAVENUPLOAD-771
>  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-771
>  Project: maven-upload-requests
> Type: Task

> Reporter: Ceki Gulcu
>  Attachments: jcl104-over-slf4j-1.0-bundle.jar, slf4j-jcl-1.0-bundle.jar, 
> slf4j-jdk14-1.0-bundle.jar, slf4j-log4j12-1.0-bundle.jar, 
> slf4j-log4j13-1.0-bundle.jar, slf4j-nop-1.0-bundle.jar, 
> slf4j-simple-1.0-bundle.jar
>
>
> The SLF4J project recently released version 1.0 of the SLF4J API and NLOG4J 
> 1.2.23. Please kindly add the attached files to ibiblio's maven repository.

-- 
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-771) Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23

[Ceki Gulcu (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-771?page=comments#action_60506 ] 

Ceki Gulcu commented on MAVENUPLOAD-771:



As URLS:

http://jira.codehaus.org/secure/attachment/19504/jcl104-over-slf4j-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19511/nlog4j-1.2.23-bundle.jar
http://jira.codehaus.org/secure/attachment/19505/slf4j-jcl-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19506/slf4j-jdk14-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19507/slf4j-log4j12-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19508/slf4j-log4j13-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19509/slf4j-nop-1.0-bundle.jar
http://jira.codehaus.org/secure/attachment/19510/slf4j-simple-1.0-bundle.jar


> Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23
> --
>
>  Key: MAVENUPLOAD-771
>  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-771
>  Project: maven-upload-requests
> Type: Task

> Reporter: Ceki Gulcu
>  Attachments: jcl104-over-slf4j-1.0-bundle.jar, nlog4j-1.2.23-bundle.jar, 
> slf4j-jcl-1.0-bundle.jar, slf4j-jdk14-1.0-bundle.jar, 
> slf4j-log4j12-1.0-bundle.jar, slf4j-log4j13-1.0-bundle.jar, 
> slf4j-nop-1.0-bundle.jar, slf4j-simple-1.0-bundle.jar
>
>
> The SLF4J project recently released version 1.0 of the SLF4J API and NLOG4J 
> 1.2.23. Please kindly add the attached files to ibiblio's maven repository.

-- 
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: (MAVENUPLOAD-771) Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23

[Ceki Gulcu (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-771?page=all ]

Ceki Gulcu updated MAVENUPLOAD-771:
---

Attachment: nlog4j-1.2.23-bundle.jar

> Upload request for SLF4J 1.0 (final) and NLOG4J 1.2.23
> --
>
>  Key: MAVENUPLOAD-771
>  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-771
>  Project: maven-upload-requests
> Type: Task

> Reporter: Ceki Gulcu
>  Attachments: jcl104-over-slf4j-1.0-bundle.jar, nlog4j-1.2.23-bundle.jar, 
> slf4j-jcl-1.0-bundle.jar, slf4j-jdk14-1.0-bundle.jar, 
> slf4j-log4j12-1.0-bundle.jar, slf4j-log4j13-1.0-bundle.jar, 
> slf4j-nop-1.0-bundle.jar, slf4j-simple-1.0-bundle.jar
>
>
> The SLF4J project recently released version 1.0 of the SLF4J API and NLOG4J 
> 1.2.23. Please kindly add the attached files to ibiblio's maven repository.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Steve Loughran (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60507 ] 

Steve Loughran commented on MNG-2127:
-

I believe Ant's return code on winnt systems was fixed as of last week. We 
really need to think of a good regression test for this, because ant.bat is the 
one of the two startup scripts that scare the team. the other is cygwin support 
in ant.sh. the perl and python startup scripts are fine, its just those two.

the underlying problem with ant.bat is trying to support win9x, which makes 
things much more contrived, and much more brittle -we have a vmware image of 
'9x around just to check things work. 

as for last weeks patch, it turns out that if you unset an env variable that 
was never set, the error code was set. So to clear all env variables (remember, 
you can't use @setlocal on '9x), ant needs to set every transient env var to a 
value just before clearing, to be 100% sure that is was set by all paths to the 
exit logic.

If starting maven on ant is important (and clearly it is), I would recomend you 
look at the script and do a  task to set it up and call it. That or 
someone needs to write a proper  task. 

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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: (MPLUGIN-13) Provide Automated Documentation for a Plugin That Provides a Report

[Stephen Duncan Jr (JIRA)]

Provide Automated Documentation for a Plugin That Provides a Report
---

 Key: MPLUGIN-13
 URL: http://jira.codehaus.org/browse/MPLUGIN-13
 Project: Maven 2.x Plugin Plugin
Type: Improvement

Reporter: Stephen Duncan Jr


Provide some automated, consistent indication and documentation that a plugin 
can be used in .

-- 
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] Reopened: (MASSEMBLY-1) assembly jar-with-dependencies does not utilize or provide for manifest configuration

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-1?page=all ]
 
Brett Porter reopened MASSEMBLY-1:
--


> assembly jar-with-dependencies does not utilize or provide for manifest 
> configuration
> -
>
>  Key: MASSEMBLY-1
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-1
>  Project: Maven 2.x Assembly Plugin
> Type: Bug

>  Environment: $ uname -a
> Darwin xxx 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; 
> root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc
> $ java -version
> java version "1.5.0_05"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-72)
> Java HotSpot(TM) Client VM (build 1.5.0_05-44, mixed mode, sharing)
> $ mvn -version
> Maven version: 2.0
> maven-assembly-plugin version 2.0
> Reporter: Michael Heuer
> Assignee: Brett Porter
> Priority: Minor
>  Fix For: 2.0.1
>  Attachments: mng-1380-src.tar.gz
>
> Original Estimate: 1 hour
>Time Spent: 30 minutes
> Remaining: 0 minutes
>
> Date: Mon, 31 Oct 2005 17:04:21 +1100
> From: Brett Porter <[EMAIL PROTECTED]>
> To: Maven Users List 
> Subject: Re: [m2] manifest for assembly jar-with-dependencies
> Yes, that's an issue with the assembly plugin. If there is no
> corresponding JIRA issue, please file one.
> - Brett
> On 10/28/05, Michael Heuer <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I followed the guide at
> >
> > > http://maven.apache.org/guides/mini/guide-manifest.html
> >
> > to add entries to my MANIFEST.MF, and that works fine with
> >
> > $ mvn package
> >
> > However, it seems that the assembly plugin does not reuse the
> > configuration information when building the jar-with-dependencies jar, so
> > I'm left with a default manifest in that jar.
> >
> >michael

-- 
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: (MASSEMBLY-1) assembly jar-with-dependencies does not utilize or provide for manifest configuration

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-1?page=all ]

Brett Porter updated MASSEMBLY-1:
-

Fix Version: (was: 2.0.1)
 2.1

> assembly jar-with-dependencies does not utilize or provide for manifest 
> configuration
> -
>
>  Key: MASSEMBLY-1
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-1
>  Project: Maven 2.x Assembly Plugin
> Type: Bug

>  Environment: $ uname -a
> Darwin xxx 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; 
> root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc
> $ java -version
> java version "1.5.0_05"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-72)
> Java HotSpot(TM) Client VM (build 1.5.0_05-44, mixed mode, sharing)
> $ mvn -version
> Maven version: 2.0
> maven-assembly-plugin version 2.0
> Reporter: Michael Heuer
> Assignee: Brett Porter
> Priority: Minor
>  Fix For: 2.1
>  Attachments: mng-1380-src.tar.gz
>
> Original Estimate: 1 hour
>Time Spent: 30 minutes
> Remaining: 0 minutes
>
> Date: Mon, 31 Oct 2005 17:04:21 +1100
> From: Brett Porter <[EMAIL PROTECTED]>
> To: Maven Users List 
> Subject: Re: [m2] manifest for assembly jar-with-dependencies
> Yes, that's an issue with the assembly plugin. If there is no
> corresponding JIRA issue, please file one.
> - Brett
> On 10/28/05, Michael Heuer <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I followed the guide at
> >
> > > http://maven.apache.org/guides/mini/guide-manifest.html
> >
> > to add entries to my MANIFEST.MF, and that works fine with
> >
> > $ mvn package
> >
> > However, it seems that the assembly plugin does not reuse the
> > configuration information when building the jar-with-dependencies jar, so
> > I'm left with a default manifest in that jar.
> >
> >michael

-- 
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-30) Wrong classpath separator

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/SUREFIRE-30?page=comments#action_60513 ] 

Brett Porter commented on SUREFIRE-30:
--

that's what I used in the 2.0 version. As you can see, it is already marked 
fixed.

> Wrong classpath separator
> -
>
>  Key: SUREFIRE-30
>  URL: http://jira.codehaus.org/browse/SUREFIRE-30
>  Project: surefire
> Type: Bug

> Versions: 1.5.2, 1.5.3
>  Environment: Only Windows
> Reporter: Marcin Cetnarski
> Assignee: Brett Porter
>  Fix For: 2.0
>  Attachments: SurefireBooter.patch
>
>
> In SurefireBooter when use fork mode elements of classpath are separated by 
> colon. This works on Linux but not on Windows. I sugest to use semicolon.
>private static ClassLoader createForkingClassLoader( String basedir )
> throws Exception
> {
> Properties p = loadProperties( basedir, CLASSLOADER_PROPERTIES );
> String cp = p.getProperty( "classpath" );
> boolean childDelegation = "true".equals( p.getProperty( 
> "childDelegation", "false" ) );
> List urls = Arrays.asList( cp.split( ";" ) );  // was List urls = 
> Arrays.asList( cp.split( ":" ) );
> return createClassLoader( urls, childDelegation );
> }
> and 
>private void getForkArgs( String batteryConfig )
> throws Exception
> {
> .
> else
> {
> if ( cp.length() == 0 )
> cp = url;
> else
> cp += ";" + url; // was cp += ":" + url;
> }

-- 
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-2139) Maven Tasks for Ant should provide an Ant task to launch Maven

[Dan Fabulich (JIRA)]

Maven Tasks for Ant should provide an Ant task to launch Maven
--

 Key: MNG-2139
 URL: http://jira.codehaus.org/browse/MNG-2139
 Project: Maven 2
Type: Wish

  Components: Ant tasks  
Versions: 2.0.3, 2.0, 2.0.1, 2.0.2
 Environment: Windows makes this especially troublesome
Reporter: Dan Fabulich


Due to bug MNG-2127, it can be tricky to launch Maven from within Ant correctly 
and extract the correct exit value on all operating systems.  A great solution 
would be to implement a  task in the Maven Tasks for Ant.  This code 
would be able to correctly and simply construct Maven's classpath (using the 
classes already baked into maven-artifact-ant-*-dep.jar) and execute arbitrary 
goals on arbitrary POMs.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Dan Fabulich (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60514 ] 

Dan Fabulich commented on MNG-2127:
---

Good points, Steve.  I've filed a wish MNG-2139 for a  ant task to 
launch Maven.

When you say you believe Ant's return code on "winnt systems" was fixed, do you 
mean Windows NT, or everything NT-based (2003, 2000, XP, etc)?  Can you provide 
a link/pointer to the revision in SCM?

Hopefully since Maven doesn't need 9x support it can at least make sure mvn.bat 
returns a reasonable result code on the supported operating systems.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60518 ] 

Brett Porter commented on MNG-2127:
---

I guess we don't support Windows NT either :(

Perhaps we should remove the exit /B altogether and rely on errorlevel not 
getting murdered by carefully checking it also.

It's awfully tempting to write a little .exe that takes care of this.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-92) site:stage fails, goal not found

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MSITE-92?page=comments#action_60519 ] 

Brett Porter commented on MSITE-92:
---

2.0


> site:stage fails, goal not found
> 
>
>  Key: MSITE-92
>  URL: http://jira.codehaus.org/browse/MSITE-92
>  Project: Maven 2.x Site Plugin
> Type: Bug

>  Environment: Maven 2.0.2
> Reporter: Howard M. Lewis Ship
> Assignee: Brett Porter

>
>
> The documentation for "site:stage" is unclear; it appears to be something 
> that will build my site to a particular directory?  In trying to test it out, 
> to see what it does, I found out that it does not work.
> bash-3.00$ mvn site:stage
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'site'.
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Required goal not found: site:stage
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Feb 16 18:57:01 PST 2006
> [INFO] Final Memory: 2M/5M
> [INFO] 
> 
> bash-3.00$

-- 
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: (MSUREFIRE-76) Surefire forkMode not working on windows [patch attached]

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-76?page=all ]
 
Brett Porter closed MSUREFIRE-76:
-

 Assign To: Brett Porter
Resolution: Duplicate

> Surefire forkMode not working on windows [patch attached]
> -
>
>  Key: MSUREFIRE-76
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-76
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Christian Schulte
> Assignee: Brett Porter
>  Attachments: system.getproperty.path.separator.patch, win.patch
>
>
> On windows all forkModes other than none are not working. This is because 
> surefire-booter writes the classpath into some property file using ':' as the 
> separator. This is not working since on windows all absolute paths contain 
> the drive letter followed by ':'. The attached patch changes ':' to '^'. 
> After applying forkMode starts working on windows.

-- 
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-2127) mvn.bat always exits 0 on Windows 2000 and higher

[Dan Fabulich (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2127?page=comments#action_60520 ] 

Dan Fabulich commented on MNG-2127:
---

exit /B is the only thing making this work nicely on Windows 2003.  I'd rather 
say "if errorlevel 1 exit /B >NUL 2>&1" which will work on Windows NT by 
sending an invalid syntax to exit, which is probably not the way you meant it 
to work, but I think it does work.

> mvn.bat always exits 0 on Windows 2000 and higher
> -
>
>  Key: MNG-2127
>  URL: http://jira.codehaus.org/browse/MNG-2127
>  Project: Maven 2
> Type: Bug

>   Components: Command Line
> Versions: 2.0, 2.0.1, 2.0.2
>  Environment: I'm on Windows 2003 Server, but this will affect any OS for 
> which the %OS% environment variable is Windows_NT, including Windows XP and 
> Windows 2000.
> Reporter: Dan Fabulich
> Assignee: Brett Porter
> Priority: Blocker
>  Attachments: mvnfixed.bat, mvnfixed.bat
>
>
> Write the following ant script and run it on Windows 2000 or higher:  
>  failonerror="true" />
> This will run "mvn" with no arguments, which will always fail.  But the ant 
> script will claim "build successful", because the exit value of mvn.bat was 
> 0.  It is absolutely critical that this work correctly, or else I can't 
> integrate Maven into any other automated system.
> This is happening because mvn.bat is improperly abusing local scoping.  On 
> line 130 of mvn.bat, we execute maven, but we don't do anything with its exit 
> value... we just always goto end.  The fix for this is to add a line 131 that 
> says "if errorlevel 1 goto error", which will behave correctly.
> (I marked this as having a test case because I've included a test ant script, 
> but technically this isn't a JUnit test case, so it may be an inappropriate 
> use of the "testcase included" marker.)

-- 
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-2139) Maven Tasks for Ant should provide an Ant task to launch Maven

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2139?page=all ]
 
Brett Porter closed MNG-2139:
-

 Assign To: Brett Porter
Resolution: Duplicate

> Maven Tasks for Ant should provide an Ant task to launch Maven
> --
>
>  Key: MNG-2139
>  URL: http://jira.codehaus.org/browse/MNG-2139
>  Project: Maven 2
> Type: Wish

>   Components: Ant tasks
> Versions: 2.0.3, 2.0, 2.0.1, 2.0.2
>  Environment: Windows makes this especially troublesome
> Reporter: Dan Fabulich
> Assignee: Brett Porter

>
>
> Due to bug MNG-2127, it can be tricky to launch Maven from within Ant 
> correctly and extract the correct exit value on all operating systems.  A 
> great solution would be to implement a  task in the Maven Tasks for 
> Ant.  This code would be able to correctly and simply construct Maven's 
> classpath (using the classes already baked into maven-artifact-ant-*-dep.jar) 
> and execute arbitrary goals on arbitrary POMs.

-- 
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-2139) Maven Tasks for Ant should provide an Ant task to launch Maven

[Dan Fabulich (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2139?page=comments#action_60522 ] 

Dan Fabulich commented on MNG-2139:
---

Isn't this a separate issue?  This one's a wish for an Ant task.

> Maven Tasks for Ant should provide an Ant task to launch Maven
> --
>
>  Key: MNG-2139
>  URL: http://jira.codehaus.org/browse/MNG-2139
>  Project: Maven 2
> Type: Wish

>   Components: Ant tasks
> Versions: 2.0.3, 2.0, 2.0.1, 2.0.2
>  Environment: Windows makes this especially troublesome
> Reporter: Dan Fabulich
> Assignee: Brett Porter

>
>
> Due to bug MNG-2127, it can be tricky to launch Maven from within Ant 
> correctly and extract the correct exit value on all operating systems.  A 
> great solution would be to implement a  task in the Maven Tasks for 
> Ant.  This code would be able to correctly and simply construct Maven's 
> classpath (using the classes already baked into maven-artifact-ant-*-dep.jar) 
> and execute arbitrary goals on arbitrary POMs.

-- 
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-2139) Maven Tasks for Ant should provide an Ant task to launch Maven

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2139?page=comments#action_60523 ] 

Brett Porter commented on MNG-2139:
---

yes, its the same thing.

> Maven Tasks for Ant should provide an Ant task to launch Maven
> --
>
>  Key: MNG-2139
>  URL: http://jira.codehaus.org/browse/MNG-2139
>  Project: Maven 2
> Type: Wish

>   Components: Ant tasks
> Versions: 2.0.3, 2.0, 2.0.1, 2.0.2
>  Environment: Windows makes this especially troublesome
> Reporter: Dan Fabulich
> Assignee: Brett Porter

>
>
> Due to bug MNG-2127, it can be tricky to launch Maven from within Ant 
> correctly and extract the correct exit value on all operating systems.  A 
> great solution would be to implement a  task in the Maven Tasks for 
> Ant.  This code would be able to correctly and simply construct Maven's 
> classpath (using the classes already baked into maven-artifact-ant-*-dep.jar) 
> and execute arbitrary goals on arbitrary POMs.

-- 
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: (MINSTALL-12) Parameters should not be read-only

[Patrick Lightbody (JIRA)]

 [ http://jira.codehaus.org/browse/MINSTALL-12?page=all ]

Patrick Lightbody updated MINSTALL-12:
--

Attachment: install.diff

> Parameters should not be read-only
> --
>
>  Key: MINSTALL-12
>  URL: http://jira.codehaus.org/browse/MINSTALL-12
>  Project: Maven 2.x Install Plugin
> Type: Improvement

> Versions: 2.1
>  Environment: Maven 2.0.2 binary
> Reporter: Patrick Lightbody
>  Attachments: install.diff
>
>
> When running the following plugin (as a workaround due to a bug in maven):
>   
>   maven-install-plugin
>   org.apache.maven.plugins
>   
>   
>   validate
>   
>   
> ${basedir}/repo/opensymphony/webwork/2.2.1-SNAPSHOT/webwork-2.2.1-SNAPSHOT.jar
>   opensymphony
>   webwork
>   2.2.1-SNAPSHOT
>   
>   
>   install-file
>   
>   
>   
>   
> I get this error:
> "Error configuration: org.apache.maven.plugins:maven-install-plugin. Reason: 
> ERROR: Cannot override read-only parameter: artifactId in goal: 
> install:install-file"
> Bret says:
> (16:49:33) brett: odd
> (16:49:55) brett: hrmph
> (16:50:12) brett: they are all read-only, so can only be set on the command 
> line
> (16:50:15) brett: I don't know why that is
> (16:50:28) PSquad32: should i open a feature request?
> (16:50:44) brett: yes, please
> So I did. Done.

-- 
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: (MINSTALL-12) Parameters should not be read-only

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MINSTALL-12?page=all ]
 
Brett Porter closed MINSTALL-12:


  Assign To: Brett Porter
 Resolution: Fixed
Fix Version: 2.2

> Parameters should not be read-only
> --
>
>  Key: MINSTALL-12
>  URL: http://jira.codehaus.org/browse/MINSTALL-12
>  Project: Maven 2.x Install Plugin
> Type: Improvement

> Versions: 2.1
>  Environment: Maven 2.0.2 binary
> Reporter: Patrick Lightbody
> Assignee: Brett Porter
>  Fix For: 2.2
>  Attachments: install.diff
>
>
> When running the following plugin (as a workaround due to a bug in maven):
>   
>   maven-install-plugin
>   org.apache.maven.plugins
>   
>   
>   validate
>   
>   
> ${basedir}/repo/opensymphony/webwork/2.2.1-SNAPSHOT/webwork-2.2.1-SNAPSHOT.jar
>   opensymphony
>   webwork
>   2.2.1-SNAPSHOT
>   
>   
>   install-file
>   
>   
>   
>   
> I get this error:
> "Error configuration: org.apache.maven.plugins:maven-install-plugin. Reason: 
> ERROR: Cannot override read-only parameter: artifactId in goal: 
> install:install-file"
> Bret says:
> (16:49:33) brett: odd
> (16:49:55) brett: hrmph
> (16:50:12) brett: they are all read-only, so can only be set on the command 
> line
> (16:50:15) brett: I don't know why that is
> (16:50:28) PSquad32: should i open a feature request?
> (16:50:44) brett: yes, please
> So I did. Done.

-- 
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: (CONTINUUM-622) Configure default build description

[Shinobu Kawai Yoshida (JIRA)]

Configure default build description
---

 Key: CONTINUUM-622
 URL: http://jira.codehaus.org/browse/CONTINUUM-622
 Project: Continuum
Type: Wish

  Components: Core system  
Versions: 1.0.2
Reporter: Shinobu Kawai Yoshida


It would be great if it was possible to configure the build definition created 
when adding a project.

e.g.  Currently, the goal for m2 projects are "clean install".  If you wanted 
to have all your projects do "clean deploy site site:deploy", you need to edit 
them one by one.  But if you could configure the defaults, you can set it to 
the goals you would use most.

I guess this will improve with the upcoming bulk updating feature, but you 
still need to edit it.  ;)

-- 
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: (MJAVADOC-36) Would like a way to get default javadoc behavior

[Martin Desruisseaux (JIRA)]

[ http://jira.codehaus.org/browse/MJAVADOC-36?page=comments#action_60526 ] 

Martin Desruisseaux commented on MJAVADOC-36:
-

Thanks for doing all this javadoc work.


> Would like a way to get default javadoc behavior
> 
>
>  Key: MJAVADOC-36
>  URL: http://jira.codehaus.org/browse/MJAVADOC-36
>  Project: Maven 2.x Javadoc Plugin
> Type: Wish

>  Environment: Windows XP
> Reporter: Martin Desruisseaux
> Assignee: Maria Odea Ching
> Priority: Minor
>  Fix For: 2.0-beta-4
>  Attachments: MJAVADOC-36-maven-javadoc-plugin.patch, 
> no_default_stylesheet.diff
>
>   Time Spent: 2 hours, 30 minutes
>Remaining: 0 minutes
>
> The javadoc plugin overrides some Sun's javadoc default options with its own 
> default. This is quite nice for options like -bottom, since Maven has 
> informations that Sun's javadoc doesn't have. The -package option (which 
> default to 'true' in maven-javadoc-plugin, while the default was 'false' in 
> Sun's javadoc) sound a little bit more surprising to me, since it lead us to 
> a situation where we have two set of default values to keep in mind: the 
> Sun's ones, and the Maven ones.
> It is not a real problem for options like -package and -use. It is a little 
> bit more disturbing for -stylesheet, since it seems hard to tell to Maven to 
> not use the Maven's stylesheet, but to keep the Sun's default stylesheet 
> instead. I understand that we can provide our own stylesheet with the 
>  parameter, but in this case I have no file to point; I would 
> just like to keep Sun's default stylesheet.
> I would like a way to disable completly the "-stylesheet" option in the 
> javadoc plugin. Or alternatively, the plugin may use the Maven's stylesheet 
> only when explicitly required.

-- 
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: (MNGECLIPSE-29) Plug-In does not run behind Proxy/Firewall (where M2 itself does)

[Peter Whitfield (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-29?page=comments#action_60530 
] 

Peter Whitfield commented on MNGECLIPSE-29:
---

Hi,

For what it's worth, I've having this problem with the following configuration:

Eclipse 3.1.1 and 3.1.2
m2eclipse 0.0.5

I've configured my proxy details in both Eclipse and settings.xml (although I'm 
not too sure where settings.xml should be located for m2eclipse.. I've tried a 
number of locations) but I'm getting the following errors:

INFO] 

[INFO] Building iAM
[INFO]task-segment: [package]
[INFO] 

[DEBUG] maven-resources-plugin: resolved to version 2.1 from repository central
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-resources-plugin:maven-plugin:2.1
[DEBUG] Found 0 components to load on start
[DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-compiler-plugin:maven-plugin:2.0
[DEBUG] Found 0 components to load on start
[DEBUG] maven-surefire-plugin: resolved to version 2.1.2 from repository central
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-surefire-plugin:maven-plugin:2.1.2
[DEBUG] Found 0 components to load on start
[DEBUG] maven-war-plugin: resolved to version 2.0-beta-2 from repository central
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-war-plugin:maven-plugin:2.0-beta-2
[DEBUG] Found 0 components to load on start
[DEBUG] maven-release-plugin: resolved to version 2.0-beta-3 from repository 
central
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-release-plugin:maven-plugin:2.0-beta-3
[DEBUG] Found 0 components to load on start
[DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 
(selected for runtime)
[DEBUG] Retrieving parent-POM from the repository for project: 
org.apache.maven:maven-model:jar:2.0
[DEBUG]   org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Retrieving parent-POM from the repository for project: 
null:maven-project:jar:2.0
[DEBUG]   org.apache.maven:maven-project:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 
(selected for runtime)
[DEBUG]   classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG]   junit:junit:jar:3.8.1 (selected for runtime)
.
.
.
Compiling 221 source files to C:\Documents and Settings\Peter Whitfield\My 
Documents\Eclipse Workspace\cbaUserAdmin\target\classes
[ERROR] mojo-execute : compiler:compile
Diagnosis: Compilation failure
FATAL ERROR: Error executing Maven for a project
[ERROR] project-execute : cbaUserAdmin:cbaUserAdmin:war:4.2.0-SNAPSHOT (  
task-segment: [package] )
Diagnosis: Compilation failure
FATAL ERROR: Error executing Maven for a project
org.apache.maven.BuildFailureException: Compilation failure
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at 
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472)
at 
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413)
at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation 
failure
at 
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
... 8 more

Looks like it's failing on anything it tries to get from the central repository.

FYI, maven 2.0.2 works fine from the command line on the same machine.

Cheers,

Peter

> Plug-In does not run behind Proxy/Firewall (where M2 itself does)
> -
>
>  Key: MNGECLIPSE-29
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-2

[jira] Commented: (MASSEMBLY-68) Need method to exclude all child dependencies when creating a jar

[Allan Ramirez (JIRA)]

[ http://jira.codehaus.org/browse/MASSEMBLY-68?page=comments#action_60535 ] 

Allan Ramirez commented on MASSEMBLY-68:


So it would only assemble the jars of your modules? 

> Need method to exclude all child dependencies when creating a jar
> -
>
>  Key: MASSEMBLY-68
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-68
>  Project: Maven 2.x Assembly Plugin
> Type: Improvement

> Reporter: Dan Diephouse
>  Fix For: 2.1

>
>
> With xfire, we have 10 different modules. We want to create an "xfire-all" 
> jar that has all the xfire modules bundled. We can do this with the assembly 
> plugin right now by creating a pom with all our modules in it. However, when 
> it includes all the child dependencies. To exclude child dependencies you 
> have to listen them individually. XFire probably has around 50+ dependencies 
> spread out over the build. Maintaining this exclude list would be too much 
> work, so we'd like a way to simply say - build a jar composed of these 10 
> jars, but none of their deps.

-- 
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: (MIDEA-32) Changed Xpp3Dom in favor of dom4j

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MIDEA-32?page=all ]

Brett Porter updated MIDEA-32:
--

Fix Version: 2.0

> Changed Xpp3Dom in favor of dom4j
> -
>
>  Key: MIDEA-32
>  URL: http://jira.codehaus.org/browse/MIDEA-32
>  Project: Maven 2.x Idea Plugin
> Type: Improvement

> Reporter: Johann Reyes
>  Fix For: 2.0
>  Attachments: MIDEA-32.patch
>
>
> As per @todo changed from Xpp3Dom to dom4j so it can cope properly with 
> entities.

-- 
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: (MASSEMBLY-68) Need method to exclude all child dependencies when creating a jar

[Dan Diephouse (JIRA)]

[ http://jira.codehaus.org/browse/MASSEMBLY-68?page=comments#action_60537 ] 

Dan Diephouse commented on MASSEMBLY-68:


Correct! All 15 or so of them into one large jar. No child dependencies though.

> Need method to exclude all child dependencies when creating a jar
> -
>
>  Key: MASSEMBLY-68
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-68
>  Project: Maven 2.x Assembly Plugin
> Type: Improvement

> Reporter: Dan Diephouse
>  Fix For: 2.1

>
>
> With xfire, we have 10 different modules. We want to create an "xfire-all" 
> jar that has all the xfire modules bundled. We can do this with the assembly 
> plugin right now by creating a pom with all our modules in it. However, when 
> it includes all the child dependencies. To exclude child dependencies you 
> have to listen them individually. XFire probably has around 50+ dependencies 
> spread out over the build. Maintaining this exclude list would be too much 
> work, so we'd like a way to simply say - build a jar composed of these 10 
> jars, but none of their deps.

-- 
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] Reopened: (MSUREFIRE-75) NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-75?page=all ]
 
Brett Porter reopened MSUREFIRE-75:
---


> NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar  
> -
>
>  Key: MSUREFIRE-75
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-75
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Olivier Lamy
> Assignee: Emmanuel Venisse
>  Fix For: 2.1.3
>  Attachments: pom.xml, 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] Closed: (MSUREFIRE-75) NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-75?page=all ]
 
Brett Porter closed MSUREFIRE-75:
-

 Resolution: Duplicate
Fix Version: (was: 2.1.3)

> NPE with maven-surefire-plugin-2.1.3-20060228.012944-10.jar  
> -
>
>  Key: MSUREFIRE-75
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-75
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

> Reporter: Olivier Lamy
> Assignee: Emmanuel Venisse
>  Attachments: pom.xml, 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects

[Eugene Kuleshov (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_60540 
] 

Eugene Kuleshov commented on MNGECLIPSE-59:
---

The plan is to always use code from Workspace if version matches. It won't be 
necessary to have anything special in pom. Though I can't give you any estimate 
on this, because most of the work is actually in the Maven ebedder component.

> Allow artifact resolution from workspace projects
> -
>
>  Key: MNGECLIPSE-59
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
>  Project: Maven 2.x Extension for Eclipse
> Type: New Feature

>   Components: Dependency Resolver
> Versions: 0.0.4
> Reporter: Leonardo Quijano Vincenzi
> Assignee: Eugene Kuleshov
>  Fix For: 1.0.0

>
>
> Provide artifact resolution from workspace projects, which override the same 
> artifact from the local or remote repositories. This would allow to work with 
> dependant Eclipse projects without specifying the Eclipse dependency manually.
> The workspace artifact resolution would have to be specified manually, since 
> several Maven-Enabled projects in the same workspace could have the same 
> artifact and version Id. Or at least automatic resolution with an optional 
> override would be nice.
> More comments here:
> http://jira.codehaus.org/browse/MNGECLIPSE-58

-- 
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: (MPIR-11) improved dependency report

[Edwin Punzalan (JIRA)]

[ http://jira.codehaus.org/browse/MPIR-11?page=comments#action_60543 ] 

Edwin Punzalan commented on MPIR-11:


Committed in svn the dependency graph and its corresponding tables.  There is a 
column in the dependency tabes marking an artifact as either "attached" or "not 
attached".

Would like to hear your comments on it.  Thanks.

> improved dependency report
> --
>
>  Key: MPIR-11
>  URL: http://jira.codehaus.org/browse/MPIR-11
>  Project: Maven 2.x Project Info Reports Plugin
> Type: New Feature

> Versions: 2.0-beta-3
> Reporter: Brett Porter
> Assignee: Edwin Punzalan
>  Fix For: 2.0
>  Attachments: DependencyReport.java, DependencyTreeMojo.java
>
> Original Estimate: 8 hours
>Time Spent: 11 hours
> Remaining: 1 hour
>
> it'd be great to have a dependencies report based on the listener in 
> maven-artifact:
> - report on scopes
> - report on versions considered by not selected
> - show structure of dependency tree
> I think it would be best to tabulate each dependencies info in multiple rows 
> at the bottom (as the description currently gets squashed into the table), 
> and present a tree at the top that links to it. (indented lists here, we have 
> a graphing tool we can use later).
> we should make some of this configurable, of course.

-- 
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: (MNGECLIPSE-75) Update source folders action should set default output folder

[Ray Tsang (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-75?page=comments#action_60544 
] 

Ray Tsang commented on MNGECLIPSE-75:
-

Eugene,  I see the problem.  I just made a patch that adds the "Share output 
folder" option, as well as a default output folder if it's not shared.

I also noticed the output folder for resources were set to themselves for a 
reason, I've also restored that behavior when output folders are not shared.

> Update source folders action should set default output folder
> -
>
>  Key: MNGECLIPSE-75
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-75
>  Project: Maven 2.x Extension for Eclipse
> Type: New Feature

> Versions: 0.0.5
>  Environment: Linux. JDK 1.5. XmlBeans 2.x.
> Reporter: Jimisola Laursen
> Assignee: Eugene Kuleshov
>  Attachments: MNGECLIPSE-75.tar.gz, mngeclipse-75-xmlbeans-testcase.zip, 
> set-output-folder.patch
>
>
> I have a problem with Maven2, XmlBeans Maven Plugin and this plugin (Eclipse 
> Maven Plugin). However, I do believe that the problem will exist when 
> generating sources in other ways as well. I assume that you are  familiar 
> with XmlBeans (if not, it's Java Binding tools that creates Java classes for 
> an XML Schema).
> In my project I use XmlBeans when performing unit tests. Hence, the XmlBeans 
> Maven Plugin generates Java code under /target/test-xmlbeans-source. The 
> actual problem is that Eclipse needs the generated Java code otherwise it 
> generates errors since it can't find the classes used by the unit tests. I 
> want the Maven plugin to add classes of auto-generated source code to Eclipse 
> class paths (dependency). Is there a solution for this?
> Like I hinted above this is not a XmlBeans specific problem as a project can 
> have other tools generating code using e.g. XSLT, AntLR etc (my project uses 
> XSLT as well). There are many advantages using Maven and two important ones 
> are with it and Eclipse:
> 1) the project is built the same (i.e. using the exact same setup of 
> libraries, library versions etc) whether is it inside or outside Eclipse
> 2) all developers have the exact same setup (same version of dependencies etc)
> Are there any other known (potential) issues preventing Eclipse and Maven 
> from working seamlessly?
> Can the Eclipses built-in compiler cause problems?

-- 
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: (MNGECLIPSE-75) Update source folders action should set default output folder

[Ray Tsang (JIRA)]

 [ http://jira.codehaus.org/browse/MNGECLIPSE-75?page=all ]

Ray Tsang updated MNGECLIPSE-75:


Attachment: set-output-folder.patch

> Update source folders action should set default output folder
> -
>
>  Key: MNGECLIPSE-75
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-75
>  Project: Maven 2.x Extension for Eclipse
> Type: New Feature

> Versions: 0.0.5
>  Environment: Linux. JDK 1.5. XmlBeans 2.x.
> Reporter: Jimisola Laursen
> Assignee: Eugene Kuleshov
>  Attachments: MNGECLIPSE-75.tar.gz, mngeclipse-75-xmlbeans-testcase.zip, 
> set-output-folder.patch, set-output-folder.patch
>
>
> I have a problem with Maven2, XmlBeans Maven Plugin and this plugin (Eclipse 
> Maven Plugin). However, I do believe that the problem will exist when 
> generating sources in other ways as well. I assume that you are  familiar 
> with XmlBeans (if not, it's Java Binding tools that creates Java classes for 
> an XML Schema).
> In my project I use XmlBeans when performing unit tests. Hence, the XmlBeans 
> Maven Plugin generates Java code under /target/test-xmlbeans-source. The 
> actual problem is that Eclipse needs the generated Java code otherwise it 
> generates errors since it can't find the classes used by the unit tests. I 
> want the Maven plugin to add classes of auto-generated source code to Eclipse 
> class paths (dependency). Is there a solution for this?
> Like I hinted above this is not a XmlBeans specific problem as a project can 
> have other tools generating code using e.g. XSLT, AntLR etc (my project uses 
> XSLT as well). There are many advantages using Maven and two important ones 
> are with it and Eclipse:
> 1) the project is built the same (i.e. using the exact same setup of 
> libraries, library versions etc) whether is it inside or outside Eclipse
> 2) all developers have the exact same setup (same version of dependencies etc)
> Are there any other known (potential) issues preventing Eclipse and Maven 
> from working seamlessly?
> Can the Eclipses built-in compiler cause problems?

-- 
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-38) Allow custom code formatters to be written to .settings

[Paul Miles (JIRA)]

[ http://jira.codehaus.org/browse/MECLIPSE-38?page=comments#action_60546 ] 

Paul Miles commented on MECLIPSE-38:


Directly related to this is adding other project-specific settings, such as 
configuring Eclipse's compiler error and warning settings, etc.

> Allow custom code formatters to be written to .settings
> ---
>
>  Key: MECLIPSE-38
>  URL: http://jira.codehaus.org/browse/MECLIPSE-38
>  Project: Maven 2.x Eclipse Plugin
> Type: Bug

> Versions: 2.0
> Reporter: Mark Hobson

>
>
> It'd be handy if there was a way of embedding custom code formatters to 
> .settings.  Eclipse can currently export code formatter profiles as a list of 
> properties in an XML format, so this file could be configured against the 
> eclipse plugin for it to generate the corresponding properties-format 
> .settings/org.eclipse.jdt.core.prefs file.

-- 
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: (MPIR-34) Update the i18n properties file with these new additions

[Edwin Punzalan (JIRA)]

Update the i18n properties file with these new additions


 Key: MPIR-34
 URL: http://jira.codehaus.org/browse/MPIR-34
 Project: Maven 2.x Project Info Reports Plugin
Type: Task

Reporter: Edwin Punzalan


These have been added:


report.dependencies.graph.title=Project Dependency Graph
report.dependencies.graph.tree.title=Dependency Tree
report.dependencies.graph.tables.title=Dependency Listings
report.dependencies.graph.tables.column.groupid=GroupId
report.dependencies.graph.tables.column.artifactid=ArtifactId
report.dependencies.graph.tables.column.version=Version
report.dependencies.graph.tables.column.comments=Comments
report.dependencies.graph.tables.attached=Attached
report.dependencies.graph.tables.notAttached=Not attached

report.summary.title=Project Summary
report.summary.name=Project Summary
report.summary.description=This document lists other related information of 
this project
report.summary.field=Field
report.summary.value=Value
report.summary.general.title=Project Information
report.summary.general.name=Name
report.summary.general.description=Description
report.summary.general.homepage=Homepage
report.summary.build.title=Build Information
report.summary.build.groupid=GroupId
report.summary.build.artifactid=ArtifactId
report.summary.build.version=Version
report.summary.build.type=Type
report.summary.organization.title=Project Organization
report.summary.organization.name=Name
report.summary.organization.url=URL


-- 
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