[jira] Commented: (MCOMPILER-142) classes complied by plexus-compiler-eclipse get 'source not found' problem in eclipse class file editor

2011-05-31 Thread Fco Javier Coira (JIRA)

[ 
http://jira.codehaus.org/browse/MCOMPILER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269094#action_269094
 ] 

Fco Javier Coira commented on MCOMPILER-142:


Some new?. I´ve got this problem. Are there some way for debugging?

 classes complied by plexus-compiler-eclipse get 'source not found' problem in 
 eclipse class file editor
 ---

 Key: MCOMPILER-142
 URL: http://jira.codehaus.org/browse/MCOMPILER-142
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Rice Yeh
Priority: Critical

 All classes complied by plexus-compiler-eclipse will get 'source not found' 
 problem in eclipse class file editor which is opened when you access the jar 
 file containing the compiled classes even though you have source jar 
 associated with the jar file. A guy met the same problem as mine, see 
 http://www.mail-archive.com/users@maven.apache.org/msg80120.html. The 
 following is his observation on this problem: 
 After having a look into the generated classes, I found that the debug 
 information is different from the one I compiled with eclipse
 jdt. For example,
 Debug information from eclipse jdt compiler
 Source File Name:   MyClass.java
 Debug information from plexus-compiler-eclipse maven plugin
 Source File Name:   com.mydomain.myproject.MyClass
 This probable causes the problem.
 Rice

-- 
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: (MPDF-51) NoSuchMethodError while calling Maven PDF Plugin via CLI

2011-05-31 Thread Karl Heinz Marbaise (JIRA)

[ 
http://jira.codehaus.org/browse/MPDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269166#action_269166
 ] 

Karl Heinz Marbaise commented on MPDF-51:
-

I checked with Maven 3.0.3 the trunk 
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-pdf-plugin/ 
(r1129830) and the result looks good:
{code}
[INFO] 
[INFO] --- maven-pdf-plugin:1.2-SNAPSHOT:pdf (pdf) @ maui ---
[INFO] Ignoring api call removed in maven 3, no reports are generated!
[INFO] Ignoring api call removed in maven 3, no reports are generated!
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 24.658s
[INFO] Finished at: Tue May 31 20:06:53 CEST 2011
[INFO] Final Memory: 25M/311M
[INFO] 
{code}
Also a PDF is generated which looks good except that the Project Reports 
(Changes Report) is missing in this PDF

The result for Maven 2.2.1 looks like this:
{code}
[INFO] Scanning for projects...
[INFO] 
[INFO] Building MaUI Test Guide
[INFO]task-segment: [clean, site]
[INFO] 
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /home/kama/ws-git/maui/target
[INFO] [assembly:single {execution: make-assembly}]
[INFO] Reading assembly descriptor: /home/kama/ws-git/maui/src.xml
[INFO] Building zip: /home/kama/ws-git/maui/target/maui-0.1-SNAPSHOT-src.zip
[INFO] Building tar : /home/kama/ws-git/maui/target/maui-0.1-SNAPSHOT-src.tar.gz
[INFO] Building tar : 
/home/kama/ws-git/maui/target/maui-0.1-SNAPSHOT-src.tar.bz2
[INFO] [doxia:render-books {execution: gernate-latex}]
[INFO] [site:site {execution: default-site}]
[INFO] Skipped About report, file index.html already exists for the English 
version.
[INFO] Generating Changes Report report.
[INFO] Generating Plugin Management report.
[INFO] Generating Mailing Lists report.
[INFO] Generating Continuous Integration report.
[INFO] Generating Project License report.
[INFO] Generating Project Team report.
[INFO] Generating Source Repository report.
[INFO] Generating Issue Tracking report.
[INFO] Generating Project Summary report.
[INFO] Generating Project Plugins report.
[INFO] Generating Dependencies report.
[INFO] [pdf:pdf {execution: pdf}]
[INFO] Generating Changes Report report.
ERROR [org.apache.fop.fo.FONode:83] 2011-05-31 20:12:13,564 - Image not found: 
images/update.gif
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 26 seconds
[INFO] Finished at: Tue May 31 20:12:13 CEST 2011
[INFO] Final Memory: 64M/353M
[INFO] 
{code}


 NoSuchMethodError while calling Maven PDF Plugin via CLI
 

 Key: MPDF-51
 URL: http://jira.codehaus.org/browse/MPDF-51
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: kama@office:~/ws-git/maui$ mvn --version
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: /home/kama/tools/maven
 Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 2.6.32-31-generic, arch: i386, family: unix
Reporter: Karl Heinz Marbaise

 Just called mvn pdf:pdf from the root directory of my Maven project which 
 results into the following failure:
 {code}
 kama@office:~/ws-git/maui$ mvn pdf:pdf | tee pdf.log
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building MaUI Test Guide 0.1-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO] --- maven-pdf-plugin:1.1:pdf (default-cli) @ maui ---
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 4.546s
 [INFO] Finished at: Mon May 30 20:17:00 CEST 2011
 [INFO] Final Memory: 13M/144M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project 
 maui: Execution default-cli of goal 
 org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf failed: An API 
 

Why the heck won't anyone respond?

2011-05-31 Thread deusaquilus
The plexus guys made a Jira entry for a P1 critical issue regarding the maven
compilers's inability to property handle a -Werror argument; the fix is a
trivial two line code swap: 
http://jira.codehaus.org/browse/MCOMPILER-120

I posted the diff 3 weeks ago yet nobody seems to reply! Can a commitier
please check this in?

--
View this message in context: 
http://maven.40175.n5.nabble.com/Why-the-heck-won-t-anyone-respond-tp4442994p4442994.html
Sent from the Maven - Issues mailing list archive at Nabble.com.


Re: Why the heck won't anyone respond?

2011-05-31 Thread Wendy Smoak
You've written to issues@, which is for automated notifications from
the issue tracker.

If you haven't gotten a reply on your JIRA issue after a while, a
[polite] nudge on dev@ is the next step.  (Hint:  Use a descriptive
subject rather than a rant.)

I see you're using Nabble, so here's a link to the dev list:
http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html

-- 
Wendy

On Tue, May 31, 2011 at 3:06 PM, deusaquilus deusaqui...@gmail.com wrote:
 The plexus guys made a Jira entry for a P1 critical issue regarding the maven
 compilers's inability to property handle a -Werror argument; the fix is a
 trivial two line code swap:
 http://jira.codehaus.org/browse/MCOMPILER-120

 I posted the diff 3 weeks ago yet nobody seems to reply! Can a commitier
 please check this in?

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Why-the-heck-won-t-anyone-respond-tp4442994p4442994.html
 Sent from the Maven - Issues mailing list archive at Nabble.com.



[jira] Commented: (MECLIPSE-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match

2011-05-31 Thread Mark McEver (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269175#action_269175
 ] 

Mark McEver commented on MECLIPSE-655:
--

I am experiencing this as well.  Does anyone know why this hasn't been resolved 
yet?  Or why more people aren't experiencing this problem?

Thanks,
Mark

 does not correctly resolve SNAPSHOTS from CI server with projects in 
 workspace because versions do not match
 

 Key: MECLIPSE-655
 URL: http://jira.codehaus.org/browse/MECLIPSE-655
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Dependencies resolution and build path 
 (.classpath)
Affects Versions: 2.8
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
 Java version: 1.5.0_16
Reporter: Jim Sellers
 Attachments: maven-eclipse-snapshot-issue.txt


 Scenario:
 1) Check out a library into your workspace, in SNAPSHOT mode.  e.g. the 
 version is 2.0-SNAPSHOT.
 2) This project is being built by a CI server, using the standard snapshot 
 artifact naming convention.  e.g. 2.0-20100513.210009-65
 3) In project in workspace that uses the library, when you run 
 eclipse:eclipse, in the .classpath file it will link to the jar in the 
 .m2/repository location.  In the log you'll see a message like:
 [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a 
 workspace project, but with different version. Expected: 
 2.0-20100513.210009-65, found: 2.0-SNAPSHOT
 The weird issues:
 W1) The difficult part is that if in the library you run a mvn install 
 command first, and then in the other project run mvn eclipse:eclipse, it 
 will correctly depend on your project in the workspace.
 W2) After doing W1, if the next day you re-run mvn eclipse:eclipse in the 
 non-library project, it will then resolve to the artifact built in the CI 
 server and no longer link the project to the library in the workspace.
 The workaround:
 Each day run mvn install in the library before running mvn 
 eclipse:eclipse in the other project.
 The solution (no patch yet, can't make it through the firewall at work):
 Instead of using org.apache.maven.artifact.Artifact#getVersion(), 
 getBaseVersion() should be used instead.
 In the AbstractIdeSupportMojo#doDependencyResolution() method, near the 
 bottom where it passing in the version, it should use the getBaseVersion()
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685
 In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) 
 method, it should compare the version in the workspace to the baseVersion
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941

-- 
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: (MCHANGES-250) ccAddresses and bccAddresses should not be 'required'

2011-05-31 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-250.


   Resolution: Fixed
Fix Version/s: 2.6
 Assignee: Dennis Lundberg

Fixed in [r1129881|http://svn.apache.org/viewvc?view=revisionrevision=1129881].

I went with the null check.

 ccAddresses and bccAddresses should not be 'required'
 -

 Key: MCHANGES-250
 URL: http://jira.codehaus.org/browse/MCHANGES-250
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: announcement
Affects Versions: 2.5
Reporter: Benson Margulies
Assignee: Dennis Lundberg
 Fix For: 2.6

 Attachments: MCHANGES-250.patch


 It seems unkind and unnecessary to require the cc and bcc. If one doesn't 
 need them, why require them?

-- 
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: (MCHANGES-247) StatusIds don't end up in the URL

2011-05-31 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-247.


Resolution: Duplicate

 StatusIds don't end up in the URL
 -

 Key: MCHANGES-247
 URL: http://jira.codehaus.org/browse/MCHANGES-247
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: jira
Affects Versions: 2.5
Reporter: Benson Margulies

 Running announcement-generate. Note from the -X output blob here that I have 
 selected more statusIds than 'Closed'. But then see the URL from a little 
 further down the trace, where statusIds=6.
 {noformat}
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-changes-plugin:2.5:announcement-generate' --
 [DEBUG]   (s) artifactId = basis-parent
 [DEBUG]   (f) basedir = /Users/benson/x/maven-support/basis-parent/trunk
 [DEBUG]   (s) developmentTeam = Common Parent for Basis Maven Projects team
 [DEBUG]   (s) finalName = basis-parent-26-SNAPSHOT
 [DEBUG]   (f) generateJiraAnnouncement = false
 [DEBUG]   (s) groupId = com.basistech
 [DEBUG]   (f) issueManagementSystems = [JIRA]
 [DEBUG]   (f) jiraMerge = false
 [DEBUG]   (f) jiraPassword = xx
 [DEBUG]   (f) jiraUser = maven-reporting
 [DEBUG]   (f) jiraXML = 
 /Users/benson/x/maven-support/basis-parent/trunk/target/jira-announcement.xml
 [DEBUG]   (f) mavenSession = org.apache.maven.execution.MavenSession@4e3e97cd
 [DEBUG]   (f) maxEntries = 25
 [DEBUG]   (s) outputDirectory = 
 /Users/benson/x/maven-support/basis-parent/trunk/target/announcement
 [DEBUG]   (s) packaging = pom
 [DEBUG]   (f) project = MavenProject: com.basistech:basis-parent:26-SNAPSHOT 
 @ /Users/benson/x/maven-support/basis-parent/trunk/pom.xml
 [DEBUG]   (f) resolutionIds = Fixed
 [DEBUG]   (f) runOnlyAtExecutionRoot = false
 [DEBUG]   (f) settings = org.apache.maven.settings.Settings@7fb6a1c4
 [DEBUG]   (f) statusIds = Resolved,Closed
 [DEBUG]   (f) template = announcement.vm
 [DEBUG]   (f) templateDirectory = org/apache/maven/plugin/announcement
 [DEBUG]   (f) tracQuery = order=id
 [DEBUG]   (s) url = http://hudson.basistech.net:8280/projects/basis-parent
 [DEBUG]   (s) version = 26-SNAPSHOT
 [DEBUG]   (s) xmlPath = 
 /Users/benson/x/maven-support/basis-parent/trunk/src/changes/changes.xml
 ...
 [DEBUG] Found the pid 10300 at 
 http://jira.basistech.net:8080/browse/MAVEN/component/10784
 [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null' 
 are correct.
 [DEBUG] download jira issues from url 
 http://jira.basistech.net:8080/secure/IssueNavigator.jspa?view=rsspid=10300statusIds=6resolutionIds=1tempMax=25reset=truedecorator=none
 [INFO] Downloading from JIRA at: 
 http://jira.basistech.net:8080/secure/IssueNavigator.jspa?view=rsspid=10300statusIds=6resolutionIds=1tempMax=25reset=truedecorator=none
 {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: (MCHANGES-249) The jira downloaded used for announcements only supports 'closed'

2011-05-31 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-249.


   Resolution: Fixed
Fix Version/s: 2.6
 Assignee: Dennis Lundberg

Patch applied in 
[r1129889|http://svn.apache.org/viewvc?view=revisionrevision=1129889].
Thanks!

 The jira downloaded used for announcements only supports 'closed'
 -

 Key: MCHANGES-249
 URL: http://jira.codehaus.org/browse/MCHANGES-249
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: announcement
Affects Versions: 2.5
Reporter: Benson Margulies
Assignee: Dennis Lundberg
 Fix For: 2.6

 Attachments: MCHANGES-249.patch


 org.apache.maven.plugin.announcement.JiraDownloader only puts 'Closed' in the 
 statusMap, so it's not possible to specify, say, Resolved,Closed. 
 Why are there two of these, anyhow?

-- 
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: (MCHANGES-246) Create an issue link template for Trackplus

2011-05-31 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-246.


   Resolution: Fixed
Fix Version/s: 2.6
 Assignee: Dennis Lundberg

Fixed in [r1129913|http://svn.apache.org/viewvc?view=revisionrevision=1129913].

 Create an issue link template for Trackplus
 ---

 Key: MCHANGES-246
 URL: http://jira.codehaus.org/browse/MCHANGES-246
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: other issue-trackers
Reporter: Benjamin Voigt
Assignee: Dennis Lundberg
 Fix For: 2.6


 Trackplus (http://www.trackplus.com/) is a commercial tracking system, that 
 we use in our company.
 The Issue Link Template would look like the following:
 %URL%/printItem.action?key=%ISSUE%

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




[jira] Commented: (MECLIPSE-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match

2011-05-31 Thread Jim Sellers (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269187#action_269187
 ] 

Jim Sellers commented on MECLIPSE-655:
--

Mark: I don't know why it's not been fixed.  Perhaps because I didn't submit a 
unit test?  We've been using a patched version of the eclipse plugin for a year 
now in order to get around this issue.  You might want to do the same.

 does not correctly resolve SNAPSHOTS from CI server with projects in 
 workspace because versions do not match
 

 Key: MECLIPSE-655
 URL: http://jira.codehaus.org/browse/MECLIPSE-655
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Dependencies resolution and build path 
 (.classpath)
Affects Versions: 2.8
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
 Java version: 1.5.0_16
Reporter: Jim Sellers
 Attachments: maven-eclipse-snapshot-issue.txt


 Scenario:
 1) Check out a library into your workspace, in SNAPSHOT mode.  e.g. the 
 version is 2.0-SNAPSHOT.
 2) This project is being built by a CI server, using the standard snapshot 
 artifact naming convention.  e.g. 2.0-20100513.210009-65
 3) In project in workspace that uses the library, when you run 
 eclipse:eclipse, in the .classpath file it will link to the jar in the 
 .m2/repository location.  In the log you'll see a message like:
 [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a 
 workspace project, but with different version. Expected: 
 2.0-20100513.210009-65, found: 2.0-SNAPSHOT
 The weird issues:
 W1) The difficult part is that if in the library you run a mvn install 
 command first, and then in the other project run mvn eclipse:eclipse, it 
 will correctly depend on your project in the workspace.
 W2) After doing W1, if the next day you re-run mvn eclipse:eclipse in the 
 non-library project, it will then resolve to the artifact built in the CI 
 server and no longer link the project to the library in the workspace.
 The workaround:
 Each day run mvn install in the library before running mvn 
 eclipse:eclipse in the other project.
 The solution (no patch yet, can't make it through the firewall at work):
 Instead of using org.apache.maven.artifact.Artifact#getVersion(), 
 getBaseVersion() should be used instead.
 In the AbstractIdeSupportMojo#doDependencyResolution() method, near the 
 bottom where it passing in the version, it should use the getBaseVersion()
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685
 In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) 
 method, it should compare the version in the workspace to the baseVersion
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941

-- 
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: (MWAR-164) Support for specifying which encoding to use when filtering resources

2011-05-31 Thread Florian Fray (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269188#action_269188
 ] 

Florian Fray commented on MWAR-164:
---

Could somebody please review the patch and respond to this issue?

Best regards,

Florian


 Support for specifying which encoding to use when filtering resources
 -

 Key: MWAR-164
 URL: http://jira.codehaus.org/browse/MWAR-164
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
Affects Versions: 2.1-alpha-1
Reporter: kai lilleby
 Fix For: 2.2

 Attachments: MWAR-164-maven-war-plugin.patch


 Quoting Hervé:
 {quote}
 Maven filtering provides an encoding parameter to set encoding used when
 reading/writing files. But war plugin uses null value, which means platform
 encoding... Sorry, encoding support won't be totally free ;)
 I added TODOs in the code.
 For web.xml and container config XML file, I set encoding to UTF-8, which is a
 better default value than platform encoding.
 For other filtered resources, you'll need to add an encoding attribute to
 o.a.m.model.Resource class, to let the user define which encoding he wants to
 use when filtering. Perhaps using project.build.sourceEncoding as a default
 value is a good idea.
 Seems like this is worth a Jira issue to track this new feature.
 {quote}

-- 
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: (MRESOURCES-131) Maven resources plugin does not honour maven.test.skip flag

2011-05-31 Thread Ryan Maki (JIRA)

[ 
http://jira.codehaus.org/browse/MRESOURCES-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269198#action_269198
 ] 

Ryan Maki commented on MRESOURCES-131:
--

The biggest problem from not honoring the flag is definitely seen when there 
are very large test data files to copy. It can also be a performance problem on 
certain operating systems if there are a lot of small files. Even when the 
tests are skipped these files fill up the ./target and the build never touches 
them. In one of my builds I can see Maven pause on the testResources step over 
and over throughout the lengthy build, even when I'm just running a quick 'mvn 
install -Dmaven.test.skip' to get the current artifacts into my local 
repository when I've synced changes.

(+1 obviously, many thanks for considering)

 Maven resources plugin does not honour  maven.test.skip  flag
 -

 Key: MRESOURCES-131
 URL: http://jira.codehaus.org/browse/MRESOURCES-131
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Kostis Me

 According to the official Maven documention the flag maven.test.skip means 
 that tests will not be compiled at all.
 If tests are not compiled then there is no need for the resources plugin to 
 copy the test resources in the output folder.
 This has a dentrimental effect to Maven project with thousands of integration 
 tests that use a lot of resources (e.g XML files, ZIP files, images.)
 The reason for this is that even if one uses the maven.test.skip flag in 
 order to speed up the build, the maven resources plugin still takes a lot of 
 time copying the test resources.
 It makes no sense for the plugin to copy the test resource if they are not 
 going to be used at all (the maven.test.skip flag)
  

-- 
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-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match

2011-05-31 Thread Mark McEver (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269202#action_269202
 ] 

Mark McEver commented on MECLIPSE-655:
--

Hmmm, strange.seems like it would affect more people.  Perhaps most people 
just use jar dependencies.  Thanks for the tip.

 does not correctly resolve SNAPSHOTS from CI server with projects in 
 workspace because versions do not match
 

 Key: MECLIPSE-655
 URL: http://jira.codehaus.org/browse/MECLIPSE-655
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Dependencies resolution and build path 
 (.classpath)
Affects Versions: 2.8
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
 Java version: 1.5.0_16
Reporter: Jim Sellers
 Attachments: maven-eclipse-snapshot-issue.txt


 Scenario:
 1) Check out a library into your workspace, in SNAPSHOT mode.  e.g. the 
 version is 2.0-SNAPSHOT.
 2) This project is being built by a CI server, using the standard snapshot 
 artifact naming convention.  e.g. 2.0-20100513.210009-65
 3) In project in workspace that uses the library, when you run 
 eclipse:eclipse, in the .classpath file it will link to the jar in the 
 .m2/repository location.  In the log you'll see a message like:
 [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a 
 workspace project, but with different version. Expected: 
 2.0-20100513.210009-65, found: 2.0-SNAPSHOT
 The weird issues:
 W1) The difficult part is that if in the library you run a mvn install 
 command first, and then in the other project run mvn eclipse:eclipse, it 
 will correctly depend on your project in the workspace.
 W2) After doing W1, if the next day you re-run mvn eclipse:eclipse in the 
 non-library project, it will then resolve to the artifact built in the CI 
 server and no longer link the project to the library in the workspace.
 The workaround:
 Each day run mvn install in the library before running mvn 
 eclipse:eclipse in the other project.
 The solution (no patch yet, can't make it through the firewall at work):
 Instead of using org.apache.maven.artifact.Artifact#getVersion(), 
 getBaseVersion() should be used instead.
 In the AbstractIdeSupportMojo#doDependencyResolution() method, near the 
 bottom where it passing in the version, it should use the getBaseVersion()
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685
 In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) 
 method, it should compare the version in the workspace to the baseVersion
 http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941

-- 
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: (MPDF-51) NoSuchMethodError while calling Maven PDF Plugin via CLI

2011-05-31 Thread Lukas Theussl (JIRA)

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

Lukas Theussl closed MPDF-51.
-

Resolution: Duplicate
  Assignee: Lukas Theussl

 NoSuchMethodError while calling Maven PDF Plugin via CLI
 

 Key: MPDF-51
 URL: http://jira.codehaus.org/browse/MPDF-51
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: kama@office:~/ws-git/maui$ mvn --version
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: /home/kama/tools/maven
 Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 2.6.32-31-generic, arch: i386, family: unix
Reporter: Karl Heinz Marbaise
Assignee: Lukas Theussl

 Just called mvn pdf:pdf from the root directory of my Maven project which 
 results into the following failure:
 {code}
 kama@office:~/ws-git/maui$ mvn pdf:pdf | tee pdf.log
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building MaUI Test Guide 0.1-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO] --- maven-pdf-plugin:1.1:pdf (default-cli) @ maui ---
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 4.546s
 [INFO] Finished at: Mon May 30 20:17:00 CEST 2011
 [INFO] Final Memory: 13M/144M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project 
 maui: Execution default-cli of goal 
 org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf failed: An API 
 incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf: 
 java.lang.NoSuchMethodError: 
 org.apache.maven.plugin.PluginManager.verifyReportPlugin(Lorg/apache/maven/model/ReportPlugin;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/execution/MavenSession;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;
 [ERROR] -
 [ERROR] realm =pluginorg.apache.maven.plugins:maven-pdf-plugin:1.1
 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
 [ERROR] urls[0] = 
 file:/home/kama/.m2/repository/org/apache/maven/plugins/maven-pdf-plugin/1.1/maven-pdf-plugin-1.1.jar
 [ERROR] urls[1] = 
 file:/home/kama/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar
 [ERROR] urls[2] = 
 file:/home/kama/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
 [ERROR] urls[3] = 
 file:/home/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.jar
 [ERROR] urls[4] = 
 file:/home/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0.4.3/maven-reporting-impl-2.0.4.3.jar
 [ERROR] urls[5] = 
 file:/home/kama/.m2/repository/commons-validator/commons-validator/1.2.0/commons-validator-1.2.0.jar
 [ERROR] urls[6] = 
 file:/home/kama/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
 [ERROR] urls[7] = 
 file:/home/kama/.m2/repository/commons-digester/commons-digester/1.6/commons-digester-1.6.jar
 [ERROR] urls[8] = file:/home/kama/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
 [ERROR] urls[9] = 
 file:/home/kama/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.1/maven-doxia-tools-1.1.jar
 [ERROR] urls[10] = 
 file:/home/kama/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar
 [ERROR] urls[11] = 
 file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1.1/doxia-logging-api-1.1.1.jar
 [ERROR] urls[12] = 
 file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1.2/doxia-sink-api-1.1.2.jar
 [ERROR] urls[13] = 
 file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
 [ERROR] urls[14] = 
 file:/home/kama/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
 [ERROR] urls[15] = 
 file:/home/kama/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
 [ERROR] urls[16] = 
 file:/home/kama/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
 [ERROR] urls[17] = 
 file:/home/kama/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
 [ERROR] urls[18] = 
 file:/home/kama/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
 [ERROR] urls[19] = 
 

[jira] Created: (MNG-5109) Passing Maven classpath to a ant mojo not working

2011-05-31 Thread Quentin Ng (JIRA)
Passing Maven classpath to a ant mojo not working
-

 Key: MNG-5109
 URL: http://jira.codehaus.org/browse/MNG-5109
 Project: Maven 2  3
  Issue Type: Bug
  Components: Class Loading
 Environment: Apache Maven 3.0.3 (r1075438; 2011-03-01 04:31:09+1100)
Maven home: /usr/share/maven3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_AU, platform encoding: UTF-8
OS name: linux, version: 2.6.35-28-generic, arch: amd64, family: unix
Reporter: Quentin Ng
 Attachments: qng-maven3.tar

I use a ant tast called listtopath 
This is part of:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/was-plugin-anttasks/1.0/

This task is to get around the headache of trying to get 
${maven.compile.classpath} to be passed from maven to the ant mojo.
It has worked like a treat in Maven 2 (I've included the maven 2 example)
but trying to run on maven 3 the CP isn't being passed through.

Basically this is what I do:
I have a simple mojo that takes a reference to the maven project.
It then uses the listtopath task to convert it into a refid that can be used.

eg.
The mojo.
the parameter to pass the maven project
pluginMetadata
mojos
mojo
goalejb-stub-compile/goal
callejb-stub-compile/call
requiresProjecttrue/requiresProject
!--- rest ommitted --//
parameter
namemavenproject/name
typeorg.apache.maven.project.MavenProject/type
requiredtrue/required
descriptionThis is the pom for the project. Property is
read-only (i.e you can not set it)
/description
/parameter

!--- rest ommitted --//


Then in my maven-ant build


project xmlns:artifact=antlib:org.apache.maven.artifact.ant
property environment=env value=/
!-- make reference to the listtopath --
taskdef name=listtopath 
classname=org.codehaus.mojo.wasanttasks.ListToPathTask
classpath
pathelement

location=${env.USERPROFILE}/.m2/repository/org/codehaus/mojo/was-plugin-anttasks/1.0/was-plugin-anttasks-1.0.jar/
/classpath
/taskdef

target name=ejb-stub-compile depends=init-windows,init-unix
echoStarting ejb stub compilation/echo

!-- using the maven project get the classpath --
listtopath targetRef=classpath mavenproject=mavenproject/
!-- convert it into a path and store in ref --
pathconvert property=converted.compile.classpath refid=classpath 
dirsep=//

!-- if the classpath works it should appear here --
echoclasspath:${converted.compile.classpath}/echo


After compiling this I make a local-repository reference and call it

the call in the pom.

 plugin
groupIdcom.nag.build/groupId
artifactIdejb-stub-compile/artifactId
version1.0.15/version
configuration
mavenproject 
implementation=org.apache.maven.project.MavenProject${project}/mavenproject
websphere.home${websphere.home}/websphere.home

input-file${project.build.directory}/${project.build.finalName}.jar/input-file

output-file${project.build.directory}/${project.build.finalName}-tmp.jar/output-file
/configuration

executions
execution
phasepre-integration-test/phase
goals
goalejb-stub-compile/goal
/goals
/execution
/executions
dependencies
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdwas-plugin-anttasks/artifactId
version1.0/version
/dependency
/dependencies
/plugin



The above worked with maven2 - migrating to Maven3 has caused the listtopath to 
stop working.
Alternatively there has to be an easier way to pass the cp through to ant

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