[jira] Commented: (MECLIPSE-570) Nullpointer during Import Maven Project from SVN via Subclipse

2009-09-30 Thread Julien Martelli (JIRA) 

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

Julien Martelli commented on MECLIPSE-570:
--

Hi,

Same exception raised with the following environnement:

Subclipse 1.6.5
Subversion Server 1.5.1
Subversion client 1.6.5
Eclipse Ganymede 3.4.2
m2eclipse 0.9.8
java 1.5.0_14

When this exception is raised I cannot benefit from Subclipse command anymore, 
anyway restarting Eclipse fixes the problem.

> Nullpointer during Import Maven Project from SVN via Subclipse
> --
>
> Key: MECLIPSE-570
> URL: http://jira.codehaus.org/browse/MECLIPSE-570
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
> Environment: eclipse 3.4.2, java 1.6.0_13, subversion server 1.5.5, 
> subversion client 1.6, maven multiproject
>Reporter: Jochen Stiepel
>
> java.lang.NullPointerException
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)
> at 
> org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

-- 
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: (MECLIPSE-570) Nullpointer during Import Maven Project from SVN via Subclipse

2009-09-30 Thread Olivier Lamy (JIRA) 

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

Olivier Lamy closed MECLIPSE-570.
-

Resolution: Not A Bug

> Nullpointer during Import Maven Project from SVN via Subclipse
> --
>
> Key: MECLIPSE-570
> URL: http://jira.codehaus.org/browse/MECLIPSE-570
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
> Environment: eclipse 3.4.2, java 1.6.0_13, subversion server 1.5.5, 
> subversion client 1.6, maven multiproject
>Reporter: Jochen Stiepel
>
> java.lang.NullPointerException
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)
> at 
> org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

-- 
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-570) Nullpointer during Import Maven Project from SVN via Subclipse

2009-09-30 Thread Olivier Lamy (JIRA) 

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

Olivier Lamy commented on MECLIPSE-570:
---

AFAIK it looks more a m2e issue
So please move it here https://issues.sonatype.org/browse/MNGECLIPSE

> Nullpointer during Import Maven Project from SVN via Subclipse
> --
>
> Key: MECLIPSE-570
> URL: http://jira.codehaus.org/browse/MECLIPSE-570
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
> Environment: eclipse 3.4.2, java 1.6.0_13, subversion server 1.5.5, 
> subversion client 1.6, maven multiproject
>Reporter: Jochen Stiepel
>
> java.lang.NullPointerException
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)
> at 
> org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
> at 
> org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

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

[jira] Created: (MECLIPSE-605) JRE position in Eclipse generated classpath is different from the one used in Maven compiler

2009-09-30 Thread Aziz Joumady (JIRA) 
JRE position in Eclipse generated classpath is different from the one used in 
Maven compiler


 Key: MECLIPSE-605
 URL: http://jira.codehaus.org/browse/MECLIPSE-605
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Dependencies resolution and build path (.classpath)
Affects Versions: 2.7
 Environment: Maven version: 2.0.9
Java version: 1.5.0_17
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Aziz Joumady
 Attachments: MECLIPSEClasspathTest.zip

*Description*
In Maven (and all command line execution) rt.jar and all Java librairies are in 
first position for class loading purpose. Then follows the classpath defined by 
the user.
In contradiction generated classpath provided to Eclipse and used by it, moves 
the JRE Container to the end of the classpath.
It results a different behavior between Maven compilation and Eclipse 
compilation.

*Use case (see attached sample project) :*
Using {{org.w3c.dom.Element}} interface.
This interface is defined in xerces and Java 1.5.

Let's suppose I have a transitive dependency to xerces 1.4.4. Then the 
{{org.w3c.dom.Element}} interface is different from the one defined in Java 1.5.
(For testing purpose I used a direct dependency in sample project).
By using in the code the method {{getTextContent}} or {{setTextContent}}, it 
will point out the problem.

Then calling the {{mvn compile}} command will finish successfully, whereas in 
Eclipse the build will fail.

*Run the test case*
1/ Download the provided sample project
2/ Run the command {{mvn eclipse:clean eclipse:eclipse compile}}
3/ Open Eclipse & import the generated project
4/ Notice the error 
5/ Open the Java Build Path from project configuration
6/ Move the JRE Container above binaries
7/ Notice that the error is resolved

*Expected modifications*
I expect to have the JRE Container above all dependencies in the generated 
.classpath file of the maven eclipse plugin.
Indeed, defining the JRE Container at the bottom of the librairies looks like 
defining all librairies as bootstrap classpath.

-- 
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-105) Update to Checkstyle 5.0

2009-09-30 Thread Stevo Slavic (JIRA) 

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

Stevo Slavic commented on MCHECKSTYLE-105:
--

>From [this comment from Stephen 
>Connolly|http://www.nabble.com/Re%3A-buildnumber-plugin-p25395826.html] I 
>guess it would help if the patch included integration tests - with them maybe 
>the new version with checkstyle 5 support could be released before Maven 3.

> Update to Checkstyle 5.0
> 
>
> Key: MCHECKSTYLE-105
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Felix Röthenbacher
> Fix For: 2.4
>
> Attachments: patch.diff, update-to-5.0-812221.patch, 
> update-to-5.0.patch, update-to-5.0beta2.patch
>
>
> Checkstyle 5.0-beta01 adds support for generics, etc.
> See
> http://checkstyle.sourceforge.net/5.x/releasenotes.html
> for a list of new features.
> Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is 
> available from a public Maven repository.
> Patch updates plugin to changed API / implementation.

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

[jira] Created: (MAVENUPLOAD-2617) Upload javax.jcr:jcr:2.0

2009-09-30 Thread Jukka Zitting (JIRA) 
Upload javax.jcr:jcr:2.0


 Key: MAVENUPLOAD-2617
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2617
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Jukka Zitting


The final version of the JCR 2.0 API defined by JSR 283 [1] is now available 
[2]. The earlier JCR 1.0 API is available on Maven central as javax.jcr:jcr:1.0 
(see MAVENUPLOAD-1733), and I have prepared the following upload bundle for 
adding the new version as javax.jcr:jcr:2.0.


http://www.day.com/o.file/jcr-2.0-bundle.jar?get=847b4159d1540c2c37fd19b866348dd9

I am a member of the JSR 283 expert group (see [1]) and an employee of Day 
Software (see [3]), the spec lead company that controls the IP of the API.

In addition to the specification license [4], Day has published a license 
addendum [5] that grants broader rights to distribute and use the JCR API jar. 
This is equivalent to the licensing of the earlier JCR 1.0 API, and clears the 
API for redistribution on Maven central. The POM file included in the bundle 
contains  references to these license terms.

[1] http://jcp.org/en/jsr/detail?id=283
[2] http://jcp.org/aboutJava/communityprocess/final/jsr283/index.html
[3] http://dev.day.com/
[4] http://www.day.com/dam/day/downloads/jsr283/day-spec-license.htm
[5] http://www.day.com/content/dam/day/downloads/jsr283/LICENSE.txt


-- 
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: (MNGSITE-98) Correction to the Maven POM Reference - install:install-file example misses "-Dpackaging=jar"

2009-09-30 Thread Yuri Volkov (JIRA) 
Correction to the Maven POM Reference -  install:install-file example misses 
"-Dpackaging=jar"
--

 Key: MNGSITE-98
 URL: http://jira.codehaus.org/browse/MNGSITE-98
 Project: Maven 2 Project Web Site
  Issue Type: Bug
Reporter: Yuri Volkov
Priority: Minor


In http://maven.apache.org/pom.html#Dependencies
Using the example:
---
...There are three methods for dealing with this scenario.
Install the dependency locally using the install plugin. The method is the 
simplest recommended method. For example:

mvn install:install-file -Dfile=non-maven-proj.jar -DgroupId=some.group 
-DartifactId=non-maven-proj -Dversion=1
---
- end in maven build error:
"Missing group, artifact, version, or packaging information".

To fix this problem, "-Dpackaging=jar" should be added to the command line.
The correct example command is:
---
mvn install:install-file -Dfile=non-maven-proj.jar -DgroupId=some.group 
-DartifactId=non-maven-proj -Dversion=1 -Dpackaging=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: (MRESOURCES-106) Plugin does not respect escapeWindowsPaths default-value

2009-09-30 Thread John Casey (JIRA) 

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

John Casey updated MRESOURCES-106:
--

Fix Version/s: (was: 2.5)
   2.4.1

moving to 2.4.1 bucket. I think this fix warrants a separate bugfix release, 
since IIRC it effectively reverses default behavior from 2.3 (since it's 
specified incorrectly in 2.4).

> Plugin does not respect escapeWindowsPaths default-value
> 
>
> Key: MRESOURCES-106
> URL: http://jira.codehaus.org/browse/MRESOURCES-106
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Marvin Froeder
>Assignee: Benjamin Bentmann
> Fix For: 2.4.1
>
> Attachments: maven-resources-plugin.patch, 
> maven-resources-plugin.patch, maven-resources-plugin.patch
>
>


-- 
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: (MREPOSITORY-19) Require SCM information to help tooling for project materialization from the repository

2009-09-30 Thread John Casey (JIRA) 

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

John Casey closed MREPOSITORY-19.
-

Resolution: Fixed

Added requirement for the SCM section, except when disableMaterialization is 
specified AND the user confirms this decision. We want this to be a huge hoop 
to jump through, to try to urge people to make upload bundles as usable as 
possible.

ITs have also been added.

> Require SCM information to help tooling for project materialization from the 
> repository
> ---
>
> Key: MREPOSITORY-19
> URL: http://jira.codehaus.org/browse/MREPOSITORY-19
> Project: Maven 2.x Repository Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.3
>
>
> if we require SCM information to be included in uploaded POMs it will 
> drastically improve the ability of tooling to materialize/checkout these 
> project sources for reference on-demand. This makes software development 
> immeasurably easier, especially for working with open source projects.

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

[jira] Closed: (MRESOURCES-105) Custom Delimiters does not work as expected - NPE with ${*} and comments in property file does break replacement

2009-09-30 Thread John Casey (JIRA) 

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

John Casey closed MRESOURCES-105.
-

   Resolution: Fixed
Fix Version/s: (was: 2.5)
   2.4.1

new plexus-interpolation provides a safety net for this to keep it from blowing 
up, and a small change in the resources plugin detects any null delimiters 
(which is what gets passed in if you specify an invalid ${xxx} expression in a 
list-style configuration parameter in Maven), and replaces them with:

{noformat}
${*}
{noformat}

This isn't precisely correct, so I'm going to file another issue to take a look 
at the larger issue later.

> Custom Delimiters does not work as expected - NPE with ${*} and comments in 
> property file does break replacement
> 
>
> Key: MRESOURCES-105
> URL: http://jira.codehaus.org/browse/MRESOURCES-105
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Ubuntu Jaunty, Sun JDK 1.6.0_16, Maven 2.2.1
>Reporter: Torsten Krah
>Assignee: Olivier Lamy
> Fix For: 2.4.1
>
> Attachments: test.tar.bz2
>
>
> Hi, 
> using custom delimiters, stuff is not working as expected.
> 
> org.apache.maven.plugins
> maven-resources-plugin
> 2.4
> 
> false
> 
> $
> @
> #
> ${*}
> 
> UTF-8
> 
> 
> mvn clean resources:resources does result in a NPE:
> java.lang.NullPointerException
> at  
> org.codehaus.plexus.interpolation.multi.DelimiterSpecification.parse(DelimiterSpecification.java:54)
> at 
> org.codehaus.plexus.interpolation.multi.MultiDelimiterStringSearchInterpolator.setDelimiterSpecs(MultiDelimiterStringSearchInterpolator.java:394)
> 
> Removing the ${*} it runs.
> However it breaks if "comments" are there in the property file. Using the 
> defaultDelimiters this is no problem.
> Additionally its not possible to use the default ones and specify additional 
> ones (maybe its a side effect and should work, don't know).
> The "$" gets ignored if i  use 
> true and  
> $ .
> Look at the attached project for an non working example. ${*} is commented in 
> the pom, use it to get the NPE.
> Removing the first comment line from the property file does result in a 
> successfull replacement (but comments are ok there so it should run with it 
> too) - let the comment there and it does only replace the first occurence of 
> the property.

-- 
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: (MRESOURCES-108) filter delimiter config that includes ${filter:*} will be changed to ${*} as of 2.4.1, causes NPE in 2.4

2009-09-30 Thread John Casey (JIRA) 
filter delimiter config that includes ${filter:*} will be changed to ${*} as of 
2.4.1, causes NPE in 2.4


 Key: MRESOURCES-108
 URL: http://jira.codehaus.org/browse/MRESOURCES-108
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
Affects Versions: 2.4, 2.4.1
Reporter: John Casey


This is the continuation of the problem expressed in MRESOURCES-105, for the 
more general case. It has something to do with the way the 
PluginParameterExpressionEvaluator and plexus itself resolves list-style plugin 
parameters.

-- 
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: (MRESOURCES-108) filter delimiter config that includes ${filter:*} will be changed to ${*} as of 2.4.1, causes NPE in 2.4

2009-09-30 Thread John Casey (JIRA) 

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

John Casey updated MRESOURCES-108:
--

Fix Version/s: 2.5

tentatively scheduling for 2.5, but may need to be pushed until later.

> filter delimiter config that includes ${filter:*} will be changed to ${*} as 
> of 2.4.1, causes NPE in 2.4
> 
>
> Key: MRESOURCES-108
> URL: http://jira.codehaus.org/browse/MRESOURCES-108
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.4, 2.4.1
>Reporter: John Casey
> Fix For: 2.5
>
>
> This is the continuation of the problem expressed in MRESOURCES-105, for the 
> more general case. It has something to do with the way the 
> PluginParameterExpressionEvaluator and plexus itself resolves list-style 
> plugin parameters.

-- 
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: (MAVENUPLOAD-2617) Upload javax.jcr:jcr:2.0

2009-09-30 Thread Carlos Sanchez (JIRA) 

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

Carlos Sanchez closed MAVENUPLOAD-2617.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> Upload javax.jcr:jcr:2.0
> 
>
> Key: MAVENUPLOAD-2617
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2617
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Jukka Zitting
>Assignee: Carlos Sanchez
>
> The final version of the JCR 2.0 API defined by JSR 283 [1] is now available 
> [2]. The earlier JCR 1.0 API is available on Maven central as 
> javax.jcr:jcr:1.0 (see MAVENUPLOAD-1733), and I have prepared the following 
> upload bundle for adding the new version as javax.jcr:jcr:2.0.
> 
> http://www.day.com/o.file/jcr-2.0-bundle.jar?get=847b4159d1540c2c37fd19b866348dd9
> I am a member of the JSR 283 expert group (see [1]) and an employee of Day 
> Software (see [3]), the spec lead company that controls the IP of the API.
> In addition to the specification license [4], Day has published a license 
> addendum [5] that grants broader rights to distribute and use the JCR API 
> jar. This is equivalent to the licensing of the earlier JCR 1.0 API, and 
> clears the API for redistribution on Maven central. The POM file included in 
> the bundle contains  references to these license terms.
> [1] http://jcp.org/en/jsr/detail?id=283
> [2] http://jcp.org/aboutJava/communityprocess/final/jsr283/index.html
> [3] http://dev.day.com/
> [4] http://www.day.com/dam/day/downloads/jsr283/day-spec-license.htm
> [5] http://www.day.com/content/dam/day/downloads/jsr283/LICENSE.txt

-- 
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: (MDOAP-25) foaf:Organization usage doesn't comply with DoaP/FoaF specs.

2009-09-30 Thread Tim Fliss (JIRA) 

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

Tim Fliss updated MDOAP-25:
---

Attachment: MDOAP-25.patch

This is a patch that generates correct foaf:Organization tags in relation to 
foaf:Person tags.
It includes unit test updates.

> foaf:Organization usage doesn't comply with DoaP/FoaF specs.
> 
>
> Key: MDOAP-25
> URL: http://jira.codehaus.org/browse/MDOAP-25
> Project: Maven 2.x DOAP Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: Any
>Reporter: Tim Fliss
>Priority: Minor
> Attachments: doap-organization-bugreport.tgz, MDOAP-25.patch
>
>
> Summary
> The foaf:Organization node is misplaced inside the foaf:Person node.  It is 
> not compliant with the FoaF or Doap specs.
> The Problem
> This is an instance of the issue described here: 
> http://lists.foaf-project.org/pipermail/foaf-dev/2009-January/009452.html
> foaf:Organization like foaf:Group is a foaf:Agent (see 
> http://xmlns.com/foaf/spec/#term_Agent), so the issue is the same.
> The recommended syntax from the DoaP project examples is to use the 
> foaf:member property between the foaf:Organization node and the foaf:Person 
> node.
> Unfortunately, per the FoaF spec, the relation only goes in that direction 
> (Organization->member->Person) with no convenient inverse property.
> The Fix
> The best fix I can currently find is to use blank nodes and a separate 
> Organization element that is not nested in the person element.  
> Unfortunately, because the DoaP plugin isn't using native RDF tools 
> internally, this will require a little more bookkeeping.
> 
> 
>   
>   
> 
> 
>John Doe
>mailto:j...@example.org"; />
> 
>   
> 
>   http://www.example.org"; />
>   
>  
> 
> Additional Info
> Info about rdf:nodeID is available at: 
> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-blank-nodes

-- 
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-265) Generate a combined javadoc using all dependency source jars.

2009-09-30 Thread Paul Gier (JIRA) 

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

Paul Gier commented on MJAVADOC-265:


I'm not looking for HTML versions of the source files.  I want javadoc to 
handle my project and all it's dependencies as if it were one large multimodule 
project, and generate a combined javadoc based on all the sources.  So this 
would require all -sources jars of the dependencies to be downloaded, and then 
added to javadoc path.  I'm not sure if javadoc would handle reading the jars 
directly, or maybe they would have to be unjarred first and then passed to the 
javadoc path.

> Generate a combined javadoc using all dependency source jars.
> -
>
> Key: MJAVADOC-265
> URL: http://jira.codehaus.org/browse/MJAVADOC-265
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: New Feature
>Reporter: Paul Gier
>
> I would like to be able to create a javadoc API that combines not only the 
> sources from my project modules, but also downloads available dependency 
> source files and includes these when generating the javadocs.

-- 
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-488) -Dgoals option no longer accepts a comma (in release:perform)

2009-09-30 Thread Chris LeCompte (JIRA) 
-Dgoals option no longer accepts a comma (in release:perform)
-

 Key: MRELEASE-488
 URL: http://jira.codehaus.org/browse/MRELEASE-488
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: perform
Affects Versions: 2.0-beta-9
Reporter: Chris LeCompte


The -Dgoals option no longer accepts a comma separated list of goals.  This 
appears to be related to the way that the InvokerMavenExecutor is parsing the 
string:

String[] rawGoals = goals.split( " " );

as opposed to the forked maven executor:

String[] tokens = StringUtils.split( goals, ", " );

a workaround for this is either to revert back to the beta-7 version, add the 
-DmavenExecutorId=forked-path or use spaces as a delimiter and quote the goals 
string.  To reproduce use a command like:

mvn release:perform -Dgoals=clean,install -DconnectionUrl=...

the command will fail with an error such as:

[INFO] [INFO] Invalid task 'clean,install': you must specify a valid lifecycle 
phase, or a goal in the format plugin:goal or 
pluginGroupId:pluginArtifactId:pluginVersion:goal

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

[jira] Commented: (MNG-4358) Multi-projects seem to send interrupt signals to some tasks

2009-09-30 Thread Gustavo Hexsel (JIRA) 

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

Gustavo Hexsel commented on MNG-4358:
-

Found it (I believe)!  The problem is that the behaviour of surefire "parallel 
mode" causes interruptions in threads that are not directly related to testing 
(and to tests too, causing tests that have Thread.sleep() tests to fail 
randomly).

Please mark it as invalid, delete, or just reassign to surefire (I don't have 
the rights to any of these actions)!

> Multi-projects seem to send interrupt signals to some tasks
> ---
>
> Key: MNG-4358
> URL: http://jira.codehaus.org/browse/MNG-4358
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 2.2.1
> Environment: All 64 bit.  Ubuntu 9.10 b5, OpenJDK Runtime Environment 
> (IcedTea6 1.6) (6b16-1.6-1ubuntu1).
>Reporter: Gustavo Hexsel
> Attachments: interrupt_on_resolve.tar.bz, out.tar.bz
>
>
> Tasks like exec:exec and surefire (testing) seem to receive an occasional 
> interrupt signal, causing the test or task to fail.  This only happens on 
> multi-module projects (i.e. if I run it a module at a time, it works).
> Here's an example stacktrace from exec:exec (I can try to reproduce the 
> surefire one as well):
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Command execution failed.
> Embedded error: Error while executing external command, process killed.
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Command execution 
> failed.
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
>   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:301)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:616)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Command execution 
> failed.
>   at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:288)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
>   ... 16 more
> Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while 
> executing external command, process killed.
>   at 
> org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:199)
>   at 
> org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:93)
>   at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:437)
>   at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:279)
>   ... 18 more
> Caused by: java.lang.InterruptedException
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at java.lang.UNIXProcess.waitFor(UNIXProcess.java:181)
>   at 
> org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:147)
>   ... 21 more

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