[jira] Commented: (MPJAR-44) linefeeds in pom fields result in corrupt jar manifest

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MPJAR-44?page=comments#action_63474 ] 

Jerome Lacoste commented on MPJAR-44:
-

As said in PLX-185 the issue is that the plexus archiver doesn't add the 
missing space before each continuation line. Nothing to do with line feeds.

> linefeeds in pom fields result in corrupt jar manifest
> --
>
>  Key: MPJAR-44
>  URL: http://jira.codehaus.org/browse/MPJAR-44
>  Project: maven-jar-plugin
> Type: Bug

> Reporter: Brett Porter

>
>
> (originally filed by Timo Santasalo )
> When the plugin creates manifest using data from pom, certain fields (such as 
> shortDescription, I didn't test others but I see no reason why this issue 
> won't affect them as well) doesn't seem to be properly filtered of disallowed 
> characters, such as linefeeds.
> For example, the following piece of pom:
>   
>  blah blah
>  blah blah
>   
> ...becomes in manifest something like this:
> Specification-Title: blah blah
>  blah blah
> ...resulting in corrupted manifest.

-- 
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: (MJAR-6) dependencies woth scope "test" are included in Extension-List of the manifest

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MJAR-6?page=all ]

Jerome Lacoste updated MJAR-6:
--

Attachment: MJAR-6.diff

> dependencies woth scope "test" are included in Extension-List of the manifest
> -
>
>  Key: MJAR-6
>  URL: http://jira.codehaus.org/browse/MJAR-6
>  Project: Maven 2.x Jar Plugin
> Type: Bug

>  Environment: Any
> Reporter: Pascal Grange
>  Attachments: MJAR-6.diff
>
>
> When activating the Extension-List generation for the jar-plugin :
> 
> 
>   
> org.apache.maven.plugins
> maven-jar-plugin
> 
> 
>   true
> 
> ...
> Event the dependencies that have only a test scope such as junit, for 
> instance, are included in the manifest.
>

-- 
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: (MJAR-35) Abstraction for JarSignMojo so that webstart plugin can allow the user to choose how their jars are signed

[David Boden (JIRA)]

 [ http://jira.codehaus.org/browse/MJAR-35?page=all ]

David Boden updated MJAR-35:


Attachment: lehmanjarsigner-1.0-src.zip

> Abstraction for JarSignMojo so that webstart plugin can allow the user to 
> choose how their jars are signed
> --
>
>  Key: MJAR-35
>  URL: http://jira.codehaus.org/browse/MJAR-35
>  Project: Maven 2.x Jar Plugin
> Type: New Feature

> Reporter: David Boden
>  Attachments: JarSignerMojo.java, MJAR-35.diff, lehmanjarsigner-1.0-src.zip
>
>
> The webstart Maven 2 plugin signs jar files as part of its operation. At the 
> moment, it relies upon JarSignMojo to do this.
> While this is going to be correct 90% of the time, sometimes users (like 
> myself!) need to ask the webstart plugin to sign jars in a different way.
> Specifically, my company keeps its private key separate and provides an HTTP 
> Post interface to allow me to submit jars for signing. I've got a Mojo to do 
> this.
> What I need is for the webstart plugin to use an abstraction defined in an 
> interface called JarSignerMojo (attached to this issue) rather than 
> JarSignMojo. That way, I can plug my own Mojo in to be used instead of 
> JarSignMojo. Jerome Lacoste is doing the webstart plugin development and is 
> happy to accommodate this change if we can get the interface added to the jar 
> plugin project.
> The only change to the existing code is that JarSignMojo's class declaration 
> needs to be changed to:
> public class JarSignMojo extends AbstractMojo implements JarSignerMojo

-- 
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-78) Attaching javadocs to dependent libraries is misleadingly made possible.

[Dimitry Voytenko (JIRA)]

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

Dimitry Voytenko updated MNGECLIPSE-78:
---

Attachment: JavaDocBundling.patch

> Attaching javadocs to dependent libraries is misleadingly made possible.
> 
>
>  Key: MNGECLIPSE-78
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-78
>  Project: Maven 2.x Extension for Eclipse
> Type: Bug

>   Components: Dependency Resolver
> Versions: 0.0.5
> Reporter: Tuomas Kiviaho
> Assignee: Eugene Kuleshov
>  Attachments: JavaDocBundling.patch
>
>
> I noticed that even though I'm able to edit javadoc locations and 
> successfully verify them, applying the changes has not yet any effect. Next 
> time looking at the lib the change just made has vanished. 
> It's sad that pom.xml doesn't support yet javadoc outside the project  
> , but at least repositories could 
> be used in same manner as for java source lookups. 

-- 
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: (MAVEN-1345) Upgrade to dom4j 1.4

[Arnaud Heritier (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1345?page=comments#action_63486 ] 

Arnaud Heritier commented on MAVEN-1345:


This is a very good thing. Did you contact the dom4j team to see if a release 
planned ?

> Upgrade to dom4j 1.4
> 
>
>  Key: MAVEN-1345
>  URL: http://jira.codehaus.org/browse/MAVEN-1345
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.0-rc3
> Reporter: Paul Libbrecht
> Assignee: Brett Porter
> Priority: Critical
>  Fix For: 1.1-beta-3

>
>
> Currently, Maven relies on dom4j beta 8.
> This is bad in many respects, the worst being that the XML output, for 
> example provided by Jelly XML plugin, has wrong xmlns attributes.
> At least the 1.5 betas of dom4j all fix this, they also fix the html output 
> which was, otherwise, inserting random (kind-of) spaces in the text.

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

[jira] Created: (MRELEASE-90) Exception if version is SNAPSHOT

[Joerg Schaible (JIRA)]

Exception if version is SNAPSHOT


 Key: MRELEASE-90
 URL: http://jira.codehaus.org/browse/MRELEASE-90
 Project: Maven 2.x Release Plugin
Type: Bug

Versions: 2.0-beta-3
Reporter: Joerg Schaible


If the project has a very simple version scheme (i.e. only a simple number) and 
has therefore set the verstion tag to "SNAPSHOT", the plugin fails with a 
StringIndexOutOfRange exception:

[INFO] [release:prepare]
[INFO] Verifying there are no local modifications ...
[INFO] Checking lineage for snapshots ...
[INFO] Checking dependencies for snapshots ...
[INFO] Checking plugins for snapshots ...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] String index out of range: -1
[INFO] 
[INFO] Trace
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1444)
at 
org.apache.maven.plugins.release.helpers.ProjectVersionResolver.resolveVersion(ProjectVersionResolver.java:61)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:219)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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:324)
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] 


-- 
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: (MPA-62) Board Report for April

[Jason van Zyl (JIRA)]

Board Report for April
--

 Key: MPA-62
 URL: http://jira.codehaus.org/browse/MPA-62
 Project: Maven Project Administration
Type: Task

Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-63) Bring maven-dependency-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

Bring maven-dependency-plugin over from the Codehaus Mojo project
-

 Key: MPA-63
 URL: http://jira.codehaus.org/browse/MPA-63
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Brett Porter 
 Fix For: 2006-q1




-- 
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: (MPA-64) Bring maven-jxr-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

Bring maven-jxr-plugin over from the Codehaus Mojo project
--

 Key: MPA-64
 URL: http://jira.codehaus.org/browse/MPA-64
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-65) Bring the maven-surefire-report-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

Bring the maven-surefire-report-plugin over from the Codehaus Mojo project
--

 Key: MPA-65
 URL: http://jira.codehaus.org/browse/MPA-65
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MJAR-37) HttpJarSignClient - New goal "httpsign" which will sign jar files by submitting them to a signing service via HTTP Post

[David Boden (JIRA)]

HttpJarSignClient - New goal "httpsign" which will sign jar files by submitting 
them to a signing service via HTTP Post
---

 Key: MJAR-37
 URL: http://jira.codehaus.org/browse/MJAR-37
 Project: Maven 2.x Jar Plugin
Type: Improvement

Reporter: David Boden
 Attachments: jar-plugin-newfiles.zip, jarplugin.diff

The patch and new files attached to this issue are newer and make the 
contributions in MJAR-35 obsolete.

There is a test pom.xml that you can do a "mvn install" on to see the new goal 
working.

-- 
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: (MPA-65) Bring the maven-surefire-report-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-65?page=all ]
 
Jason van Zyl closed MPA-65:


Resolution: Fixed

> Bring the maven-surefire-report-plugin over from the Codehaus Mojo project
> --
>
>  Key: MPA-65
>  URL: http://jira.codehaus.org/browse/MPA-65
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-63) Bring maven-dependency-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-63?page=all ]
 
Jason van Zyl closed MPA-63:


Resolution: Fixed

> Bring maven-dependency-plugin over from the Codehaus Mojo project
> -
>
>  Key: MPA-63
>  URL: http://jira.codehaus.org/browse/MPA-63
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Brett Porter
>  Fix For: 2006-q1

>
>


-- 
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: (MJAR-35) Abstraction for JarSignMojo so that webstart plugin can allow the user to choose how their jars are signed

[David Boden (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-35?page=comments#action_63489 ] 

David Boden commented on MJAR-35:
-

Better diff and new file zip have been added to MJAR-37 . Ignore the 
attachments to this issue. Thanks!

> Abstraction for JarSignMojo so that webstart plugin can allow the user to 
> choose how their jars are signed
> --
>
>  Key: MJAR-35
>  URL: http://jira.codehaus.org/browse/MJAR-35
>  Project: Maven 2.x Jar Plugin
> Type: New Feature

> Reporter: David Boden
>  Attachments: JarSignerMojo.java, MJAR-35.diff, lehmanjarsigner-1.0-src.zip
>
>
> The webstart Maven 2 plugin signs jar files as part of its operation. At the 
> moment, it relies upon JarSignMojo to do this.
> While this is going to be correct 90% of the time, sometimes users (like 
> myself!) need to ask the webstart plugin to sign jars in a different way.
> Specifically, my company keeps its private key separate and provides an HTTP 
> Post interface to allow me to submit jars for signing. I've got a Mojo to do 
> this.
> What I need is for the webstart plugin to use an abstraction defined in an 
> interface called JarSignerMojo (attached to this issue) rather than 
> JarSignMojo. That way, I can plug my own Mojo in to be used instead of 
> JarSignMojo. Jerome Lacoste is doing the webstart plugin development and is 
> happy to accommodate this change if we can get the interface added to the jar 
> plugin project.
> The only change to the existing code is that JarSignMojo's class declaration 
> needs to be changed to:
> public class JarSignMojo extends AbstractMojo implements JarSignerMojo

-- 
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: (MPA-64) Bring maven-jxr-plugin over from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-64?page=all ]
 
Jason van Zyl closed MPA-64:


Resolution: Fixed

> Bring maven-jxr-plugin over from the Codehaus Mojo project
> --
>
>  Key: MPA-64
>  URL: http://jira.codehaus.org/browse/MPA-64
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-66) Move maven-changelog-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

Move maven-changelog-plugin from the Codehaus Mojo project
--

 Key: MPA-66
 URL: http://jira.codehaus.org/browse/MPA-66
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 




-- 
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: (MPA-66) Move maven-changelog-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-66?page=all ]
 
Jason van Zyl closed MPA-66:


Resolution: Fixed

> Move maven-changelog-plugin from the Codehaus Mojo project
> --
>
>  Key: MPA-66
>  URL: http://jira.codehaus.org/browse/MPA-66
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl

>
>


-- 
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: (MPA-67) Move C# plugins in the Plugins Sandbox

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-67?page=all ]
 
Jason van Zyl closed MPA-67:


Resolution: Fixed

> Move C# plugins in the Plugins Sandbox
> --
>
>  Key: MPA-67
>  URL: http://jira.codehaus.org/browse/MPA-67
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl

>
>


-- 
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: (MPA-68) Move NUnit plugin into the Plugins Sandbox

[Jason van Zyl (JIRA)]

Move NUnit plugin into the Plugins Sandbox
--

 Key: MPA-68
 URL: http://jira.codehaus.org/browse/MPA-68
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-67) Move C# plugins in the Plugins Sandbox

[Jason van Zyl (JIRA)]

Move C# plugins in the Plugins Sandbox
--

 Key: MPA-67
 URL: http://jira.codehaus.org/browse/MPA-67
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 




-- 
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: (MPA-67) Move C# plugins in the Plugins Sandbox

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-67?page=all ]
 
Jason van Zyl closed MPA-67:


Resolution: Fixed

> Move C# plugins in the Plugins Sandbox
> --
>
>  Key: MPA-67
>  URL: http://jira.codehaus.org/browse/MPA-67
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-66) Move maven-changelog-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-66?page=all ]
 
Jason van Zyl reopened MPA-66:
--


> Move maven-changelog-plugin from the Codehaus Mojo project
> --
>
>  Key: MPA-66
>  URL: http://jira.codehaus.org/browse/MPA-66
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-66) Move maven-changelog-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-66?page=all ]

Jason van Zyl updated MPA-66:
-

Fix Version: 2006-q1

> Move maven-changelog-plugin from the Codehaus Mojo project
> --
>
>  Key: MPA-66
>  URL: http://jira.codehaus.org/browse/MPA-66
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-67) Move C# plugins in the Plugins Sandbox

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-67?page=all ]

Jason van Zyl updated MPA-67:
-

Fix Version: 2006-q1

> Move C# plugins in the Plugins Sandbox
> --
>
>  Key: MPA-67
>  URL: http://jira.codehaus.org/browse/MPA-67
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-67) Move C# plugins in the Plugins Sandbox

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-67?page=all ]
 
Jason van Zyl reopened MPA-67:
--


> Move C# plugins in the Plugins Sandbox
> --
>
>  Key: MPA-67
>  URL: http://jira.codehaus.org/browse/MPA-67
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-66) Move maven-changelog-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-66?page=all ]
 
Jason van Zyl closed MPA-66:


Resolution: Fixed

> Move maven-changelog-plugin from the Codehaus Mojo project
> --
>
>  Key: MPA-66
>  URL: http://jira.codehaus.org/browse/MPA-66
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-68) Move NUnit plugin into the Plugins Sandbox

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-68?page=all ]
 
Jason van Zyl closed MPA-68:


Resolution: Fixed

> Move NUnit plugin into the Plugins Sandbox
> --
>
>  Key: MPA-68
>  URL: http://jira.codehaus.org/browse/MPA-68
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-69) Add Stephane Nicoll to the PMC

[Jason van Zyl (JIRA)]

Add Stephane Nicoll to the PMC
--

 Key: MPA-69
 URL: http://jira.codehaus.org/browse/MPA-69
 Project: Maven Project Administration
Type: Task

  Components: New PMC Members  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-70) Add Fabrizio Giustina to the PMC

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-70?page=all ]
 
Jason van Zyl closed MPA-70:


Resolution: Fixed

> Add Fabrizio Giustina to the PMC
> 
>
>  Key: MPA-70
>  URL: http://jira.codehaus.org/browse/MPA-70
>  Project: Maven Project Administration
> Type: Task

>   Components: New PMC Members
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-70) Add Fabrizio Giustina to the PMC

[Jason van Zyl (JIRA)]

Add Fabrizio Giustina to the PMC


 Key: MPA-70
 URL: http://jira.codehaus.org/browse/MPA-70
 Project: Maven Project Administration
Type: Task

  Components: New PMC Members  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-69) Add Stephane Nicoll to the PMC

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-69?page=all ]
 
Jason van Zyl closed MPA-69:


Resolution: Fixed

> Add Stephane Nicoll to the PMC
> --
>
>  Key: MPA-69
>  URL: http://jira.codehaus.org/browse/MPA-69
>  Project: Maven Project Administration
> Type: Task

>   Components: New PMC Members
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


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

[jira] Created: (SCM-185) Validity check rejects valid protocol

[Joerg Schaible (JIRA)]

Validity check rejects valid protocol
-

 Key: SCM-185
 URL: http://jira.codehaus.org/browse/SCM-185
 Project: Maven SCM
Type: Bug

  Components: maven-scm-provider-svn  
Versions: 1.0-beta-2
Reporter: Joerg Schaible


According to the subversion manual a user can add arbitrary protocols by 
defining new tunnels in his local subversion configuration. Such definitions 
are necessary to tunnel ports, define the usage of a smart card, ... e.g. 
defining an entry in the tunnel section of the .subversion/config file to 
access over SSH protocol version 1 can be defined like:

ssh1=ssh -1

A repo would be accessed with "svn+ssh1://repo/url"

This is not possible, since the SvnScmProvider checks against a fixed set of 
protocols, which is not 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] Created: (MPA-71) Move maven-changes-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

Move maven-changes-plugin from the Codehaus Mojo project


 Key: MPA-71
 URL: http://jira.codehaus.org/browse/MPA-71
 Project: Maven Project Administration
Type: Task

  Components: New Projects  
Versions: 2006-q1
Reporter: Jason van Zyl
 Assigned to: Jason van Zyl 
 Fix For: 2006-q1




-- 
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: (MPA-71) Move maven-changes-plugin from the Codehaus Mojo project

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-71?page=all ]
 
Jason van Zyl closed MPA-71:


Resolution: Fixed

> Move maven-changes-plugin from the Codehaus Mojo project
> 
>
>  Key: MPA-71
>  URL: http://jira.codehaus.org/browse/MPA-71
>  Project: Maven Project Administration
> Type: Task

>   Components: New Projects
> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MPA-62) Board Report for April

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MPA-62?page=all ]
 
Jason van Zyl closed MPA-62:


Resolution: Fixed

> Board Report for April
> --
>
>  Key: MPA-62
>  URL: http://jira.codehaus.org/browse/MPA-62
>  Project: Maven Project Administration
> Type: Task

> Versions: 2006-q1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl
>  Fix For: 2006-q1

>
>


-- 
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: (MJAR-37) HttpJarSignClient - New goal "httpsign" which will sign jar files by submitting them to a signing service via HTTP Post

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-37?page=comments#action_63493 ] 

Jerome Lacoste commented on MJAR-37:


In case we don't want the official maven-jar-plugin to depend on httpclient, 
another solution is to:

1- check MJAR-35 as is
2- move this mojo to a plugin to the mojo plugin



> HttpJarSignClient - New goal "httpsign" which will sign jar files by 
> submitting them to a signing service via HTTP Post
> ---
>
>  Key: MJAR-37
>  URL: http://jira.codehaus.org/browse/MJAR-37
>  Project: Maven 2.x Jar Plugin
> Type: Improvement

> Reporter: David Boden
>  Attachments: jar-plugin-newfiles.zip, jarplugin.diff
>
>
> The patch and new files attached to this issue are newer and make the 
> contributions in MJAR-35 obsolete.
> There is a test pom.xml that you can do a "mvn install" on to see the new 
> goal working.

-- 
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: (MNGECLIPSE-78) Attaching javadocs to dependent libraries is misleadingly made possible.

[Eugene Kuleshov (JIRA)]

 [ http://jira.codehaus.org/browse/MNGECLIPSE-78?page=all ]
 
Eugene Kuleshov closed MNGECLIPSE-78:
-

 Resolution: Fixed
Fix Version: 0.0.6

Patch applied. Thanks Dmitri.

> Attaching javadocs to dependent libraries is misleadingly made possible.
> 
>
>  Key: MNGECLIPSE-78
>  URL: http://jira.codehaus.org/browse/MNGECLIPSE-78
>  Project: Maven 2.x Extension for Eclipse
> Type: Bug

>   Components: Dependency Resolver
> Versions: 0.0.5
> Reporter: Tuomas Kiviaho
> Assignee: Eugene Kuleshov
>  Fix For: 0.0.6
>  Attachments: JavaDocBundling.patch
>
>
> I noticed that even though I'm able to edit javadoc locations and 
> successfully verify them, applying the changes has not yet any effect. Next 
> time looking at the lib the change just made has vanished. 
> It's sad that pom.xml doesn't support yet javadoc outside the project  
> , but at least repositories could 
> be used in same manner as for java source lookups. 

-- 
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-653) java.lang.OutOfMemoryError

[Emmanuel Venisse (JIRA)]

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

Emmanuel Venisse commented on CONTINUUM-653:


it seems to be fixed with my latest changes, but need more tests on machines 
where it occured.

> java.lang.OutOfMemoryError
> --
>
>  Key: CONTINUUM-653
>  URL: http://jira.codehaus.org/browse/CONTINUUM-653
>  Project: Continuum
> Type: Bug

> Versions: 1.0.3
> Reporter: Arnaud Heritier
> Priority: Blocker
>  Fix For: 1.0.3
>  Attachments: wrapper.log, wrapper.log
>
>
> After some hours, continuum fails, the projects list is empty.

-- 
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: (MJAR-37) HttpJarSignClient - New goal "httpsign" which will sign jar files by submitting them to a signing service via HTTP Post

[Arik Kfir (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-37?page=comments#action_63496 ] 

Arik Kfir commented on MJAR-37:
---

Just an idea - this can be a cool Plexus component (JAR signing, that 
is...especially by HTTP)

> HttpJarSignClient - New goal "httpsign" which will sign jar files by 
> submitting them to a signing service via HTTP Post
> ---
>
>  Key: MJAR-37
>  URL: http://jira.codehaus.org/browse/MJAR-37
>  Project: Maven 2.x Jar Plugin
> Type: Improvement

> Reporter: David Boden
>  Attachments: jar-plugin-newfiles.zip, jarplugin.diff
>
>
> The patch and new files attached to this issue are newer and make the 
> contributions in MJAR-35 obsolete.
> There is a test pom.xml that you can do a "mvn install" on to see the new 
> goal working.

-- 
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: (MAVEN-1345) Upgrade to dom4j 1.4

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1345?page=all ]

Lukas Theussl updated MAVEN-1345:
-

 Priority: Blocker  (was: Critical)
Assign To: Lukas Theussl  (was: Brett Porter)
 type: Task  (was: Bug)

Yes, I left a request at the link above, but didn't get a response yet. I'm 
thinking about putting our own version on ibiblio, I have tested it since my 
comment above and haven't found any issues. WDYT?

I'm putting this to blocker status now as we have to resolve at least the 
licensing issue and also to mark it as something we _really_ have to fix for 
beta-3 (contrary to most of what is scheduled now ;) ). Note that if we manage 
to upgrade dom4j, we have to publish new versions of the changes and xdoc 
plugins which will need a dependency on jaxen too because of API changes in 
dom4j. :(

> Upgrade to dom4j 1.4
> 
>
>  Key: MAVEN-1345
>  URL: http://jira.codehaus.org/browse/MAVEN-1345
>  Project: Maven
> Type: Task

>   Components: core
> Versions: 1.0-rc3
> Reporter: Paul Libbrecht
> Assignee: Lukas Theussl
> Priority: Blocker
>  Fix For: 1.1-beta-3

>
>
> Currently, Maven relies on dom4j beta 8.
> This is bad in many respects, the worst being that the XML output, for 
> example provided by Jelly XML plugin, has wrong xmlns attributes.
> At least the 1.5 betas of dom4j all fix this, they also fix the html output 
> which was, otherwise, inserting random (kind-of) spaces in the text.

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

[jira] Created: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs

[Marcel Schutte (JIRA)]

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


 Key: MRELEASE-91
 URL: http://jira.codehaus.org/browse/MRELEASE-91
 Project: Maven 2.x Release Plugin
Type: Bug

Versions: 2.0-beta-4
 Environment: maven 2.0.4, win XP
Reporter: Marcel Schutte
 Attachments: release.patch

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

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

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

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

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

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

[jira] Commented: (MAVEN-1711) Error reading POM

[Lukas Theussl (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1711?page=comments#action_63500 ] 

Lukas Theussl commented on MAVEN-1711:
--

Arnaud, I cannot reproduce this. I can put as many blank lines and whitespace 
in front of  as I want, I don't see this error. Are you sure that you 
don't have a tab instead of a space somewhere? Can you attach a stand-alone pom 
that gives you the error?

> Error reading POM
> -
>
>  Key: MAVEN-1711
>  URL: http://jira.codehaus.org/browse/MAVEN-1711
>  Project: Maven
> Type: Bug

>   Components: model
> Versions: 1.1-beta-3
>  Environment: 1.1 beta 3 2005-10-11
> Reporter: Arnaud Heritier
>  Fix For: 1.1-beta-3
>  Attachments: MAVEN-1711-log.txt, project.xml
>
>
> In some cases, maven breaks because it can't read a POM.
> It occurs when there's for exemple a blank line just before the  tag.
> I already saw this error several times and it must occurs with all 1.1 
> releases.
> We must try to upgrade plexus-utils to see if it fixes the problem.

-- 
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: (MAVEN-1675) Unable to extract maven-nsis-plugin-1.1.jar

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1675?page=all ]
 
Lukas Theussl closed MAVEN-1675:


  Assign To: Lukas Theussl
 Resolution: Incomplete
Fix Version: (was: 1.1-beta-3)

> Unable to extract maven-nsis-plugin-1.1.jar
> ---
>
>  Key: MAVEN-1675
>  URL: http://jira.codehaus.org/browse/MAVEN-1675
>  Project: Maven
> Type: Bug

>   Components: plugin manager
> Versions: 1.0.2
>  Environment: Solaris 5.8, JDK 1.5.0
> Reporter: Alex Mayorga Adame
> Assignee: Lukas Theussl

>
>
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> Initializing Plugins!
> Set plugin source directory to /export1/eae/CIBOS/maven-1.0.2/plugins
> Set unpacked plugin directory to /export1/CIBOS/maven-1.0.2/.maven/cache
> Set user plugin directory to /export1/CIBOS/maven-1.0.2/.maven/plugins
> Plugin cache will be regenerated
> Unpacking maven-nsis-plugin-1.1.jar to directory --> 
> /export1/CIBOS/maven-1.0.2/.maven/cache/maven-nsis-plugin-1.1
> Invalidating plugin maven-nsis-plugin-1.1
> org.apache.maven.MavenException: Unable to extract plugin: 
> /export1/eae/CIBOS/maven-1.0.2/plugins/maven-nsis-plugin-1.1.jar
> at 
> org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1075)
> at 
> org.apache.maven.plugin.PluginManager.expandPluginFiles(PluginManager.java:321)
> at 
> org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:288)
> at 
> org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204)
> at org.apache.maven.MavenSession.initialize(MavenSession.java:171)
> at org.apache.maven.cli.App.doMain(App.java:475)
> at org.apache.maven.cli.App.main(App.java:1239)
> 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 com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> --- Nested Exception ---
> java.io.FileNotFoundException: 
> /export1/CIBOS/maven-1.0.2/.maven/cache/maven-nsis-plugin-1.1/META-INF/MANIFEST.MF
>  (No such file or directory)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(FileOutputStream.java:179)
> at java.io.FileOutputStream.(FileOutputStream.java:131)
> at org.apache.maven.util.Expand.extractFile(Expand.java:147)
> at org.apache.maven.util.Expand.expandFile(Expand.java:85)
> at org.apache.maven.util.Expand.execute(Expand.java:67)
> at 
> org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1071)
> at 
> org.apache.maven.plugin.PluginManager.expandPluginFiles(PluginManager.java:321)
> at 
> org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:288)
> at 
> org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204)
> at org.apache.maven.MavenSession.initialize(MavenSession.java:171)
> at org.apache.maven.cli.App.doMain(App.java:475)
> at org.apache.maven.cli.App.main(App.java:1239)
> 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 com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> You have encountered an unknown error running Maven. Please help us to 
> correct 
> this problem by following these simple steps:
> - read the Maven FAQ at http://maven.apache.org/faq.html
> - run the same command again with the '-e' parameter, eg maven -e jar
> - search the maven-user archives for the error at
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
> - post the output of maven -e to JIRA at
> http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up first)
> - run 'maven --info' and post the output as the environment to the bug above
> Final Memory: 0M/4M
> Total time: 2 seconds
> Finished at: Thu Aug 25 11:22:18 EDT 2005
> The user that is running maven is the owner of all folders, why is this 
> failing?

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

[jira] Created: (MRELEASE-92) PerformMojo throws an error if there are no process args

[Daun DeFrance (JIRA)]

PerformMojo throws an error if there are no process args


 Key: MRELEASE-92
 URL: http://jira.codehaus.org/browse/MRELEASE-92
 Project: Maven 2.x Release Plugin
Type: Bug

Versions: 2.0-beta-5
 Environment: winxp, maven 2.0.4
Reporter: Daun DeFrance


While reading the process, PerformReleasMojo.getSystemEnvVars looks for an '=' 
and then tries to get substrings on either side to form key/value properties.  
Under my environment, the index of '=' is -1 and the code does not guard before 
trying to grab a substring with this index.

I will attach the diff file of the (very minor) fix to workaround this problem.

-- 
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: (MRELEASE-92) PerformMojo throws an error if there are no process args

[Daun DeFrance (JIRA)]

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

Daun DeFrance updated MRELEASE-92:
--

Attachment: MRELEASE-92.patch

> PerformMojo throws an error if there are no process args
> 
>
>  Key: MRELEASE-92
>  URL: http://jira.codehaus.org/browse/MRELEASE-92
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Versions: 2.0-beta-5
>  Environment: winxp, maven 2.0.4
> Reporter: Daun DeFrance
>  Attachments: MRELEASE-92.patch
>
>
> While reading the process, PerformReleasMojo.getSystemEnvVars looks for an 
> '=' and then tries to get substrings on either side to form key/value 
> properties.  Under my environment, the index of '=' is -1 and the code does 
> not guard before trying to grab a substring with this index.
> I will attach the diff file of the (very minor) fix to workaround this 
> problem.

-- 
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: (MAVEN-1711) Error reading POM

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1711?page=all ]

Arnaud Heritier updated MAVEN-1711:
---

Attachment: project.xml

> Error reading POM
> -
>
>  Key: MAVEN-1711
>  URL: http://jira.codehaus.org/browse/MAVEN-1711
>  Project: Maven
> Type: Bug

>   Components: model
> Versions: 1.1-beta-3
>  Environment: 1.1 beta 3 2005-10-11
> Reporter: Arnaud Heritier
>  Fix For: 1.1-beta-3
>  Attachments: MAVEN-1711-log.txt, project.xml, project.xml
>
>
> In some cases, maven breaks because it can't read a POM.
> It occurs when there's for exemple a blank line just before the  tag.
> I already saw this error several times and it must occurs with all 1.1 
> releases.
> We must try to upgrade plexus-utils to see if it fixes the problem.

-- 
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: (MAVEN-1711) Error reading POM

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1711?page=all ]
 
Arnaud Heritier closed MAVEN-1711:
--

 Assign To: Arnaud Heritier
Resolution: Duplicate

The resolution duplicates MAVEN-1707

> Error reading POM
> -
>
>  Key: MAVEN-1711
>  URL: http://jira.codehaus.org/browse/MAVEN-1711
>  Project: Maven
> Type: Bug

>   Components: model
> Versions: 1.1-beta-3
>  Environment: 1.1 beta 3 2005-10-11
> Reporter: Arnaud Heritier
> Assignee: Arnaud Heritier
>  Fix For: 1.1-beta-3
>  Attachments: MAVEN-1711-log.txt, project.xml, project.xml
>
>
> In some cases, maven breaks because it can't read a POM.
> It occurs when there's for exemple a blank line just before the  tag.
> I already saw this error several times and it must occurs with all 1.1 
> releases.
> We must try to upgrade plexus-utils to see if it fixes the problem.

-- 
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: (MASSEMBLY-83) POMs are not being placed in generated repository structure

[Jason van Zyl (JIRA)]

POMs are not being placed in generated repository structure
---

 Key: MASSEMBLY-83
 URL: http://jira.codehaus.org/browse/MASSEMBLY-83
 Project: Maven 2.x Assembly Plugin
Type: Bug

Versions: 2.1
Reporter: Jason van Zyl




-- 
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: (MASSEMBLY-83) POMs are not being placed in generated repository structure

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-83?page=all ]
 
Jason van Zyl closed MASSEMBLY-83:
--

Resolution: Fixed

> POMs are not being placed in generated repository structure
> ---
>
>  Key: MASSEMBLY-83
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-83
>  Project: Maven 2.x Assembly Plugin
> Type: Bug

> Versions: 2.1
> Reporter: Jason van Zyl
> Assignee: Jason van Zyl

>
>


-- 
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: (MASSEMBLY-84) Provide an option to align all the versions of artifacts having the same groupId

[Jason van Zyl (JIRA)]

Provide an option to align all the versions of artifacts having the same groupId


 Key: MASSEMBLY-84
 URL: http://jira.codehaus.org/browse/MASSEMBLY-84
 Project: Maven 2.x Assembly Plugin
Type: New Feature

Reporter: Jason van Zyl


When creating an assembly you may want to force a particular version of an 
artifact to use in your repository. Allow this first by groupId as it makes it 
easy to select a whole set of artifacts, say for groupId = org.apache.maven.

-- 
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: (MASSEMBLY-84) Provide an option to align all the versions of artifacts having the same groupId

[Jason van Zyl (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-84?page=all ]
 
Jason van Zyl closed MASSEMBLY-84:
--

Resolution: Fixed

> Provide an option to align all the versions of artifacts having the same 
> groupId
> 
>
>  Key: MASSEMBLY-84
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-84
>  Project: Maven 2.x Assembly Plugin
> Type: New Feature

> Reporter: Jason van Zyl
> Assignee: Jason van Zyl

>
>
> When creating an assembly you may want to force a particular version of an 
> artifact to use in your repository. Allow this first by groupId as it makes 
> it easy to select a whole set of artifacts, say for groupId = 
> org.apache.maven.

-- 
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: (MASSEMBLY-85) Parent POMs are not pulled down into the assembled repository

[Jason van Zyl (JIRA)]

Parent POMs are not pulled down into the assembled repository
-

 Key: MASSEMBLY-85
 URL: http://jira.codehaus.org/browse/MASSEMBLY-85
 Project: Maven 2.x Assembly Plugin
Type: Bug

Versions: 2.1
Reporter: Jason van Zyl




-- 
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: (MAVEN-1695) maven test-plugin silently ignores test definitions in the POM when run under maven 1.1 beta 2

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1695?page=all ]
 
Lukas Theussl closed MAVEN-1695:


 Assign To: Lukas Theussl
Resolution: Fixed

The pom:validate goal of pom-plugin-1.5 catches this.

> maven test-plugin silently ignores test definitions in the POM when run under 
> maven 1.1 beta 2
> --
>
>  Key: MAVEN-1695
>  URL: http://jira.codehaus.org/browse/MAVEN-1695
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-2
> Reporter: Henning Schmiedehausen
> Assignee: Lukas Theussl
>  Fix For: 1.1-beta-3

>
>
> use the following unitTest definition in your POM:
>
>   
> **/*Test.java
>   
>   
> **/Test*.java
>   
>   
> **/test/*.java
>   
> [...]
>   
> When running under maven 1.0.2, all Test classes that start with Test or end 
> with Test are executed. 
> When running under maven 1.1-beta2, only the classes starting with Test are 
> executed. The second  definition overrides the first. Under maven
> 1.0.2 the two definitions are added.
> According to my understanding of the xsd, there should either be a maxOccurs 
> to prevent this, an exception being thrown when encountering the second 
> includes or the old maven 1.0.2 behaviour being restored.
> This is a real world example. I ran into this when test driving the Jakarta 
> Turbine 2.3.2 RC1 with maven 1.1

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

[jira] Updated: (MNG-2225) Classloader problem when adding jars to M2_HOME

[Carlos Sanchez (JIRA)]

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

Carlos Sanchez updated MNG-2225:


Testcase included: yes
  Fix Version: 2.0.5

> Classloader problem when adding jars to M2_HOME
> ---
>
>  Key: MNG-2225
>  URL: http://jira.codehaus.org/browse/MNG-2225
>  Project: Maven 2
> Type: Bug

>   Components: Dependencies
> Versions: 2.0.4
> Reporter: Carlos Sanchez
> Priority: Critical
>  Fix For: 2.0.5
>  Attachments: testwagonscm.tgz
>
>
> Added these jars to M2_HOME/custom to allow using scm based remote repos
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-api/1.0-beta-2/maven-scm-api-1.0-beta-2.jar
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-manager-plexus/1.0-beta-2/maven-scm-manager-plexus-1.0-beta-2.jar
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-provider-svn/1.0-beta-2/maven-scm-provider-svn-1.0-beta-2.jar
> http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/wagon/wagon-scm/1.0-alpha-7-SNAPSHOT/wagon-scm-1.0-alpha-7-20060308.183410-3.jar
> bin/m2.conf
> main is org.apache.maven.cli.MavenCli from plexus.core.maven
> set maven.home default ${user.home}/m2
> [plexus.core]
> load ${maven.home}/core/*.jar
> [plexus.core.maven]
> load ${maven.home}/custom/*.jar
> load ${maven.home}/lib/*.jar
> When running "mvn install" and "mvn testwagonscm:test" in the attached test 
> case you get a ClassCastException although the Class to assign to and the 
> assigned one are the same. The problem seems to be that they come from 
> different classloaders. This problem makes the project-info-report:scm goal 
> fail.

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

[jira] Created: (MNG-2225) Classloader problem when adding jars to M2_HOME

[Carlos Sanchez (JIRA)]

Classloader problem when adding jars to M2_HOME
---

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

  Components: Dependencies  
Versions: 2.0.4
Reporter: Carlos Sanchez
Priority: Critical
 Fix For: 2.0.5
 Attachments: testwagonscm.tgz

Added these jars to M2_HOME/custom to allow using scm based remote repos

http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-api/1.0-beta-2/maven-scm-api-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-manager-plexus/1.0-beta-2/maven-scm-manager-plexus-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-provider-svn/1.0-beta-2/maven-scm-provider-svn-1.0-beta-2.jar
http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/wagon/wagon-scm/1.0-alpha-7-SNAPSHOT/wagon-scm-1.0-alpha-7-20060308.183410-3.jar


bin/m2.conf

main is org.apache.maven.cli.MavenCli from plexus.core.maven

set maven.home default ${user.home}/m2

[plexus.core]
load ${maven.home}/core/*.jar

[plexus.core.maven]
load ${maven.home}/custom/*.jar
load ${maven.home}/lib/*.jar




When running "mvn install" and "mvn testwagonscm:test" in the attached test 
case you get a ClassCastException although the Class to assign to and the 
assigned one are the same. The problem seems to be that they come from 
different classloaders. This problem makes the project-info-report:scm goal 
fail.

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

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

[Marcel Schutte (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-91?page=comments#action_63509 ] 

Marcel Schutte commented on MRELEASE-91:


I forgot to mention that I'm using the latest SVN of the release plugin.

> Updating of dependencyManagement inconsistent with updating of dependencies 
> with regard to SNAPSHOTs
> 
>
>  Key: MRELEASE-91
>  URL: http://jira.codehaus.org/browse/MRELEASE-91
>  Project: Maven 2.x Release Plugin
> Type: Bug

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

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

[jira] Closed: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1741?page=all ]
 
Lukas Theussl closed MAVEN-1741:


 Assign To: Lukas Theussl
Resolution: Duplicate

Same as MAVEN-1638.

> maven 1.1 fails to run commons-attributes in mutliproject mode on a war 
> project
> ---
>
>  Key: MAVEN-1741
>  URL: http://jira.codehaus.org/browse/MAVEN-1741
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-2
> Reporter: nicolas de loof
> Assignee: Lukas Theussl
> Priority: Minor
>  Fix For: 1.1-beta-3
>  Attachments: test_maven11_commons-attributes.zip
>
>
> Attached zip contains a minimalist multiproject using commons-attributes that 
> demonstrates the bug. 
> - head (top level project)
> - jar (minimalist jar project) : Sample.java has a "java.util.Date" attribute
> - war (minimalist war project) : Sample.java has a "java.util.Date" attribute
> When runing "maven war:install" on war project, attributes are generated as 
> expected.
> When running from "head" project using "maven multiproject:install", 
> commons-attributes are 
> - generated as expected for the jar
> - NOT generated in the war (no log from plugin)
> I don't know if this is a maven, multiproject-plugin, war-plugin or 
> commons-attributes-plugin bug.
> Please notice commons-attributes plugin uses a preGoal to automatically 
> register itself. 

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

[jira] Closed: (DOXIA-58) snapshot failed doxia-site-renderer-1.0-alpha-8-20060411.133534-1

[Olivier Lamy (JIRA)]

 [ http://jira.codehaus.org/browse/DOXIA-58?page=all ]
 
Olivier Lamy closed DOXIA-58:
-

Resolution: Fixed

The last maven-site-plugin snapshot saved me ;-)
In fact, this issue was better in maven-site-plugin project. (sorry)
Thanks,
Olivier

> snapshot failed doxia-site-renderer-1.0-alpha-8-20060411.133534-1
> -
>
>  Key: DOXIA-58
>  URL: http://jira.codehaus.org/browse/DOXIA-58
>  Project: doxia
> Type: Bug

>   Components: Site Renderer
> Versions: 1.0-alpha-8
>  Environment: all
> Reporter: Olivier Lamy

>
>
> with doxia-site-renderer-1.0-alpha-8-20060411.133534-1
> I have the stack trace 
> 
> [ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] 
> org.apache.maven.doxia.siterenderer.Renderer.render(Ljava/util/Collectio
> n;Lorg/apache/maven/d
> oxia/siterenderer/SiteRenderingContext;Ljava/io/File;Ljava/lang/String;)
> V
> [INFO]
> 
> [INFO] Trace
> java.lang.NoSuchMethodError: 
> org.apache.maven.doxia.siterenderer.Renderer.render(Ljava/util/Collecti
> on;Lorg/apache/maven/doxia/siterenderer/SiteRenderingContext;Ljava/io/Fi
> le;Ljava/lang/String;)V
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:121)
> at
> org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
> nager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
> LifecycleExecutor
> .java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
> ycle(DefaultLifec
> ycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL
> ifecycleExecutor.
> java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
> Failures(Default

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

[jira] Commented: (MRELEASE-92) PerformMojo throws an error if there are no process args

[Emmanuel Venisse (JIRA)]

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

Emmanuel Venisse commented on MRELEASE-92:
--

I'm not sure this patch is correct. If a line doesn't include "=" that mean 
previous env var have a carriage return so the line must be added to previous 
key.

> PerformMojo throws an error if there are no process args
> 
>
>  Key: MRELEASE-92
>  URL: http://jira.codehaus.org/browse/MRELEASE-92
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Versions: 2.0-beta-5
>  Environment: winxp, maven 2.0.4
> Reporter: Daun DeFrance
>  Attachments: MRELEASE-92.patch
>
>
> While reading the process, PerformReleasMojo.getSystemEnvVars looks for an 
> '=' and then tries to get substrings on either side to form key/value 
> properties.  Under my environment, the index of '=' is -1 and the code does 
> not guard before trying to grab a substring with this index.
> I will attach the diff file of the (very minor) fix to workaround this 
> problem.

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

[jira] Created: (MRELEASE-93) release:prepare loses POM prerequisite element

[Mike Perham (JIRA)]

release:prepare loses POM prerequisite element
--

 Key: MRELEASE-93
 URL: http://jira.codehaus.org/browse/MRELEASE-93
 Project: Maven 2.x Release Plugin
Type: Bug

Versions: 2.0-beta-4
Reporter: Mike Perham
Priority: Critical
 Fix For: 2.0-beta-4


I have a master POM which requires maven 2.0.4:


  2.0.4


When I release:prepare the POM, the new development version is missing that 
prerequisite element.  I'm using the release plugin bits from SVN.


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

[jira] Closed: (MRELEASE-93) release:prepare loses POM prerequisite element

[Mike Perham (JIRA)]

 [ http://jira.codehaus.org/browse/MRELEASE-93?page=all ]
 
Mike Perham closed MRELEASE-93:
---

Resolution: Duplicate

MRELEASE-64

> release:prepare loses POM prerequisite element
> --
>
>  Key: MRELEASE-93
>  URL: http://jira.codehaus.org/browse/MRELEASE-93
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Versions: 2.0-beta-4
> Reporter: Mike Perham
> Priority: Critical
>  Fix For: 2.0-beta-4

>
>
> I have a master POM which requires maven 2.0.4:
> 
>   2.0.4
> 
> When I release:prepare the POM, the new development version is missing that 
> prerequisite element.  I'm using the release plugin bits from SVN.

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

[jira] Commented: (MRELEASE-64) are stripped on release:prepare

[Mike Perham (JIRA)]

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

Mike Perham commented on MRELEASE-64:
-

I suspect this is because the release plugin is referencing maven-model 2.0.  
Didn't   come in 2.0.1?

>  are stripped on release:prepare
> ---
>
>  Key: MRELEASE-64
>  URL: http://jira.codehaus.org/browse/MRELEASE-64
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Reporter: Vincent Massol
> Assignee: Jason van Zyl
> Priority: Blocker

>
>
> {noformat} 
> Author: vmassol
> Date: Mon Dec 26 00:42:18 2005
> New Revision: 359040
> URL: http://svn.apache.org/viewcvs?rev=359040&view=rev
> Log:
> [maven-release-plugin] prepare release maven-clover-plugin-2.0
> Modified:
> maven/plugins/trunk/maven-clover-plugin/pom.xml
> Modified: maven/plugins/trunk/maven-clover-plugin/pom.xml
> URL: 
> http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-clover-plugin/pom.xml?rev=359040&r1=359039&r2=359040&view=diff
> ==
> --- maven/plugins/trunk/maven-clover-plugin/pom.xml (original)
> +++ maven/plugins/trunk/maven-clover-plugin/pom.xml Mon Dec 26 00:42:18 
> +++ 2005
> @@ -1,23 +1,20 @@
> -
> +
>
>  maven-plugin-parent
>  org.apache.maven.plugins
>  2.0.1
>
> -  
> -2.0.1
> -  
>4.0.0
>maven-clover-plugin
>maven-plugin
>Maven Clover Plugin
> -  2.0-SNAPSHOT
> +  2.0
>Maven plugin for Clover
> -  2005
>
>  jira
>  http://jira.codehaus.org/browse/MCLOVER
>
> +  2005
>
>  
>vmassol
> @@ -62,24 +59,4 @@
>2.0
>  
>
> -  
> -
> +
> \ No newline at end of file
> {noformat} 

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

[jira] Commented: (MRELEASE-64) are stripped on release:prepare

[Mike Perham (JIRA)]

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

Mike Perham commented on MRELEASE-64:
-

This is what I mean:


  org.apache.maven
  maven-project
  2.0


  org.apache.maven
  maven-core
  2.0



>  are stripped on release:prepare
> ---
>
>  Key: MRELEASE-64
>  URL: http://jira.codehaus.org/browse/MRELEASE-64
>  Project: Maven 2.x Release Plugin
> Type: Bug

> Reporter: Vincent Massol
> Assignee: Jason van Zyl
> Priority: Blocker

>
>
> {noformat} 
> Author: vmassol
> Date: Mon Dec 26 00:42:18 2005
> New Revision: 359040
> URL: http://svn.apache.org/viewcvs?rev=359040&view=rev
> Log:
> [maven-release-plugin] prepare release maven-clover-plugin-2.0
> Modified:
> maven/plugins/trunk/maven-clover-plugin/pom.xml
> Modified: maven/plugins/trunk/maven-clover-plugin/pom.xml
> URL: 
> http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-clover-plugin/pom.xml?rev=359040&r1=359039&r2=359040&view=diff
> ==
> --- maven/plugins/trunk/maven-clover-plugin/pom.xml (original)
> +++ maven/plugins/trunk/maven-clover-plugin/pom.xml Mon Dec 26 00:42:18 
> +++ 2005
> @@ -1,23 +1,20 @@
> -
> +
>
>  maven-plugin-parent
>  org.apache.maven.plugins
>  2.0.1
>
> -  
> -2.0.1
> -  
>4.0.0
>maven-clover-plugin
>maven-plugin
>Maven Clover Plugin
> -  2.0-SNAPSHOT
> +  2.0
>Maven plugin for Clover
> -  2005
>
>  jira
>  http://jira.codehaus.org/browse/MCLOVER
>
> +  2005
>
>  
>vmassol
> @@ -62,24 +59,4 @@
>2.0
>  
>
> -  
> -
> +
> \ No newline at end of file
> {noformat} 

-- 
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-90) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[Matthew Wheaton (JIRA)]

maven-surefire-plugin cannot test custom charset providers specified in 
META-INF/services/java.nio.charset.spi.CharsetProvider
--

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

 Environment: All
Reporter: Matthew Wheaton
 Assigned to: Brett Porter 
Priority: Blocker


maven-surefire-plugin cannot run a jUnit test for a custom charset provider 
specified in the jar file's 
META-INF/services/java.nio.charset.spi.CharsetProvider file. Class 
java.nio.charset.Charset performs a lookup using 
ClassLoader.getSystemClassLoader(); which does not have the jar file in its 
classpath and thus fails with e.g. junit.framework.AssertionFailedError: 
java.io.UnsupportedEncodingException: DIN_66003 although the jar file itself is 
correct. I think this is due to the plugin using its own classloader and the 
JDK using the system classloader but I may be totally wrong and everything is 
fine with the plugin.

The method from java.nio.charset.Charset performing the lookup beings with

private static Iterator providers() {
return new Iterator() {

Class c = java.nio.charset.spi.CharsetProvider.class;
ClassLoader cl = ClassLoader.getSystemClassLoader();
Iterator i = Service.providers(c, cl);
Object next = null;

As it seems org.codehaus.surefire.SurefireBooter does not promote the jar files 
to the classpath of the system classloader.


-- 
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-91) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[Matthew Wheaton (JIRA)]

maven-surefire-plugin cannot test custom charset providers specified in 
META-INF/services/java.nio.charset.spi.CharsetProvider
--

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

 Environment: All
Reporter: Matthew Wheaton
 Assigned to: Brett Porter 
Priority: Blocker


maven-surefire-plugin cannot run a jUnit test for a custom charset provider 
specified in the jar file's 
META-INF/services/java.nio.charset.spi.CharsetProvider file. Class 
java.nio.charset.Charset performs a lookup using 
ClassLoader.getSystemClassLoader(); which does not have the jar file in its 
classpath and thus fails with e.g. junit.framework.AssertionFailedError: 
java.io.UnsupportedEncodingException: DIN_66003 although the jar file itself is 
correct. I think this is due to the plugin using its own classloader and the 
JDK using the system classloader but I may be totally wrong and everything is 
fine with the plugin.

The method from java.nio.charset.Charset performing the lookup beings with

private static Iterator providers() {
return new Iterator() {

Class c = java.nio.charset.spi.CharsetProvider.class;
ClassLoader cl = ClassLoader.getSystemClassLoader();
Iterator i = Service.providers(c, cl);
Object next = null;

As it seems org.codehaus.surefire.SurefireBooter does not promote the jar files 
to the classpath of the system classloader.


-- 
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-91) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[Matthew Wheaton (JIRA)]

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

Matthew Wheaton commented on MSUREFIRE-91:
--

The original task for this was http://jira.codehaus.org/browse/MSUREFIRE-16 
which was deemed a duplicate issue.
I do not believe it is. I have the exact same problem as the original reporter. 
Standalone ANT/Junit with fork ON works just fine. Inside surefire it FAILS.
This means that surefire is NOT promoting the JAR contents to the boot 
classpath where CharsetProviders are resolved.
The same unit test works fine in Eclipse, as Eclipse essentially forks a new 
process to run as well.
Running under surefire/maven even with the fork option turned on in surefire 
still results in a failure.

> maven-surefire-plugin cannot test custom charset providers specified in 
> META-INF/services/java.nio.charset.spi.CharsetProvider
> --
>
>  Key: MSUREFIRE-91
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-91
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

>  Environment: All
> Reporter: Matthew Wheaton
> Assignee: Brett Porter
> Priority: Blocker

>
>
> maven-surefire-plugin cannot run a jUnit test for a custom charset provider 
> specified in the jar file's 
> META-INF/services/java.nio.charset.spi.CharsetProvider file. Class 
> java.nio.charset.Charset performs a lookup using 
> ClassLoader.getSystemClassLoader(); which does not have the jar file in its 
> classpath and thus fails with e.g. junit.framework.AssertionFailedError: 
> java.io.UnsupportedEncodingException: DIN_66003 although the jar file itself 
> is correct. I think this is due to the plugin using its own classloader and 
> the JDK using the system classloader but I may be totally wrong and 
> everything is fine with the plugin.
> The method from java.nio.charset.Charset performing the lookup beings with
> private static Iterator providers() {
>   return new Iterator() {
>   Class c = java.nio.charset.spi.CharsetProvider.class;
>   ClassLoader cl = ClassLoader.getSystemClassLoader();
>   Iterator i = Service.providers(c, cl);
>   Object next = null;
> As it seems org.codehaus.surefire.SurefireBooter does not promote the jar 
> files to the classpath of the system classloader.

-- 
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-90) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[Matthew Wheaton (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-90?page=all ]
 
Matthew Wheaton closed MSUREFIRE-90:


Resolution: Fixed

sorry, i have a more detailed one as MSUREFIRE-91

> maven-surefire-plugin cannot test custom charset providers specified in 
> META-INF/services/java.nio.charset.spi.CharsetProvider
> --
>
>  Key: MSUREFIRE-90
>  URL: http://jira.codehaus.org/browse/MSUREFIRE-90
>  Project: Maven 2.x Surefire Plugin
> Type: Bug

>  Environment: All
> Reporter: Matthew Wheaton
> Assignee: Brett Porter
> Priority: Blocker

>
>
> maven-surefire-plugin cannot run a jUnit test for a custom charset provider 
> specified in the jar file's 
> META-INF/services/java.nio.charset.spi.CharsetProvider file. Class 
> java.nio.charset.Charset performs a lookup using 
> ClassLoader.getSystemClassLoader(); which does not have the jar file in its 
> classpath and thus fails with e.g. junit.framework.AssertionFailedError: 
> java.io.UnsupportedEncodingException: DIN_66003 although the jar file itself 
> is correct. I think this is due to the plugin using its own classloader and 
> the JDK using the system classloader but I may be totally wrong and 
> everything is fine with the plugin.
> The method from java.nio.charset.Charset performing the lookup beings with
> private static Iterator providers() {
>   return new Iterator() {
>   Class c = java.nio.charset.spi.CharsetProvider.class;
>   ClassLoader cl = ClassLoader.getSystemClassLoader();
>   Iterator i = Service.providers(c, cl);
>   Object next = null;
> As it seems org.codehaus.surefire.SurefireBooter does not promote the jar 
> files to the classpath of the system classloader.

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

[Matthew Wheaton (JIRA)]

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

Matthew Wheaton commented on MSUREFIRE-77:
--

I've opened almost the identical issue.
http://jira.codehaus.org/browse/MSUREFIRE-91
This one is just about strike 3 for me and Maven2. ANT will be back in full 
swing if seemingly simple things like this cannot be fixed.

> 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
>  Fix For: 2.2

>
>
> 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] Closed: (CONTINUUM-653) java.lang.OutOfMemoryError

[Brett Porter (JIRA)]

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

 Assign To: Brett Porter
Resolution: Fixed

I was able to build all 135 Maven projects without any memory loss. first time 
started at 16, finished at 22 - this is the project cache. Next started at 22, 
finished at 22.

We can now run Continuum in -Xmx64m, though the current -Xmx128m is a good safe 
setting.

> java.lang.OutOfMemoryError
> --
>
>  Key: CONTINUUM-653
>  URL: http://jira.codehaus.org/browse/CONTINUUM-653
>  Project: Continuum
> Type: Bug

> Versions: 1.0.3
> Reporter: Arnaud Heritier
> Assignee: Brett Porter
> Priority: Blocker
>  Fix For: 1.0.3
>  Attachments: wrapper.log, wrapper.log
>
>
> After some hours, continuum fails, the projects list is empty.

-- 
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: (MAVEN-1490) make plugin installation unique by artifactId

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1490?page=all ]

Arnaud Heritier updated MAVEN-1490:
---

Fix Version: (was: 1.1-beta-3)

> make plugin installation unique by artifactId
> -
>
>  Key: MAVEN-1490
>  URL: http://jira.codehaus.org/browse/MAVEN-1490
>  Project: Maven
> Type: Bug

>   Components: plugin manager
> Versions: 1.0.1
> Reporter: Brett Porter

>
>
> currently, warning when multiple versions of a plugin are installed (based on 
> artifactId).
> Instead:
> if > 1 duplicated in installation, error
> if > 1 duplicated in user directory, error
> if 1 in install, 1 in user - honour user, not install

-- 
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: (MAVEN-1533) Project properties inherited to plugins

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1533?page=all ]

Arnaud Heritier updated MAVEN-1533:
---

Fix Version: (was: 1.1-beta-3)

> Project properties inherited to plugins
> ---
>
>  Key: MAVEN-1533
>  URL: http://jira.codehaus.org/browse/MAVEN-1533
>  Project: Maven
> Type: Bug

>   Components: inheritance
> Versions: 1.0.2
>  Environment: Win XP & Solaris 8
> Maven 1.0.2
> Reporter: Martin Jaeger
> Priority: Critical

>
>
> In my project.properties the 
> maven.jar.override = on 
> is setted and the library override:
> maven.jar.commons-lang = ${basedir}/lib/commons-lang-2.0.jar 
> is setted.
> Now the Artifact Plugin tries to get the commons-lang-2.0.jar from the local 
> plugin libraries and fails.

-- 
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: (MAVEN-410) maven plugins seem to choke on properties containing a "-"?

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-410?page=all ]

Arnaud Heritier updated MAVEN-410:
--

Fix Version: (was: 1.1-beta-3)

> maven plugins seem to choke on properties containing a "-"?
> ---
>
>  Key: MAVEN-410
>  URL: http://jira.codehaus.org/browse/MAVEN-410
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.0-beta-9
>  Environment: RedHat Linux 7.3, JDK 1.3.1
> Reporter: Henning Schmiedehausen

>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0] 
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time:  7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: 
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger 
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time:  9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init files.

-- 
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: (MAVEN-256) does not use the global session

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-256?page=all ]

Arnaud Heritier updated MAVEN-256:
--

Fix Version: (was: 1.1-beta-3)

>  does not use the global session
> 
>
>  Key: MAVEN-256
>  URL: http://jira.codehaus.org/browse/MAVEN-256
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.0-beta-8
> Reporter: Peter Lynch
> Priority: Critical
>  Attachments: 1.0.2.patch, head.patch
>
>
> The problem:
> Basically there needs to be a way to call a goal from inside another goal and
> have the called goal use the current session.
> The result being no new session created and all already attained goals would 
> not
> be called again by the called goal's prereqs attribute or nested  
> tags.
> The only way to create a new session would be to use the  tags or set 
>  if an attribute is decided to 
> be the way to flag session creation.
> Alternatively it was suggested a new tag be added called  which 
> would always create a new session, and  would be reverted to use 
> the current session.
> Here is the thread from the mailing lists describing the problems and 
> soltuions.
> - Original Message - 
> From: "Colin Sampaleanu" <[EMAIL PROTECTED]>
> To: "Turbine Maven Users List" 
> Cc: "Turbine Maven Developers List" 
> Sent: Thursday, January 30, 2003 7:27 AM
> Subject: Re: goals are broken, let's fix it
> > bob mcwhirter wrote:
> > 
> > >On Thu, 30 Jan 2003, Colin Sampaleanu wrote:
> > >
> > >>I think that there is currently a serious problem in maven and a number 
> > >>of plugins, in that 'attainGoal' is being used in various places (goals, 
> > >>preGoals, and postGoals) with the expectation that the goal being named 
> > >>to be attained will be part of the dependency graph of the main build 
> > >>itself, and will be attained only once. However, due to the way the 
> > >>werkz 'attainGoal' tag is implemented, there is no integration into the 
> > >>main maven dependency session, and each invocation of attainGoal with a 
> > >>specific goal will call that goal again including all its dependencies, 
> > >>becoming more of a subroutine call. At best, I would say it's confusing 
> > >>as hell, since the name 'attainGoal' implies something; certainly there 
> > >>is some code which is using the tag with the expectation that it is 
> > >>integrating into the dependency graph, and there is other code which is 
> > >>using it like a subroutine call. I would also suggest there need to be 
> > >>clearly named, different mechanisms, to handle both usage semantics.
> > >>
> > >>
> > >Yah, this is a well-understood problem (at least by me, having written
> > >werkz).
> > >
> > >Though, my non-scientific polling has resulted in me thinking that
> > >most folks are now taking advantage of the fact that 
> > >doesn't participate in the global session.
> > >
> > >ie:
> > >
> > > 
> > > 
> > > 
> > > 
> > >
> > >Where 'clean' wouldn't fire the 2nd time if we shared in the global
> > >session.
> > >
> > >We noodled around with keeping the current syntax and semantics the
> > >same but adding a session="true" attribute for folks needing new
> > >semantics.
> > >
> > >Or, since so many other things have changed lately, retaining backwards
> > >compatibility is less important, and we could certain make 
> > >behave has expected, and rename the current functionality to 
> > >or  or somesuch.
> > >
> > >The biggest use-case we must accomodate is folks wanting to 'clean'
> > >multple times and not have werkz think everything is still attained.
> > >
> > >Though, that could maybe be rememdied with something like:
> > >
> > > 
> > >
> > >
> > > 
> > >
> > >That'd allow us to invalidate the werkz session and allow for rebuilds
> > >without confusing werkz.
> > >
> > >IRC would probably be a glad place to hammer out the details.
> > >
> > (still cross-posting, as I think this has big implications for users as 
> > well as developers...)
> > 
> > How are the IRC sessions typically arranged? i.e. when are you guys 
> > normally on?. My main issue with IRC is that unfortunately it is blocked 
> > for me during the day due to the firewall at work, although in the worst 
> > case I could probably ssh to my home machine and do a text mode client 
> > from there. Evenings wouldn't be a problem.
> > 
> > My suggestion would be to have very clearly named mechanisms (either 
> > separate tags or attributes on the same tag) to attain goals and share 
> > the maven session, to attain goals and not share the maven session, and 
> > some other mechanism (such as calling a custom tag), that is encouraged 
> > as a means of code reuse/macro/subroutine, which some code is currently 
> > using attainGoal for today. I would favour making a maven (not 
> > necessarilly werkz) attainGoal by default share the session, given it's 
> > name, it'd be less confusing, but if people think backwards 
> > comp

[jira] Updated: (MAVEN-1659) Dependency jars are not downloading from remote repository placed in Subversion with http access

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1659?page=all ]

Arnaud Heritier updated MAVEN-1659:
---

Fix Version: (was: 1.1-beta-3)

> Dependency jars are not downloading from remote repository placed in 
> Subversion with http access
> 
>
>  Key: MAVEN-1659
>  URL: http://jira.codehaus.org/browse/MAVEN-1659
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-1
>  Environment: Server: Apache 1.3.x with Subversion 1.1.1
> Client: Linux 2.6/Windows 2000, J2SE 5.0
> Reporter: Roman Krutyakov

>
>
> Dependencies are not downloading from remote repository if it's placed in 
> Subversion with http access (with apache and mod_davsvn)
> In verbose mode maven logs (under linux):
> ---
> Getting failed dependencies: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
> PROTECTED]
> Attempting to download slamd_client-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_client-1.8.1.jar
>  - Status code: 200
> Local file is newer: not downloaded
> Attempting to download slamd_server-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_server-1.8.1.jar
>  - Status code: 200
> Local file is newer: not downloaded
> 
> Artifact '/opt/maven-repository/slamd/jars/slamd_client-1.8.1.jar' not found 
> to add to classpath
> Artifact '/opt/maven-repository/slamd/jars/slamd_server-1.8.1.jar' not found 
> to add to classpath
> ---
> in local repository appropriate paths are created, but jar files are missing
> this was checked against repository server with basic auth and without 
> authentication - result is the same
> affected version 1.1-beta-1, 1.0.x works well

-- 
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: (MAVEN-1676) Problem generation with antlr

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1676?page=all ]

Arnaud Heritier updated MAVEN-1676:
---

Fix Version: (was: 1.1-beta-3)

> Problem generation with antlr
> -
>
>  Key: MAVEN-1676
>  URL: http://jira.codehaus.org/browse/MAVEN-1676
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-1
>  Environment: Linux
> Reporter: Emmanuel Lécharny

>
>
> The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version 
> handles it correctly. 
> Here is a sample of this error :
> on apacheds, in shared/ldap/common, 
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer 
> present
> Cache invalidated due to out of date plugins
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> clean:clean:
> xdoc:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time   : 3 seconds
> Finished at  : Friday, August 26, 2005 12:24:38 PM CEST
> $ maven java:compile
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile:
> [copy] Copying 1 file to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common
> antlr:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr
> antlr:generate:
> ANTLR Parser Generator   Version 2.7.2   1989-2003 jGuru.com
> warning: public lexical rule SIMPLE_STRING is optional (can match "nothing")
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [delete] Deleting: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [echo] Compiling to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] Compiling 200 source files to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31:
>  cannot find symbol
> [javac] symbol  : class AntlrFilterParser
> [javac] location: class org.apache.ldap.common.filter.FilterParserImpl
> [javac] private AntlrFilterParser parser;
> [javac] ^
> (... many errors)
> [javac] 16 errors
> BUILD FAILED
> File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly
> Element... ant:javac
> Line.. 63
> Column 48
> Compile failed; see the compiler error output for details.
> Total time   : 4 seconds
> Finished at  : Friday, August 26, 2005 12:24:50 PM CEST
> The very same operation using maven-1.0.2 :
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> clean:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time: 1 seconds
> Finished at: Fri Aug 26 12:24:11 CEST 2005
> $maven java:compile
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile:
> [copy] Copying 1 file to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common
> antlr

[jira] Updated: (MAVEN-1521) loading properties file via Ant property task does not work from maven.xml

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1521?page=all ]

Arnaud Heritier updated MAVEN-1521:
---

Fix Version: (was: 1.1-beta-3)

> loading properties file via Ant property task does not work from maven.xml
> --
>
>  Key: MAVEN-1521
>  URL: http://jira.codehaus.org/browse/MAVEN-1521
>  Project: Maven
> Type: Bug

>   Components: jelly/ant integration
> Versions: 1.0.1
>  Environment: n/a
> Reporter: Ian Springer

>
>
> If I have the following line in maven.xml, either within a goal or outside of 
> any goals:
>   
> where my.properties exists and is a valid Java props file, any properties 
> that are in my.properties end up with a value of "0" (yes, simply the zero 
> character) in Maven.

-- 
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: (MAVEN-1696) Wrong basedir property in producess unusefull error message

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1696?page=all ]

Arnaud Heritier updated MAVEN-1696:
---

Fix Version: (was: 1.1-beta-3)

> Wrong basedir property in  producess unusefull error message
> 
>
>  Key: MAVEN-1696
>  URL: http://jira.codehaus.org/browse/MAVEN-1696
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-1
>  Environment: Linux, Maven 1.0.2/Maven 1.1-beta-1
> Reporter: Mykola Nikishov
>  Attachments: extendbug.tar.gz, wrongextend.patch
>
>
> In one of my projects I've misspelt basedir property in such way:
> --- ok/project.xml  2005-08-05 00:55:49.0 +0300
> +++ bug/project.xml 2005-08-05 00:55:28.0 +0300
> @@ -1,6 +1,6 @@
>  
>  
> -${basedir}/../project.xml
> +{$basedir}/../project.xml
>  3
> and Maven reported about:
> File.. /home/mn/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly
> Element... maven:reactor
> Line.. 64
> Column 9
> Unknown error reading project
> for Maven 1.1-beta-1 and
> File.. /home/mn/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly
> Element... maven:reactor
> Line.. 64
> Column 9
> Parent POM is equal to the current POM
> for Maven 1.0.2

-- 
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: (MAVEN-1700) Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property for Java under Mac OS X

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1700?page=all ]

Arnaud Heritier updated MAVEN-1700:
---

Fix Version: (was: 1.1-beta-3)

> Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property 
> for Java under Mac OS X
> -
>
>  Key: MAVEN-1700
>  URL: http://jira.codehaus.org/browse/MAVEN-1700
>  Project: Maven
> Type: Bug

>   Components: cli
> Versions: 1.1-beta-1
>  Environment: Mac OS X 10.4 - Java 1.4.2 - Should apply to any Mac OS X and 
> Java
> Reporter: Ludovic Maître
> Priority: Minor

>
>
> I had to add the following to the Maven 1.1b1 startup script for it to run 
> properly under Mac OS X :
> if $darwin; then
>   MAVEN_OPTS="$MAVEN_OPTS 
> -Djava.endorsed.dirs=/System/Library/Java/Extensions"
> fi
> Because the extension are placed in this folder under Mac OS X Java 
> installation. However this as perhaps been already fixed. (also one should 
> have the Xerces libs in the above mentionned folder for running Maven 1.1b1 
> with jdk 1.4.2 [the classes of Xerces are included in Java 1.5 AFAIK]).

-- 
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: (MAVEN-1466) install_repo.bat can require inconsistent quoting on the command line

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1466?page=all ]

Arnaud Heritier updated MAVEN-1466:
---

Fix Version: (was: 1.1-beta-3)

> install_repo.bat can require inconsistent quoting on the command line
> -
>
>  Key: MAVEN-1466
>  URL: http://jira.codehaus.org/browse/MAVEN-1466
>  Project: Maven
> Type: Bug

>   Components: documentation
> Versions: 1.0
>  Environment: Windows XP Professional SP 1
> Reporter: Albert Davidson Chou
> Priority: Minor

>
> Original Estimate: 1 hour
> Remaining: 1 hour
>
> The install_repo.bat script in version 1.0 builds up its argument word by 
> word and then puts double quotes around the value thereby built up wherever 
> it is used.  However, this implementation makes using the script kind of 
> weird.  On Windows I have to quote the command anyway if it contains spaces, 
> e.g.,
> "%MAVEN_HOME%\bin\install_repo.bat"
> and I would expect to have to quote its argument for similar reasons.  But as 
> it stands now, install_repo.bat _requires_ the following quoting syntax if 
> both MAVEN_HOME and HOME (or HOMEPATH) contain spaces:
> "%MAVEN_HOME%\bin\install_repo.bat" %HOME%\.maven\repository
> Note the inconsistency in quoting.
> The Windows batch language doesn't treat quotes the way most shells do; the 
> quotes are literally part of the string rather than just a meta-character 
> that signifies that contained whitespace is literal rather than a command or 
> argument separator.  The syntax %~1 can be used to produce a non-quoted and 
> fully-path-expanced version of whatever argument %1 was, at least in more 
> recent versions of Windows (2000, XP, 2003).  No guarantees that this feature 
> is present in Windows 9x

-- 
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: (MAVEN-1440) Clearing maven.repo.remote results in incorrect reporting of unsatisfied dependencies

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1440?page=all ]

Arnaud Heritier updated MAVEN-1440:
---

Fix Version: (was: 1.1-beta-3)

> Clearing maven.repo.remote results in incorrect reporting of unsatisfied 
> dependencies
> -
>
>  Key: MAVEN-1440
>  URL: http://jira.codehaus.org/browse/MAVEN-1440
>  Project: Maven
> Type: Bug

> Versions: 1.0
>  Environment: Solaris
> Reporter: Cameron Horn
> Priority: Minor

>
>
> Running "maven -Dmaven.repo.remote= -Dmaven.mode.online=false"
> 
> The use of the remote repository has been disabled. (x10)
> BUILD FAILED
> File.. 
> /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> The build cannot continue because of the following unsatisfied dependency:
> kernel-core-SNAPSHOT.jar
> 
> Which is misleading. kernel-core-SNAPSHOT.jar failed to build because it was 
> missing dependencies.  Running "maven -o -Dmaven.repo.remote= 
> multiproject:install-snapshot" shows the correct dependencies:
> 
> The use of the remote repository has been disabled. (x10)
> You are working offline so the build will continue, but 
> kernel-core-SNAPSHOT.jar may be out of date!
> You are working offline so the build will continue, but 
> kernel-container-SNAPSHOT.jar may be out of date!
> BUILD FAILED
> File.. 
> /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> The build cannot continue because of the following unsatisfied dependencies:
> commons-beanutils-1.6.1.jar
> commons-digester-1.4.1.jar
> 

-- 
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: (MAVEN-1641) NPE thrown on RMIC call

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1641?page=all ]

Arnaud Heritier updated MAVEN-1641:
---

Fix Version: (was: 1.1-beta-3)

> NPE thrown on RMIC call
> ---
>
>  Key: MAVEN-1641
>  URL: http://jira.codehaus.org/browse/MAVEN-1641
>  Project: Maven
> Type: Bug

> Versions: 1.0.2
>  Environment: Windows XP SP2, Java SDK 1.4.2_06, Maven 1.0.2
> Reporter: Ricardo Gladwell
>  Attachments: stacktrace.txt, testcase.zip
>
>
> NullPointerException thrown when calling the RMIC ant task from within Maven. 
> To see run:
> > maven java:compile
> From within the attached test case project.

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

[jira] Updated: (MAVEN-1688) The ${pom.versions} List behaves differently when running plugins under maven 1.1 and maven 1.0

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1688?page=all ]

Arnaud Heritier updated MAVEN-1688:
---

Fix Version: (was: 1.1-beta-3)

> The ${pom.versions} List behaves differently when running plugins under maven 
> 1.1 and maven 1.0
> ---
>
>  Key: MAVEN-1688
>  URL: http://jira.codehaus.org/browse/MAVEN-1688
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.1-beta-2
> Reporter: Henning Schmiedehausen

>
>
> Consider the following POM snipped:
> 
> 
>   2.1
>   TURBINE_2_1
> 
> 
>   2.2
>   TURBINE_2_2_0
> 
> 
>   2.3-rc1
>   TURBINE_2_3_RC1
> 
> 
>   2.3-rc2
>   TURBINE_2_3_RC2
> 
> 
>   2.3
>   TURBINE_2_3
> 
> 
>   2.3.1-RC1
>   TURBINE_2_3_1_RC1
> 
> 
>   2.3.1-RC2
>   TURBINE_2_3_1_RC2
> 
> 
>   2.3.1
>   TURBINE_2_3_1
>   2.3.1
> 
> 
>   2.3.2-RC1
>   TURBINE_2_3_2_RC1
> 
>   
> echoing ${pom.versions} under the 1.0.2 maven release issues the following 
> output:
> [echo] [2.1, 2.2, 2.3-rc1, 2.3-rc2, 2.3, 2.3.1-RC1, 2.3.1-RC2, 2.3.1, 
> 2.3.2-RC1]
> doing the same thing under the 1.1-beta 2 core results in
> [echo] [null, null, null, null, null, null, null, 2.3.1, null]
> It seems that 1.0 uses the name as key and 1.1 uses the id. This causes e.g. 
> the clirr plugin to fail if a project
> defines names for a version entry but no id.
> If it is necessary that a version entry contains name and/or id, it should be 
> enforced by the maven core and bad
> entries should be reported.

-- 
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: (MAVEN-1666) Non-informative exception when running 1.1-beta-1 on pom/maven.xml working in 1.0.2

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1666?page=all ]

Arnaud Heritier updated MAVEN-1666:
---

Fix Version: (was: 1.1-beta-3)

> Non-informative exception when running 1.1-beta-1 on pom/maven.xml working in 
> 1.0.2
> ---
>
>  Key: MAVEN-1666
>  URL: http://jira.codehaus.org/browse/MAVEN-1666
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-1
>  Environment: D:\jhb_bugfix_view\sw\java>maven --info all_jar
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> - Environment
>   java.version=1.4.2_06
>   file.encoding=Cp1252
>   java.ext.dirs=c:\j2sdk1.4.2_06\jre\lib\ext
>   java.class.path=d:\tools\maven-1.1-beta-1\lib\forehead-1.0-beta-5.jar
>   os.name=Windows 2000
>   java.vendor=Sun Microsystems Inc.
>   
> sun.boot.class.path=c:\j2sdk1.4.2_06\jre\lib\rt.jar;c:\j2sdk1.4.2_06\jre\lib\i18n.jar;c:\j2sdk1.4.2_06\jre\lib\sunrsasign.jar;c:\j2sdk1.4.2_06\jre\lib\jsse.jar;c:\j2sdk1.4.2_06\jre\lib\jce.jar;c:\j2
> sdk1.4.2_06\jre\lib\charsets.jar;c:\j2sdk1.4.2_06\jre\classes
>   java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
> -
> Installed plugins :
>   maven-abbot-plugin-1.1
>   maven-announcement-plugin-1.3
>   maven-ant-plugin-1.9
>   maven-antlr-plugin-1.2.1
>   maven-artifact-plugin-1.5.2
>   maven-aspectj-plugin-3.2
>   maven-castor-plugin-1.2
>   maven-changelog-plugin-1.8.2
>   maven-changes-plugin-1.5.1
>   maven-checkstyle-plugin-2.5
>   maven-clean-plugin-1.3
>   maven-clover-plugin-1.9.1
>   maven-console-plugin-1.1
>   maven-cruisecontrol-plugin-1.7
>   maven-dashboard-plugin-1.8
>   maven-developer-activity-plugin-1.5.1
>   maven-dist-plugin-1.6.1
>   maven-ear-plugin-1.7
>   maven-eclipse-plugin-1.9
>   maven-ejb-plugin-1.6
>   maven-faq-plugin-1.4
>   maven-file-activity-plugin-1.5.1
>   maven-genapp-plugin-2.2
>   maven-gump-plugin-2.0.1
>   maven-hibernate-plugin-1.3
>   maven-html2xdoc-plugin-1.3.1
>   maven-idea-plugin-1.6
>   maven-j2ee-plugin-1.5.1
>   maven-jalopy-plugin-1.3.1
>   maven-jar-plugin-1.7
>   maven-java-plugin-1.5
>   maven-javacc-plugin-1.1
>   maven-javadoc-plugin-1.7
>   maven-jboss-plugin-1.5
>   maven-jbuilder-plugin-1.5
>   maven-jcoverage-plugin-1.0.9
>   maven-jdepend-plugin-1.5
>   maven-jdiff-plugin-1.4
>   maven-jellydoc-plugin-1.3.1
>   maven-jetty-plugin-1.1
>   maven-jira-plugin-1.1.2
>   maven-jnlp-plugin-1.4.1
>   maven-junit-report-plugin-1.5
>   maven-jxr-plugin-1.4.2
>   maven-license-plugin-1.2
>   maven-linkcheck-plugin-1.3.4
>   maven-multichanges-plugin-1.1
>   maven-multiproject-plugin-1.4.1
>   maven-native-plugin-1.1
>   maven-nsis-plugin-1.1
>   maven-pdf-plugin-2.3
>   maven-plugin-plugin-1.6
>   maven-pmd-plugin-1.6
>   maven-pom-plugin-1.4.1
>   maven-rar-plugin-1.0
>   maven-release-plugin-1.4.1
>   maven-repository-plugin-1.2
>   maven-scm-plugin-1.5
>   maven-simian-plugin-1.4
>   maven-site-plugin-1.6.1
>   maven-tasklist-plugin-2.4
>   maven-test-plugin-1.6.2
>   maven-uberjar-plugin-1.2
>   maven-war-plugin-1.6.1
>   maven-xdoc-plugin-1.9.1
> Home Build properties : {eclipse_location=C:/eclipse, 
> eclipse_dep_project=project, staging_location=d:/stage}
> Reporter: Jan-Helge Bergesen
>  Attachments: maven.xml, project.xml, super_project.xml
>
>
> D:\jhb_bugfix_view\sw\java>maven -e all_jar
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> java.lang.NullPointerException
> at 
> org.codehaus.plexus.util.StringUtils.deleteWhitespace(StringUtils.java:139)
> at 
> org.apache.maven.plugin.PluginScriptParser.startElement(PluginScriptParser.java:143)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
> at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
> at 
> org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:157)
> at 
> org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:177)
> at 
> org.apache.maven.plugin.PluginManager.readMavenXml(PluginManager.java:524)
> at 
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager

[jira] Updated: (MAVEN-1706) maven.src.dir != pom.build.sourceDirectory

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1706?page=all ]

Arnaud Heritier updated MAVEN-1706:
---

Fix Version: (was: 1.1-beta-3)

> maven.src.dir != pom.build.sourceDirectory
> --
>
>  Key: MAVEN-1706
>  URL: http://jira.codehaus.org/browse/MAVEN-1706
>  Project: Maven
> Type: Bug

>   Components: documentation, core
> Versions: 1.0.2
> Reporter: Peter Lynch

>
>
> Maven documentation states on 
> http://maven.apache.org/reference/properties.html
> maven.src.dir  The base directory for source code. DEPRECATED: 
> Currently unused. Instead, use the   element of the POM. 
>  ${basedir}/src
> Problem is that maven.src.dir != pom.build.sourceDirectory in practice.
> default of maven.src.dir property is ${basedir}/src. Most plugins project.xml 
> and their dependent Jelly plugin code expect pom.build.sourceDirectory to 
> point to src/java, ie. where your Java sources are located.
> Try setting sourceDirectory element in your java project's POM to 'src' and 
> watch the various java/jar/junit plugin's croak if you have any other Java 
> source files in any other location than src/java because they all will try to 
> be compiled all at one. Another example: Grep for pom.build.sourceDirectory 
> in your plugin cache and look at all the code that expects it to point to 
> src/java, where you java sources live.
> The solution for existing projects is to ignore the documentation as written 
> and make pom.build.sourceDirectory still point to src/java, then use 
> maven.src.dir when they want the real root source directory. The 
> documentation needs to be replaced on this front. Or replace the code in 10+ 
> standard plugins to not assume sourceDirectory element is pointing to Java 
> home.

-- 
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: (MAVEN-1673) does not indicate failure

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1673?page=all ]

Arnaud Heritier updated MAVEN-1673:
---

Fix Version: (was: 1.1-beta-3)

>  does not indicate failure
> ---
>
>  Key: MAVEN-1673
>  URL: http://jira.codehaus.org/browse/MAVEN-1673
>  Project: Maven
> Type: Bug

>   Components: jelly/ant integration
> Versions: 1.1-beta-1, 1.0.2
>  Environment: OS X 10.4.2, JRE 1.4.2_07-215
> Reporter: Scott Lamb
> Priority: Minor
>  Attachments: element-without-taskdef.tar.gz
>
>
> maven does not error out when it encounters an ant element with no taskdef. 
> This is horribly confusing. ant produces a nice error message when run 
> directly.
> This is likely to happen frequently on maven 1.1, since it no longer includes 
> many optional taskdefs.
> In my tests, maven 1.0.2 completely ignores the unknown element. maven 
> 1.1-beta-1 prints out the literal element but still does nothing.
> To reproduce with the attached testcase (not jUnit; sorry):
> $ tar xvzf element-without-taskdef.tar.gz
> $ cd element-without-taskdef
> $ maven shouldfail
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> build:start:
> shouldfail:
> BUILD SUCCESSFUL
> Total time   : 1 seconds 
> Finished at  : Wednesday, August 24, 2005 4:01:53 PM PDT
> vs ant:
> $ ant shouldfail
> Buildfile: build.xml
> shouldfail:
> BUILD FAILED
> /private/tmp/element-without-taskdef/build.xml:8: Could not create task or 
> type of type: element-without-taskdef.
> ...

-- 
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: (MAVEN-1656) Doco that explains the protocols required to allow maven.xml or any plugin.jelly to inject values into or retrieve values from another plugin

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1656?page=all ]

Arnaud Heritier updated MAVEN-1656:
---

Fix Version: (was: 1.1-beta-3)

> Doco that explains the protocols required to allow maven.xml or any 
> plugin.jelly to inject values into or retrieve values from another plugin
> -
>
>  Key: MAVEN-1656
>  URL: http://jira.codehaus.org/browse/MAVEN-1656
>  Project: Maven
> Type: Bug

>   Components: documentation
> Versions: 1.1-beta-1
>  Environment: All
> Reporter: Andy Glick

>
>
> Brett recently posted a suggestion to someone who asked how to access the 
> contents of "plugin a" from the context of "plugin b" or from maven.xml. 
> Brett stated that "plugin a" would have to be initialized before it could be 
> accessed, and that from what I could understand he recommended 1 or 2 ways to 
> do that:
> 1) reference the artifact plugin's namespace in the project tag 
> 2) specify  value="some.value"/>  (I think that this is the proper syntax, but I'm not 
> sure :-).
> Thierry Lach, who asked the question this time around, reported that using 
> the artifact namespace didn't work in his instance, but that setting the 
> scope to parent did. I'm hoping that we can put together a fairly 
> comprehensive explanation about what is going on here, and if that means 
> explaining why the project gave up on Jelly and switched to M2, then so be it.
> See http://news.gmane.org/gmane.comp.jakarta.turbine.maven.user for the 
> postings
> Given that during the last couple of months Vincent Massol recommended that 
> people use the now deprecated  mechanism on the 
> mavenbook.org site (see Tip #2), I should think that there ought to be a 
> priority on documenting this issue in an obvious place, probably the FAQ, but 
> also on the Maven Jelly tags get and set entries. 
> If this is actually explicitly documented somewhere, I'm sorry to have wasted 
> anyone's time. I have seen several plugins that have successfully used the 
> artifact namespace tag, so there must be some way that people have learned 
> this. I simply wish that I knew how they had done so. ;-) 
> I'm willing to write the doco if someone would explain the details.

-- 
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: (MAVEN-1546) add maven.reactor.basedir property when the reactor starts to locate the project root

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1546?page=all ]

Arnaud Heritier updated MAVEN-1546:
---

Fix Version: (was: 1.1-beta-3)

> add maven.reactor.basedir property when the reactor starts to locate the 
> project root
> -
>
>  Key: MAVEN-1546
>  URL: http://jira.codehaus.org/browse/MAVEN-1546
>  Project: Maven
> Type: Bug

> Reporter: Brett Porter

>
>
> add maven.reactor.basedir property when the reactor starts to locate the 
> project root

-- 
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: (MAVEN-1492) use whole id, not artifact ID, for identifying plugins

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1492?page=all ]

Arnaud Heritier updated MAVEN-1492:
---

Fix Version: (was: 1.1-beta-3)

> use whole id, not artifact ID, for identifying plugins
> --
>
>  Key: MAVEN-1492
>  URL: http://jira.codehaus.org/browse/MAVEN-1492
>  Project: Maven
> Type: Bug

>   Components: plugin manager
> Versions: 1.0.1
> Reporter: Brett Porter

>
>
> currently we map artifactId's to plugins. This is not guaranteed to be 
> unique, so switch to mapping the groupId:artifactId combo.

-- 
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: (MAVEN-1080) Maven download corrupted jar file into repository

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1080?page=all ]

Arnaud Heritier updated MAVEN-1080:
---

Fix Version: (was: 1.1-beta-3)

> Maven download corrupted jar file into repository
> -
>
>  Key: MAVEN-1080
>  URL: http://jira.codehaus.org/browse/MAVEN-1080
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.0-rc1
> Reporter: Mesut Celik

>
>
> When you break up downloading the jar files into repository while executing 
> some goal, Maven puts corrupted jar file into repository. 
> Solution is to copy the same jar to the correct folder in the repository 
> folder structure.

-- 
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: (MAVEN-1716) Download problem from internal repository

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1716?page=all ]

Arnaud Heritier updated MAVEN-1716:
---

Fix Version: (was: 1.1-beta-3)

> Download problem from internal repository
> -
>
>  Key: MAVEN-1716
>  URL: http://jira.codehaus.org/browse/MAVEN-1716
>  Project: Maven
> Type: Bug

>  Environment: Windows 2000 JDK 1.4.2
> Reporter: Emil A. Lefkof III
>  Attachments: screenshot-1.jpg
>
>
> I want to have all my custom plugins in the internal company repository.  
> However the plugin:download goal has a bug where it is not finding the 
> plugins correctly.  Here is what I have discovered.
> maven.repo.remote=file:///development/dev-share/maven   -this fails to find 
> the plugins but works fine for finding library dependencies.
> maven.repo.remote=file://x:/maven  - 2 slashes this fails to find plugins but 
> works find for finding libraries
> maven.repo.remote=file:///x:/maven - noticed the 3 slashes, this works for 
> finding the plugins but now all libraries fail to dowload because of invalid 
> syntax.

-- 
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: (MAVEN-1704) artifactId is used as groupId when the latest is not defined

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1704?page=all ]

Arnaud Heritier updated MAVEN-1704:
---

Fix Version: (was: 1.1-beta-3)

> artifactId is used as groupId when the latest is not defined
> 
>
>  Key: MAVEN-1704
>  URL: http://jira.codehaus.org/browse/MAVEN-1704
>  Project: Maven
> Type: Bug

>   Components: inheritance
> Versions: 1.1-beta-2
> Reporter: Carlos Sanchez

>
>
> artifactId is used as groupId when the latest is not defined (using extends 
> at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven 
> should complain.
> Which is really a problem is that if pom a extends pom b, and no groupId is 
> defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, 
> while in 1.1 artifactId of b is the chosen one.

-- 
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: (MAVEN-1648) Maven 1.1-beta-1 no longer downloads MD5 sums to local repository

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1648?page=all ]

Arnaud Heritier updated MAVEN-1648:
---

Fix Version: (was: 1.1-beta-3)

> Maven 1.1-beta-1 no longer downloads MD5 sums to local repository
> -
>
>  Key: MAVEN-1648
>  URL: http://jira.codehaus.org/browse/MAVEN-1648
>  Project: Maven
> Type: Bug

> Versions: 1.1-beta-1
>  Environment: Gentoo Linux JDK 1.5, downloaded Maven from website.
> Reporter: Matt Ray

>
>
> With Maven 1.02, the .md5 sums are stored in the local repository with the 
> files.  They are no longer there for maven 1.1-beta-1.  If this behavior is 
> intentional, maven needs to check md5 sums for itself when it downloads a 
> 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] Updated: (MAVEN-1435) Plugin classpath are not overwriting project classpath.

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1435?page=all ]

Arnaud Heritier updated MAVEN-1435:
---

Fix Version: (was: 1.1-beta-3)

> Plugin classpath are not overwriting project classpath.
> ---
>
>  Key: MAVEN-1435
>  URL: http://jira.codehaus.org/browse/MAVEN-1435
>  Project: Maven
> Type: Bug

> Reporter: Jose Peleteiro
> Priority: Critical
>  Attachments: example.zip
>
>
> My project uses picocontainer 1.1 and andromda maven plugin uses 
> picocontainer 1.0. In plugin´s project.xml there´s a pico 1.0 depedencie 
> declaration, but as in my project there´s a pico 1.1 declaration so I cant 
> run it.
> Okay, I´ve looked plugin code and I found:
>  
> that uses pico 1.0 and I tried to find a way to set it´s context classpath, 
> but I could not find it (Someway like ant).
> I´ve looked at project.xml and wrote 
> "root" at pico 1.0 
> depedency. 
> It goes perfectly... well, not so perfectly because if I run another plugin 
> that needs pico 1.1 (like xdoclet 2.0 will soon) I got problem because when I 
> finish to run a plugin classpath configuration does not come back to normal.
> In my opinion if I write plugins depedencies should overwrite project 
> depedencies when a plugin is running and just when its running.
> I wrote a example, there is two jars on this zip, one of them is my andromda 
> cartridge and the andromda plugin with classloader fixed.
> test1 - Just run andromda plugin
> test2 - Run andromda plugin and other code that uses pico 1.1.
> test3 - Run a code that uses pico 1.1 and andromda plugin.
> Thank´s

-- 
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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1677?page=all ]

Arnaud Heritier updated MAVEN-1677:
---

Fix Version: (was: 1.1-beta-3)

> "No directory specified for fileset" when debugging for 
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
>  Key: MAVEN-1677
>  URL: http://jira.codehaus.org/browse/MAVEN-1677
>  Project: Maven
> Type: Bug

>   Components: jelly/ant integration
> Versions: 1.1-beta-1
>  Environment: OS X 10.4.2, java version "1.5.0_02"
> Reporter: Scott Lamb
> Priority: Minor

>
>
> I've been trying to debug problems by specifying an alternate 
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for 
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this 
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can 
> attach full exception info, the project I used, and the log4j config file I 
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is 
> not too helpful, though.

-- 
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: (MAVEN-1482) some genuine errors result in "fatal" errors

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1482?page=all ]

Arnaud Heritier updated MAVEN-1482:
---

Fix Version: (was: 1.1-beta-3)

> some genuine errors result in "fatal" errors
> 
>
>  Key: MAVEN-1482
>  URL: http://jira.codehaus.org/browse/MAVEN-1482
>  Project: Maven
> Type: Bug

>   Components: core
> Reporter: Brett Porter

>
>
> for example: extend a POM that doesn't exist.
> Need to gracefully catch such exceptions and handle differently.

-- 
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: (MAVEN-1576) expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1576?page=all ]

Arnaud Heritier updated MAVEN-1576:
---

Fix Version: (was: 1.1-beta-3)

> expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader
> -
>
>  Key: MAVEN-1576
>  URL: http://jira.codehaus.org/browse/MAVEN-1576
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.0.2
>  Environment: Linux
> Reporter: Willie Milnor

>
>
> I am trying to get around using com.werken.forehead.Forehead to run Maven, 
> and instead use my own class that extends org.apache.maven.cli.App.  However, 
> I get the following error no matter what I try:
> java.lang.ClassCastException: sun.misc.Launcher$AppClassLoader
> at 
> org.apache.maven.plugin.PluginManager.processDependencies(PluginManager.java:437)
> at 
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:642)
> at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
> at MyApp.myDoMain(MyApp.java:80)
> at MyApp.main(MyApp.java:575)
> I know that this is caused by the following line:
> ForeheadClassLoader projectClassLoader = 
> (ForeheadClassLoader)project.getContext().getClassLoader();
> I assume that when com.werken.forehead.Forehead is called, it somehow sets 
> the class loader (for the context) to an instance of ForeheadClassLoader; but 
> by calling my class directly, the context uses an instance of 
> sun.misc.Launcher$AppClassLoader.
> I am able to run my own class calling com.werken.forehead.Forehead first (I 
> edited the forehead.conf file), and it works as it should.  I tried setting 
> the class loader for the context using a ForeheadClassLoader, but that loader 
> is changed somewhere along the way to processing the dependencies.
> Is there a way around this problem?  I am using maven 1.0.2...is there a 
> newer beta version of maven that expects simply a ClassLoader rather than a 
> ForeheadClassLoader?

-- 
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: (MAVEN-1679) maven 1.1-beta-1 chokes on XML Entities for non-US characters in project.xml

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1679?page=all ]

Arnaud Heritier updated MAVEN-1679:
---

Fix Version: (was: 1.1-beta-3)

> maven 1.1-beta-1 chokes on XML Entities for non-US characters in project.xml
> 
>
>  Key: MAVEN-1679
>  URL: http://jira.codehaus.org/browse/MAVEN-1679
>  Project: Maven
> Type: Bug

>   Components: model
> Versions: 1.1-beta-1
> Reporter: Eirik Maus

>
>
> To make project.xml readable across operating systems and parsers (even when 
> turned into html by the site plugin), we have used entities for non-US 
> characters in project xml.   The XML parser used in maven 1.1 chokes on the 
> use of these entities (but not on the entity definition). This is very 
> unfortunate, as using entities for abbreviations and symbols is perfectly 
> legal Xml. 
> Example: won't work with 1.1:
> 
>  
> 
> ]>
> 
> 3
>  ...
> 
> 
> Marit Finne J&OSlash;rgensen
> mfj
> 
> 
> 
> 
> Example: fix for 1.1, with cross-system compatibility issues. 
> 
>  
> 
> ]>
> 
> 3
>  ...
> 
> 
> Marit Finne Jørgensen
> mfj
> 
> 
> 
> 
> The XML parser chokes on the Usage of the XML Entity, inside 'Jørgensen', not 
> on the definition.  

-- 
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: (MAVEN-1591) 'maven.repo.local' not honored by all

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1591?page=all ]

Arnaud Heritier updated MAVEN-1591:
---

Fix Version: (was: 1.1-beta-3)

> 'maven.repo.local' not honored by all
> -
>
>  Key: MAVEN-1591
>  URL: http://jira.codehaus.org/browse/MAVEN-1591
>  Project: Maven
> Type: Bug

> Versions: 1.0.2
>  Environment: Windows XP SP2; Java 1.5.0_02; Maven 1.0.2
> Reporter: Jamie Bisotti

>
>
> 1. In project.properties file, set maven.repo.local=C:\blah\repository
> 2. Delete, completely, %HOMEDRIVE%%HOMEPATH%\.maven\repository, if it already 
> exists
> 3. Run maven java:compile
> 4. I see where it downloads my project's dependencies, and places them in the 
> appropriate local repository location (see maven.repo.local above)
> 5. However, it also downloads commons-lang, antlr & commons-jelly-tags-antlr, 
> which I'm assuming Maven is using under the covers.  That wouldn't be a 
> problem, except they are still being put in 
> %HOMEDRIVE%%HOMEPATH%\.maven\repository.  Am I missing some other property, 
> or is this a bug?

-- 
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: (MAVEN-1629) Ugly error message when JDK 1.3 is set for JAVA_HOME

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1629?page=all ]

Arnaud Heritier updated MAVEN-1629:
---

Fix Version: (was: 1.1-beta-3)

> Ugly error message when JDK 1.3 is set for JAVA_HOME
> 
>
>  Key: MAVEN-1629
>  URL: http://jira.codehaus.org/browse/MAVEN-1629
>  Project: Maven
> Type: Bug

>   Components: cli
> Versions: 1.1-beta-1
>  Environment: JAVA_HOME set to a 1.3 JDK
> Reporter: dion gillard
> Priority: Minor

>
>
> Is there some nicer message that can be produced than this?
> C:\source\wsad\workspace\Deployment>maven 
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> org/apache/maven/cli/App (Unsupported major.minor version 48.0)
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:488)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:243)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:51)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:190)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:190)
> at com.werken.forehead.Forehead.setupEntry(Forehead.java:298)
> at com.werken.forehead.Forehead.config(Forehead.java:256)
> at com.werken.forehead.Forehead.config(Forehead.java:131)
> at com.werken.forehead.Forehead.main(Forehead.java:579)

-- 
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: (MAVEN-1660) DependencyVerifier class doesn't resolve an snapshot artifact after attaining a first goal.

[Arnaud Heritier (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1660?page=all ]

Arnaud Heritier updated MAVEN-1660:
---

Fix Version: (was: 1.1-beta-3)

> DependencyVerifier class doesn't resolve an snapshot artifact after attaining 
> a first goal.
> ---
>
>  Key: MAVEN-1660
>  URL: http://jira.codehaus.org/browse/MAVEN-1660
>  Project: Maven
> Type: Bug

>   Components: core
> Versions: 1.1-beta-1
> Reporter: Pascal Larin
> Priority: Minor

>
>
> Since revision 179556 of 
> src/java/org/apache/maven/verifier/DependencyVerifier.java, the 
> satisfyDependencies() method check if an artifact has already been resolved. 
> It changes the behavior from version 1.0.
> For example, if you call maven with goals multiproject:clean and 
> multiproject:deploy with artifact versions set to snaphot, maven doesn't 
> resolve the dependencies for the multiproject:deploy because it has been 
> already done for the multiproject:clean.
> I know that a multiproject:clean should not resolve the project dependencies 
> but it can probably cause problems in other cases. 

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