date:20080606

[jira] Commented: (ARCHETYPE-181) Missing class org/apache/commons/lang/StringUtils

2008-06-06 Thread Gabriel Lincourt (JIRA)


[ 
http://jira.codehaus.org/browse/ARCHETYPE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137608#action_137608
 ] 

Gabriel Lincourt commented on ARCHETYPE-181:


Raphaël, thank you for your help!
Yes, it is indirectly an Artifactory "issue". (Without any repository proxy, 
everything works perfectly for me as well :-)

Artifactory is working as designed, but the Velocity 1.5 POM is faulty. Problem 
described here:
http://www.nabble.com/problem-with-velocity:velocity:1.5-td15005415.html


> Missing class org/apache/commons/lang/StringUtils
> -
>
> Key: ARCHETYPE-181
> URL: http://jira.codehaus.org/browse/ARCHETYPE-181
> Project: Maven Archetype
>  Issue Type: Bug
>Affects Versions: 2.0-alpha-3
> Environment: mvn 2.0.9
> java 1.6_06
>Reporter: Andreas Höhmann
> Attachments: 2008-06-05-trace.txt, mvn-debug.txt
>
>
> mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes 
> -DgroupId=com.mycompany.app -DartifactId=my-app
>  
> throws ...
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/lang/StringUtils
> org.apache.commons.lang.StringUtils
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
> at 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(R
> esourceManagerImpl.java:165)
> at 
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager
> (RuntimeInstance.java:594)
> Any ideas?

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

[jira] Issue Comment Edited: (ARCHETYPE-181) Missing class org/apache/commons/lang/StringUtils

2008-06-06 Thread Gabriel Lincourt (JIRA)


[ 
http://jira.codehaus.org/browse/ARCHETYPE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137608#action_137608
 ] 

a101ymr edited comment on ARCHETYPE-181 at 6/6/08 3:24 AM:


Raphaël, thank you for your help!
Turns out, it is infact indirectly an "issue" with Artifactory. (Without any 
repository proxy, everything works perfectly for me as well :-)

Artifactory is working as designed, but the Velocity 1.5 POM is faulty. Problem 
described here:
http://www.nabble.com/problem-with-velocity:velocity:1.5-td15005415.html


  was (Author: a101ymr):
Raphaël, thank you for your help!
Yes, it is indirectly an Artifactory "issue". (Without any repository proxy, 
everything works perfectly for me as well :-)

Artifactory is working as designed, but the Velocity 1.5 POM is faulty. Problem 
described here:
http://www.nabble.com/problem-with-velocity:velocity:1.5-td15005415.html

  
> Missing class org/apache/commons/lang/StringUtils
> -
>
> Key: ARCHETYPE-181
> URL: http://jira.codehaus.org/browse/ARCHETYPE-181
> Project: Maven Archetype
>  Issue Type: Bug
>Affects Versions: 2.0-alpha-3
> Environment: mvn 2.0.9
> java 1.6_06
>Reporter: Andreas Höhmann
> Attachments: 2008-06-05-trace.txt, mvn-debug.txt
>
>
> mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes 
> -DgroupId=com.mycompany.app -DartifactId=my-app
>  
> throws ...
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/lang/StringUtils
> org.apache.commons.lang.StringUtils
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
> at 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(R
> esourceManagerImpl.java:165)
> at 
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager
> (RuntimeInstance.java:594)
> Any ideas?

-- 
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: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg updated MCHECKSTYLE-97:
---

Description: 
I guess this issue is a follow-up to *MCHECKSTYLE-90*.

With version 2.2, I get the following errors running 'checkstyle:checkstyle':

1) commons-beanutils

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org/apache/commons/beanutils/Converter
org.apache.commons.beanutils.Converter
[INFO] 
[INFO] Trace
java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
at 
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
at 
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
at 
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at 
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.beanutils.Converter
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at 
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at 
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at 
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at 
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 22 more

2) antlr

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] antlr/CommonAST
antlr.CommonAST
[INFO] 
[INFO] Trace
java.lang.NoClassDefFoundError: antlr/CommonAST
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at 
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at 
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at 
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoad

[jira] Commented: (MAVENUPLOAD-2093) RabbitMQ Java Client For AMQP

2008-06-06 Thread Ben Hood (JIRA)


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

Ben Hood commented on MAVENUPLOAD-2093:
---

Sorry about that, the firewall was configured wrongly. Can you please try 
again, please? Thx, Ben

> RabbitMQ Java Client For AMQP
> -
>
> Key: MAVENUPLOAD-2093
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2093
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Ben Hood
>
> "com.rabbitmq","[EMAIL 
> PROTECTED]:/home/maven/rabbitmq-java-client/","rsync_ssh","Ben Hood","[EMAIL 
> PROTECTED]"
> I am a developer at LShift who is the company that maintains RabbitMQ 
> (http://www.rabbitmq.com/), which you can see on the site.
> Please note that we do not have any links to the development team on the 
> site, but you can see from whois that our infrastructure manager Stuart 
> Mottram is the domain owner 
> (http://www.whois.net/whois_new.cgi?d=rabbitmq&tld=com).
> I have set up the rsync server with your public key.
> Please let me know if you need any further identification.

-- 
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: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

2008-06-06 Thread Dennis Lundberg (JIRA)


[ 
http://jira.codehaus.org/browse/MCHECKSTYLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137630#action_137630
 ] 

Dennis Lundberg commented on MCHECKSTYLE-97:


You shouldn't use the Checkstyle Plugin as an extension. See this page for 
instructions on how to use it in a multi module build:
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html

> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at 
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.beanutils.Converter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> ... 22 more
> 2) antlr
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] antlr/CommonAST
> antlr.CommonAST
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: antlr/CommonAST
> at java.lang.ClassLoader.defineCl

[jira] Closed: (MJAVADOC-196) Create AggregatorJavadocMojo similar to AggregatorSourceJarMojo

2008-06-06 Thread Vincent Siveton (JIRA)


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

Vincent Siveton closed MJAVADOC-196.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.5

Added two new goals: javadoc:aggregate and javadoc:test-aggregate in r663917, 
snapshot deployed


> Create AggregatorJavadocMojo similar to AggregatorSourceJarMojo
> ---
>
> Key: MJAVADOC-196
> URL: http://jira.codehaus.org/browse/MJAVADOC-196
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.5
>
>


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

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Vincent Siveton (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137632#action_137632
 ] 

Vincent Siveton commented on MJAVADOC-194:
--

I just fixed MJAVADOC-196 so you will be able to try the 2.5-snap

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

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

[jira] Commented: (MSITE-163) The modules menu is not inherited

2008-06-06 Thread Doron Solomon (JIRA)


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

Doron Solomon commented on MSITE-163:
-

I've been looking into this issue and have come up with a proposed solution ... 
I don't presume to know enough about the way the plugin should work to say it's 
the best solution, so I hope that someone who knows more than I do can comment.

In version 2.0-beta-6, the problem is in the method {{populateModules}} in the 
class {{org.apache.maven.plugins.site.AbstractSiteMojo}}.  In this method two 
booleans are checked - {{keepInheritedRefs}} and {{menu.isInheritAsRef()}}.  If 
either of these is false, then the modules are populated (otherwise, the 
element is left alone to inherit from a parent).  If the project has no 
modules, then the {{}} element is removed by calling method 
{{decorationModel.removeMenuRef}}.  However, this seems to go against the 
purpose of the {{keepInhertiedRefs}} boolean ... if we want to keep inherited 
refs then shouldn't the element remain in the site descriptor, even if there 
are no modules of *this* POM?

I tried surrounding the call to {{decorationModel.removeMenuRef}} with an if 
statement:

{code:title=AbstractSiteMojo.java}
if ( !keepInheritedRefs )
{
decorationModel.removeMenuRef( "modules" );
}
{code}

The problem with this is that it now keeps the {{}} element 
even if no inherit attribute is set, which again (I believe) goes against the 
purpose of this attribute.  So I was able to get the {{}} 
element to remain in the installed/deployed site descriptor ONLY if the element 
contains an inherit attribute by changing the above code to:

{code:title=AbstractSiteMojo.java}
if ( !keepInheritedRefs || menu.getInherit() == null )
{
decorationModel.removeMenuRef( "modules" );
}
{code}

This made me stop and think about the {{keepInheritedRefs}} flag.  I'm not sure 
what its purpose is, but it seems to me that it should be set to true or false 
depending on whether or not {{menu.getInherit()}} is null (i.e. set to false if 
null).  But since I can't be certain of the purpose of {{keepInheritedRefs}} I 
can't say for sure that this is correct.

I believe that all of the above would also apply to the 
{{populateProjectParentMenu}} method that deals with the {{}} element, although I have not tested this.

Finally, it is worth noting that in the trunk the {{populateModules}} method 
has moved to the maven-doxia-tools artifact (groupId org.apache.maven.shared) 
into the class {{org.apache.maven.doxia.tools.DefaultSiteTool}} (the method is 
also defined in the {{SiteTool}} interface).  Perhaps this issue should be 
moved to that project?

> The modules menu is not inherited
> -
>
> Key: MSITE-163
> URL: http://jira.codehaus.org/browse/MSITE-163
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 2.0-beta-4
> Environment: ubuntu linux / debian linux
>Reporter: Andrew Williams
> Fix For: 2.0-beta-8
>
>
> if I have a site.xml in a parent project that contains the line  ref="modules" inherit="top" /> it is not inherited by child projects.
>  works, as does parent.
> This happens when the parent project has no modules of its own.

-- 
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: (MSITE-334) site url inheritance broken

2008-06-06 Thread James Nord (JIRA)

site url inheritance broken
---

 Key: MSITE-334
 URL: http://jira.codehaus.org/browse/MSITE-334
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 2.0-beta-6
 Environment: Windows XP
Reporter: James Nord
 Attachments: build.txt

I have a parent POM that is inherited by multiple projects that specifies site 
wide default settings.

(e.g)
Parent\pom.xml   <--- this is the pom containing the site configuration
Parent\CheckStyleConfig\pom.xml

Part of this is the site deploy 

  

  nds-uk.site
  
file:/scg-nas.uk.nds.com/maven_sites/${project.groupId}/${project.artifactId}/${project.version}

  


running site:deploy on the sub procject results in it using a corrupted version 
of the url.

build output attached.

Notice the corruption of the original file:/ (2 slashes are removed so it 
tries to deploy to local HDD)
Also notice the project name is appended to the end of the URL which doesn't 
match the URL specified

parent (OK) 
file:/scg-nas.uk.nds.com/maven_sites/com.nds.cab.scg/common-parent/1.0.0.0-SNAPSHOT
 - Session: Opened  
child (bad) 
file:///scg-nas.uk.nds.com/maven_sites/com.nds.cab.scg/common-checkstyle/1.0.0.0-SNAPSHOT/common-checkstyle
 - Session: Opened  





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

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Lois Modesitt (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137667#action_137667
 ] 

Lois Modesitt commented on MJAVADOC-194:


I used the javadoc plugin 2.5-SNAPSHOT version:  20080606.132616-15  and the 
problem is still there.  Is your change in this version of the SNAPSHOT?

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

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

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Vincent Siveton (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137668#action_137668
 ] 

Vincent Siveton commented on MJAVADOC-194:
--

yes but you need to call javadoc:aggregate instead of javadoc:javadoc. See svn 
log file http://svn.apache.org/viewvc?rev=663917&view=rev 
You could also generate the documentation from the trunk.

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

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

[jira] Commented: (MSITE-25) mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml

2008-06-06 Thread Emerson Farrugia (JIRA)


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

Emerson Farrugia commented on MSITE-25:
---

Are there any updates on this bug? I'm hitting a brick wall no matter how I try 
to get around it.

> mvn site:deploy and site:stage-deploy ignores server configuration in 
> settings.xml
> --
>
> Key: MSITE-25
> URL: http://jira.codehaus.org/browse/MSITE-25
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Alan Cabrera
>Assignee: Dennis Lundberg
>Priority: Critical
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-25-01.patch, MSITE-25-02.patch, MSITE-25-03.patch, 
> MSITE-25.sample.pom.xml, MSITE-25.settings.xml.fragment.txt, MSITE-25.txt, 
> patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff
>
>
> mvn site:site ignores parts of my settings.xml:
> 
>   livetribe-website
>   664
>   775
>   
> plink
> pscp
>   
>   livetribe
> 
> It uses the username when ssh but does not invoke plink.
> [INFO] [site:deploy]
> Using private key: C:\Documents and Settings\adc\.ssh\id_dsa
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Opened
> Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o 
> "BatchMode yes" [EMAIL PROTECTED] "mkdir -p 
> /home/projects/livetribe/public_html/maven/."
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Disconnecting
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Disconnected

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

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Lois Modesitt (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137671#action_137671
 ] 

Lois Modesitt commented on MJAVADOC-194:


Yes, that fix is great.  I tried the test using javadoc:aggregate and the 
problem is resolved.  Thanks

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

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

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Lois Modesitt (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137678#action_137678
 ] 

Lois Modesitt commented on MJAVADOC-194:


Do you (Vincent) close this issue?  Or am I supposed to do this?

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

-- 
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: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

2008-06-06 Thread Vincent Siveton (JIRA)


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

Vincent Siveton closed MJAVADOC-194.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.5

fixed due to MJAVADOC-196

> javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when 
> aggregating a javadoc for a project
> ---
>
> Key: MJAVADOC-194
> URL: http://jira.codehaus.org/browse/MJAVADOC-194
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Lois Modesitt
>Assignee: Vincent Siveton
> Fix For: 2.5
>
> Attachments: JavaDocTestCase.zip, m209out-UsingJavadoc2.3.txt, 
> m209out-UsingJavadoc2.4.txt, m209out-UsingJavadoc2.5SNAPSHOT.txt
>
>
> The javadoc does not include the "additional source" files defined using the 
> "build-helper:add-source" in each of my subproject pom files when using 
> javadoc plugin 2.4.  The javadoc plugin 2.3 worked correctly.
> I use the "build-helper:add-source" to include additional source directories 
> to the build.  The additional source directories contain my generated source 
> file.  When I run the command using javadoc plugin version 2.4:
> mvn javadoc:javadoc -Daggregate=true
> (or have the aggregate=true specified inside of the pom) the 
> "build-helper:add-source" is not run for each of the subprojects before the 
> aggregated javadoc is created.  Therefore the javadoc does not include the 
> documentation for the files in the additional source directories.
> I also noted that the output for 2.3 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> but the output for the 2.4 javadoc plugin is:
> [INFO]task-segment: [javadoc:javadoc]
> I am not sure if the above output is changed between versions or if the 
> "aggregator-style" is not detectd in the 2.4 version and has an influence in 
> this issue.
> I have attached the log file for running my project using javadoc plugin 
> version 2.3 and 2.4.  Version 2.3 works and version 2.4 does not include the 
> additional source files in the aggregated javadoc.

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

[jira] Commented: (MECLIPSE-126) mark contents of "target" directory as derived

2008-06-06 Thread Richard Bondi (JIRA)


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

Richard Bondi commented on MECLIPSE-126:


+1
Please reopen.

> mark contents of "target" directory as derived
> --
>
> Key: MECLIPSE-126
> URL: http://jira.codehaus.org/browse/MECLIPSE-126
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andreas Schildbach
>Assignee: fabrizio giustina
> Fix For: 2.3
>
>
> Eclipse has the notion of "derived resources", which are normally excluded 
> from many dialogs like the "Open Resource" dialog (Ctrl-Shift-R). Without 
> this marker, all those dialogs would be cluttered with unrelevant files 
> (which can't be edited anyway because they will be overwritten on the next 
> build).
> Unfortunately, unlike Eclipse itself, "mvn eclipse:eclipse" does not mark 
> generated files as derived. A good candidate would be the entire contents of 
> the "target" directory.

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

[jira] Commented: (MSITE-25) mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg commented on MSITE-25:
--

This issue has been fixed in 2.0-beta-7 of the site plugin. That version has 
not yet been released, but you can try out 2.0-beta-7-SNAPSHOT if you really 
need this functionality right away.

> mvn site:deploy and site:stage-deploy ignores server configuration in 
> settings.xml
> --
>
> Key: MSITE-25
> URL: http://jira.codehaus.org/browse/MSITE-25
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Alan Cabrera
>Assignee: Dennis Lundberg
>Priority: Critical
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-25-01.patch, MSITE-25-02.patch, MSITE-25-03.patch, 
> MSITE-25.sample.pom.xml, MSITE-25.settings.xml.fragment.txt, MSITE-25.txt, 
> patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff
>
>
> mvn site:site ignores parts of my settings.xml:
> 
>   livetribe-website
>   664
>   775
>   
> plink
> pscp
>   
>   livetribe
> 
> It uses the username when ssh but does not invoke plink.
> [INFO] [site:deploy]
> Using private key: C:\Documents and Settings\adc\.ssh\id_dsa
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Opened
> Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o 
> "BatchMode yes" [EMAIL PROTECTED] "mkdir -p 
> /home/projects/livetribe/public_html/maven/."
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Disconnecting
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - 
> Session: Disconnected

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

[jira] Closed: (MNG-3314) offline build not running, when having SNAPSHOT dependencies

2008-06-06 Thread John Casey (JIRA)


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

John Casey closed MNG-3314.
---

  Assignee: John Casey
Resolution: Cannot Reproduce

I haven't been able to reproduce this error. I've incorporated a series of 
integration tests, as noted in the previous comment. If this bug is still 
present, and you can provide more details - or even better, a test build that's 
failing - then reopen it and I'll take another look.

> offline build not running, when having SNAPSHOT dependencies
> 
>
> Key: MNG-3314
> URL: http://jira.codehaus.org/browse/MNG-3314
> Project: Maven 2
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.0.7
>Reporter: Matthias Weßendorf
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.10
>
>
> am having troubles with
> mvn ... -o
> (with maven 2.0.7)
> says not able to download (but, really, the file is in my local repo)
> The dependency is a -SNAPSHOT (for what's worth)
> Luckily, when traveling by train, I had maven 2.0.4 on my box as well.
> A change to use 2.0.4 works fine.
> So, is this an already know bug in 2.0.7 ?
> To my understanding it is a bug, since offline just shouldn't try to get a 
> newer
> SNAPSHOT, perhaps I am wrong.
> I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect
> just not checking for new stuff.
> and... for some reasons, sometimes,
> it just downloads a new SNAPSHOT.
> That is a pain, when you are "maintaining" the same snapshot on your
> box, but the build just goes ahead and actually downloads a version.

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

[jira] Closed: (MNG-2695) -o makes build fail for snapshot plugins

2008-06-06 Thread John Casey (JIRA)


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

John Casey closed MNG-2695.
---

 Assignee: John Casey
   Resolution: Cannot Reproduce
Fix Version/s: (was: 2.1)
   2.0.10

As mentioned above, I cannot reproduce this error. I've added an integration 
test to the suite attempting to reproduce, but it may not capture the full 
scenario in play here.

If you can provide a test case that fails for this issue, reopen it and I'll 
take another look.

> -o makes build fail for snapshot plugins
> 
>
> Key: MNG-2695
> URL: http://jira.codehaus.org/browse/MNG-2695
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> I've set the maven-eclipse-plugin version to 2.3-SNAPSHOT in my root pom.
> When I run without -o, the build works fine. All 100 non-deployed 
> snapshot artifacts are resolved 100 times from all of my 10 remote 
> repo's so the build takes ages.
> After a succesful build, I run with -o and the build fails:
> {noformat}
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.plugins
> ArtifactId: maven-eclipse-plugin
> Version: 2.3-SNAPSHOT
> Reason: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> NOTE: Maven is executing in offline mode. Any artifacts not already in your 
> local
> repository will be inaccessible.
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build 
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM 
> 'org.apache.maven.
> plugins:maven-eclipse-plugin' not found in repository: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1269)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
> at 
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:394)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build 
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM 
> 'org.apache.mav
> en.plugins:maven-eclipse-plugin' not found in repository: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:266)
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:184)
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:164)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252)
> ... 15 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM 
> 'org.apache.maven.plugins:maven-eclipse-plugin' not found in repository: 
> System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:522)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:227)
> at 
> org.apache.maven.plugin.DefaultPluginManager.c

[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

2008-06-06 Thread JIRA


[ 
http://jira.codehaus.org/browse/MCHECKSTYLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137702#action_137702
 ] 

André Fügenschuh commented on MCHECKSTYLE-97:
-

I already noticed the change and migrated my pom,
adding my 'codestyle.jar' as a plugin dependency of 'maven-checkstyle-plugin'.

Same errors, same workaround.

> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at 
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.beanutils.Converter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> ... 22 more
> 2) antlr
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] antlr/CommonAST
> antlr.CommonAST
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: antlr/CommonAST
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defi

[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

2008-06-06 Thread Dennis Lundberg (JIRA)


[ 
http://jira.codehaus.org/browse/MCHECKSTYLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137704#action_137704
 ] 

Dennis Lundberg commented on MCHECKSTYLE-97:


Please post your pom.xml, or better yet - a complete sample project.
I am unable to reproduce the error you get.

> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at 
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.beanutils.Converter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> ... 22 more
> 2) antlr
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] antlr/CommonAST
> antlr.CommonAST
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: antlr/CommonAST
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at 
> jav

[jira] Commented: (MSITE-332) Unable to load parent project from a relative path: Could not find the model file '/pom.xml'. for project unknown

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg commented on MSITE-332:
---

This was caused by this commit to doxia-tools:
https://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/src/main/java/org/apache/maven/doxia/tools/DefaultSiteTool.java?r1=640091&r2=649670&diff_format=h

I have locally reverted that change in the trunk of doxia-tools and that makes 
the reported error go away.

Benjamin can you shed some light on why that change was made?

> Unable to load parent project from a relative path: Could not find the model 
> file '/pom.xml'. for project unknown
> --
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project 
> directory.
> This started occurring last night for us, using 
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a 
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the 
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] SiteToolException: Error reading default site descriptor: 
> ${OUTPUTENCODING}
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException: 
> Error reading default site descriptor: ${OUTPUTENCODING}
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException: 
> Error reading default site descriptor: ${OUTPUTENCODING}
> at 
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)
> at 
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error reading 
> default site descriptor: ${OUTPUTENCODING}
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:527)
> at 
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226)
> ... 20 more
> Caused by: java.io.UnsupportedEncodingExce

[jira] Created: (MSHARED-22) Danish localization

2008-06-06 Thread Dennis Lundberg (JIRA)

Danish localization
---

 Key: MSHARED-22
 URL: http://jira.codehaus.org/browse/MSHARED-22
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-doxia-tools
Reporter: Dennis Lundberg




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

[jira] Commented: (MSITE-332) Unable to load parent project from a relative path: Could not find the model file '/pom.xml'. for project unknown

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg commented on MSITE-332:
---

OK, I think I understand the problem now.

On line 522 we now use an XmlReader to read the default-site.xml file. That 
file has no xml encoding yet - only a placeholder ${outputEncoding} that will 
be filled in later. But that doesn't happen until line 530, when the 
siteDescriptorContent is interpolated. See below. So we have a chicken-and-egg 
problem.

{code}
String siteDescriptorContent;

try
{
// Note the default is not a super class - it is used when 
nothing else is found
Reader reader = ReaderFactory.newXmlReader( 
getClass().getResourceAsStream( "/default-site.xml" ) );
siteDescriptorContent = IOUtil.toString( reader );
}
catch ( IOException e )
{
throw new SiteToolException( "Error reading default site 
descriptor: " + e.getMessage(), e );
}

siteDescriptorContent = getInterpolatedSiteDescriptorContent( 
props, project, siteDescriptorContent,
  
inputEncoding, outputEncoding );

decorationModel = readDecorationModel( siteDescriptorContent );
{code}


> Unable to load parent project from a relative path: Could not find the model 
> file '/pom.xml'. for project unknown
> --
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project 
> directory.
> This started occurring last night for us, using 
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a 
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the 
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] SiteToolException: Error reading default site descriptor: 
> ${OUTPUTENCODING}
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException: 
> Error reading default site descriptor: ${OUTPUTENCODING}
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException: 
> Error reading default site descriptor: ${OUTPUTENCODING}
> at 
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)

[jira] Commented: (MSHARED-16) stage dies at normalization of relative path

2008-06-06 Thread Dennis Lundberg (JIRA)


[ 
http://jira.codehaus.org/browse/MSHARED-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137709#action_137709
 ] 

Dennis Lundberg commented on MSHARED-16:


I think that this is a duplicate of MSHARED-15, which was fixed and included in 
maven-doxia-tools 1.0. I'm unable to produce any error from the testcase.

Martin, can you confirm that this is fixed in maven-doxia-tools 1.0?

> stage dies at normalization of relative path
> 
>
> Key: MSHARED-16
> URL: http://jira.codehaus.org/browse/MSHARED-16
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-doxia-tools
> Environment: Linux
>Reporter: Martin von Gagern
> Attachments: normalizeRelativePaths.patch, testcase.zip
>
>
> Since r640091, DefaultSiteTool from maven-doxia-tools tries to normalize 
> paths, which fails, as the current plexus-utils don't handle normalization of 
> relative paths, and the stage mojo seems to use them quite extensively.
> I have attached a small testcase, a parent project with a single child, and 
> site:stage as the default goal, so you can simply run "mvn" on the parent. 
> Debugging this shows that FileUtils.normalize is handed a path starting in 
> "../../".
> I have also attached a patch to plexus-utils that makes FileUtils.normalize 
> handle relative paths, but I'm not sure if this would be intended, and I 
> can't test it, because I can't get maven use the latest snapshot of 
> plexus-utils, even if stated as an explicit dependency of the site plugin.
> See also:
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/src/main/java/org/apache/maven/doxia/tools/DefaultSiteTool.java?r1=637431&r2=640091&diff_format=h#l72
> http://fisheye.codehaus.org/browse/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java

-- 
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: (MSHARED-15) DefaultSiteTools fails on paths with prefix "../"

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg updated MSHARED-15:
---

Fix Version/s: maven-doxia-tools 1.0

> DefaultSiteTools fails on paths with prefix "../"
> -
>
> Key: MSHARED-15
> URL: http://jira.codehaus.org/browse/MSHARED-15
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-doxia-tools
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: maven-doxia-tools 1.0
>
>
> {noformat}
> [ERROR] NORMALIZE: ../../../../localhost/G/test/site
> [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:1938)
> at org.codehaus.plexus.util.FileUtils.normalize(FileUtils.java:1101)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.getNormalizedPath(DefaultSiteTool.java:199)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.getRelativePath(DefaultSiteTool.java:246)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.appendMenuItem(DefaultSiteTool.java:1324)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.populateModulesMenuItemsFromModels(DefaultSiteTool.java:1297)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.populateModules(DefaultSiteTool.java:927)
> at 
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:551)
> at 
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226)
> at 
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at 
> org.apache.maven.plugins.site.SiteStageMojo.execute(SiteStageMojo.java:105)
> {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] Closed: (MSITE-81) Site descriptor resolution never falls back to site.xml

2008-06-06 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MSITE-81.


   Resolution: Not A Bug
Fix Version/s: (was: 2.0-beta-8)

As noted by Brett earlier the error is expected is the repo is not available.

> Site descriptor resolution never falls back to site.xml
> ---
>
> Key: MSITE-81
> URL: http://jira.codehaus.org/browse/MSITE-81
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site descriptor
>Reporter: Indrajit Raychaudhuri
>Priority: Critical
> Attachments: site.log, sitemojo.patch
>
>
> For default locale (i.e., Locale.getDefault() is "en") site descriptor for 
> parent project attempt to resolve site_en.xml.
> But it doesn't fallback to site.xml.

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

[jira] Commented: (MECLIPSE-126) mark contents of "target" directory as derived

2008-06-06 Thread Thomas Ferris Nicolaisen (JIRA)


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

Thomas Ferris Nicolaisen commented on MECLIPSE-126:
---

+1 on the re-open.

Perhaps it's not correct to use target/derived technique directly if this is 
hard to achieve by manipulating Eclipse's meta-data. 

What we want is simply not to encounter build directory resources when (1) 
opening resources, and (2) while searching (optionally).

> mark contents of "target" directory as derived
> --
>
> Key: MECLIPSE-126
> URL: http://jira.codehaus.org/browse/MECLIPSE-126
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andreas Schildbach
>Assignee: fabrizio giustina
> Fix For: 2.3
>
>
> Eclipse has the notion of "derived resources", which are normally excluded 
> from many dialogs like the "Open Resource" dialog (Ctrl-Shift-R). Without 
> this marker, all those dialogs would be cluttered with unrelevant files 
> (which can't be edited anyway because they will be overwritten on the next 
> build).
> Unfortunately, unlike Eclipse itself, "mvn eclipse:eclipse" does not mark 
> generated files as derived. A good candidate would be the entire contents of 
> the "target" directory.

-- 
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: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

2008-06-06 Thread JIRA


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

André Fügenschuh updated MCHECKSTYLE-97:


Attachment: checkstyle-dependencies.zip

Here's a simple sample project.

Without any editing, it should fail ...

I assume that you got a test plugin like the one named 'whizbang' mentioned in 
the docs; although it looks that it doesn't matter ...
(the cp errors occur before any complaints about missing config files ...)

Please note the comments in the pom;
e.g. *my* 'whizbang' plugin is *not* a submodule, it's simply a plugin of its 
own residing in my local repo.

> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
> Attachments: checkstyle-dependencies.zip
>
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at 
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at 
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.beanutils.Converter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> ... 22 more
> 2) antlr
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> --

[jira] Commented: (ARCHETYPE-181) Missing class org/apache/commons/lang/StringUtils

[jira] Issue Comment Edited: (ARCHETYPE-181) Missing class org/apache/commons/lang/StringUtils

[jira] Updated: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

[jira] Commented: (MAVENUPLOAD-2093) RabbitMQ Java Client For AMQP

[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

[jira] Closed: (MJAVADOC-196) Create AggregatorJavadocMojo similar to AggregatorSourceJarMojo

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Commented: (MSITE-163) The modules menu is not inherited

[jira] Created: (MSITE-334) site url inheritance broken

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Commented: (MSITE-25) mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Commented: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Closed: (MJAVADOC-194) javadoc 2.4 does not [build-helper:add-source {execution: add-source}] when aggregating a javadoc for a project

[jira] Commented: (MECLIPSE-126) mark contents of "target" directory as derived

[jira] Commented: (MSITE-25) mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml

[jira] Closed: (MNG-3314) offline build not running, when having SNAPSHOT dependencies

[jira] Closed: (MNG-2695) -o makes build fail for snapshot plugins

[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

[jira] Commented: (MSITE-332) Unable to load parent project from a relative path: Could not find the model file '/pom.xml'. for project unknown

[jira] Created: (MSHARED-22) Danish localization

[jira] Commented: (MSITE-332) Unable to load parent project from a relative path: Could not find the model file '/pom.xml'. for project unknown

[jira] Commented: (MSHARED-16) stage dies at normalization of relative path

[jira] Updated: (MSHARED-15) DefaultSiteTools fails on paths with prefix "../"

[jira] Closed: (MSITE-81) Site descriptor resolution never falls back to site.xml

[jira] Commented: (MECLIPSE-126) mark contents of "target" directory as derived

[jira] Updated: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr

29 matches

Site Navigation

Mail list logo

Footer information