Nabble - Maven - Issues

[jira] Updated: (MJAR-97) Using when you have no dependencies fails with FileNotFoundException

2008-10-11T19:36:50Z

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

Randy Kamradt updated MJAR-97:
------------------------------

Attachment: fix.patch

possible solution to this issue

> Using <addClasspath> when you have no dependencies fails with FileNotFoundException
> -----------------------------------------------------------------------------------
>
> Key: MJAR-97
> URL: http://jira.codehaus.org/browse/MJAR-97
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_01
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Reporter: Wim Deblauwe
> Attachments: fix.patch
>
>
> When you have no dependencies in your project and configure <addClasspath>true</addClasspath> for the jar plugin, then maven exits with a strange error message:
> {noformat}
> Embedded error: Problem creating jar: C:\personal\mytool\target\classes (Access is denied)
> {noformat}
> If I run with -e, you can see that the classes directory is trying to be opened like it is a file:
> {noformat}
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> 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:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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: org.apache.maven.plugin.MojoExecutionException: Error assembling JAR
> at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:225)
> at org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:237)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating jar:
> C:\personal\mytool\target\classes (Access is denied)
> at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:690)
> at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:421)
> at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:218)
> ... 19 more
> Caused by: java.io.FileNotFoundException: C:\personal\mytool\target\classes (Access is denied)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
> at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:147)
> at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:132)
> at org.codehaus.plexus.archiver.jar.JarArchiver.grabFilesAndDirs(JarArchiver.java:922)
> at org.codehaus.plexus.archiver.jar.JarArchiver.createIndexList(JarArchiver.java:499)
> at org.codehaus.plexus.archiver.jar.JarArchiver.finalizeZipOutputStream(JarArchiver.java:422)
> at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:245)
> at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> ... 21 more
> {noformat}
> The workaround it to remove the <addClasspath/> thing ofcourse, but maven should give a better error message to avoid that people spend an hour searching for processes that keep the directory busy, when there is really a configuration problem.

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

[jira] Commented: (MJAR-97) Using when you have no dependencies fails with FileNotFoundException

2008-10-11T19:34:50Z

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

Randy Kamradt commented on MJAR-97:
-----------------------------------

This appears to be a problem because it uses the maven project classpath, which starts with the classes directory. Hacking the org.apache.maven.archiver.MavenArchiver to remove classpath entrys that end with 'classes' solves this. But it doesn't answer the question of why it's only a problem if target/classes is the only dependency. I'm attaching a patch of what I did in case anyone is interested.

> Using <addClasspath> when you have no dependencies fails with FileNotFoundException
> -----------------------------------------------------------------------------------
>
> Key: MJAR-97
> URL: http://jira.codehaus.org/browse/MJAR-97
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_01
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Reporter: Wim Deblauwe
>
> When you have no dependencies in your project and configure <addClasspath>true</addClasspath> for the jar plugin, then maven exits with a strange error message:
> {noformat}
> Embedded error: Problem creating jar: C:\personal\mytool\target\classes (Access is denied)
> {noformat}
> If I run with -e, you can see that the classes directory is trying to be opened like it is a file:
> {noformat}
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> 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:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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: org.apache.maven.plugin.MojoExecutionException: Error assembling JAR
> at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:225)
> at org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:237)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating jar:
> C:\personal\mytool\target\classes (Access is denied)
> at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:690)
> at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:421)
> at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:218)
> ... 19 more
> Caused by: java.io.FileNotFoundException: C:\personal\mytool\target\classes (Access is denied)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
> at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:147)
> at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:132)
> at org.codehaus.plexus.archiver.jar.JarArchiver.grabFilesAndDirs(JarArchiver.java:922)
> at org.codehaus.plexus.archiver.jar.JarArchiver.createIndexList(JarArchiver.java:499)
> at org.codehaus.plexus.archiver.jar.JarArchiver.finalizeZipOutputStream(JarArchiver.java:422)
> at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:245)
> at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> ... 21 more
> {noformat}
> The workaround it to remove the <addClasspath/> thing ofcourse, but maven should give a better error message to avoid that people spend an hour searching for processes that keep the directory busy, when there is really a configuration problem.

[jira] Closed: (DOXIA-244) Upgrade to fop 0.94

2008-10-11T15:58:51Z

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

Vincent Siveton closed DOXIA-244.
---------------------------------

Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.0-beta-1

upgraded to 0.95 in [r703746|http://svn.apache.org/viewvc?rev=703746&view=rev]

> Upgrade to fop 0.94
> -------------------
>
> Key: DOXIA-244
> URL: http://jira.codehaus.org/browse/DOXIA-244
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - FO
> Affects Versions: 1.0-beta-1
> Reporter: Lukas Theussl
> Assignee: Vincent Siveton
> Fix For: 1.0-beta-1
>
> Attachments: fo-0.94.log
>
>
> Fop 0.94 fixes several bugs [1], I think it's worth upgrading. Unfortunately just bumping the dependency I get an obscure build failure (see attached log) when converting to pdf, apparently because of multiple fo:page-sequence elements, which is not a problem with 0.93. Needs investigation.
> [1] http://xmlgraphics.apache.org/fop/0.94/changes_0.94.html

[jira] Commented: (SUREFIRE-524) Forked Process not terminated if maven process aborted. Provide means to clean up.

2008-10-11T15:28:50Z

[ http://jira.codehaus.org/browse/SUREFIRE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150585#action_150585 ]

Jason Zaugg commented on SUREFIRE-524:
--------------------------------------

The patch is against: http://svn.apache.org/repos/asf/maven/surefire/tags/surefire-2.4.3

> Forked Process not terminated if maven process aborted. Provide means to clean up.
> ----------------------------------------------------------------------------------
>
> Key: SUREFIRE-524
> URL: http://jira.codehaus.org/browse/SUREFIRE-524
> Project: Maven Surefire
> Issue Type: New Feature
> Components: process forking
> Affects Versions: 2.4.3
> Environment: Windows XP, JDK 6
> Reporter: Jason Zaugg
> Priority: Minor
> Attachments: surefire-2.4.3-remote-shutdown.patch
>
>
> Steps to reproduce:
> forkMode = once
> Run a test suite containing: Thread.sleep(Integer.MAX_VALUE)
> Kill maven build
> Observe that surefire JVM still running.
> Use Case:
> 1. Maven build on Contiunous Integration server forks a JVM to run long test suite.
> 2. User aborts the build.
> 3. User expects the test suite to be aborted.
> Workarounds:
> * use forkMode=never
> This is a hassle for us -- at best we have to log in remotely to the build server, find the process and kill it. At worst, we waste time misdiagnosing failures in the subsequently triggered build that are due to concurrent tests executing.
> I'm not sure what the expected behaviour is for maven / surefire currently in this situation.
> It is likely that is platform dependent. Windows is different from Unix in the way it kills child processes. [1]
> One solution would be to open up a TCP port on the forked JVM to enable a remote shutdown. This would integrate well with the Hudson Port Allocator plugin [2]. At the conclusion of an aborted build, Hudson would clean up the forked surefire JVM. Perhaps surefire itself could register a shutdown hook in the maven JVM which would use attempt a remote shutdown of the forked JVM?
> I've attached a patch to demonstrate the idea. If you would like to include this functionality, I could clean it up and add test cases.
> [1] http://darkforge.blogspot.com/2007/09/windows-killableprocess-and-case-of.html
> [2] http://weblogs.java.net/blog/kohsuke/archive/2007/11/hudson_portallo.html
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.4.3.1</version>
> <configuration>
> <excludes>
> <exclude>${integration.test.pattern}</exclude>
> </excludes>
> <forkMode>once</forkMode>
> <remoteShutdownPort>8999</remoteShutdownPort>
> </configuration>

[jira] Created: (SUREFIRE-524) Forked Process not terminated if maven process aborted. Provide means to clean up.

2008-10-11T15:22:51Z

Forked Process not terminated if maven process aborted. Provide means to clean up.
----------------------------------------------------------------------------------

Key: SUREFIRE-524
URL: http://jira.codehaus.org/browse/SUREFIRE-524
Project: Maven Surefire
Issue Type: New Feature
Components: process forking
Affects Versions: 2.4.3
Environment: Windows XP, JDK 6
Reporter: Jason Zaugg
Priority: Minor
Attachments: surefire-2.4.3-remote-shutdown.patch

Steps to reproduce:

forkMode = once
Run a test suite containing: Thread.sleep(Integer.MAX_VALUE)
Kill maven build
Observe that surefire JVM still running.

Use Case:

1. Maven build on Contiunous Integration server forks a JVM to run long test suite.
2. User aborts the build.
3. User expects the test suite to be aborted.

Workarounds:

* use forkMode=never

This is a hassle for us -- at best we have to log in remotely to the build server, find the process and kill it. At worst, we waste time misdiagnosing failures in the subsequently triggered build that are due to concurrent tests executing.

I'm not sure what the expected behaviour is for maven / surefire currently in this situation.

It is likely that is platform dependent. Windows is different from Unix in the way it kills child processes. [1]

One solution would be to open up a TCP port on the forked JVM to enable a remote shutdown. This would integrate well with the Hudson Port Allocator plugin [2]. At the conclusion of an aborted build, Hudson would clean up the forked surefire JVM. Perhaps surefire itself could register a shutdown hook in the maven JVM which would use attempt a remote shutdown of the forked JVM?

I've attached a patch to demonstrate the idea. If you would like to include this functionality, I could clean it up and add test cases.

[1] http://darkforge.blogspot.com/2007/09/windows-killableprocess-and-case-of.html
[2] http://weblogs.java.net/blog/kohsuke/archive/2007/11/hudson_portallo.html

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3.1</version>
<configuration>
<excludes>
<exclude>${integration.test.pattern}</exclude>
</excludes>
<forkMode>once</forkMode>
<remoteShutdownPort>8999</remoteShutdownPort>
</configuration>

--
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: (MCHANGELOG-80) support selecting of changes by revision-range for subversion

2008-10-11T01:33:50Z

[ http://jira.codehaus.org/browse/MCHANGELOG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150560#action_150560 ]

Thomas commented on MCHANGELOG-80:
----------------------------------

It would probably be better to change the patch from <revisions/> to a more generic <versions/>, which means all the documentation will also need to be re-changed. The Maven ScmProvider seems to work fine with SVN revision numbers fed into it as new ScmVersion()s.

> support selecting of changes by revision-range for subversion
> -------------------------------------------------------------
>
> Key: MCHANGELOG-80
> URL: http://jira.codehaus.org/browse/MCHANGELOG-80
> Project: Maven 2.x Changelog Plugin
> Issue Type: New Feature
> Reporter: Simon Kitching
> Attachments: changelog_svn_revision.patch
>
>
> Currently, only selecting by-date is supported for Subversion. However subversion has a problem with date-selection in some cases.
> In particular, when CVS projects are imported into subversion, and the original commit date info is preserved during import, then all subversion select-by-date operations are broken for the repository. This is a known issue with subversion, and not likely to be fixed in the near future. The basic issue is that subversion maps a date to a revision-number by doing a binary-search across all its revisions, and assumes that the commit-date for revision N is before the commit-date for revision N+M. This is not true when external repos (CVS or other) are imported into subversion with original commit dates preserved.
> One example of a repository where this is a problem is *svn.apache.org*; all select-by-date is completely broken for the apache repo; always has been and will be until (if) a subversion release is made that has an additional "committed on" attribute for each commit, and changes made to svn to use an index on this property rather than its existing binary-search.
> It would therefore be *very* nice to be able to specify a subversion revision range, eg "from r100000 to HEAD" as the input to the report.

[jira] Issue Comment Edited: (MCHANGELOG-80) support selecting of changes by revision-range for subversion

2008-10-11T01:29:51Z

[ http://jira.codehaus.org/browse/MCHANGELOG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150554#action_150554 ]

tfh2000 edited comment on MCHANGELOG-80 at 10/11/08 3:28 AM:
------------------------------------------------------------

added type="revision", fixed ChangeLogHandler, added to txt bundle, updated site (apt) files, only allowed for SVN b/c only tested with SVN + mvn 2.0.9. sup/BlueFish/

was (Author: tfh2000):
added type="revision", fixed ChangeLogHandler, added to txt bumdle, updated site (apt) files, only allowed for SVN b/c only tested with SVN + mvn 2.0.9. sup/BlueFish/

[jira] Updated: (MCHANGELOG-80) support selecting of changes by revision-range for subversion

2008-10-10T23:48:51Z

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

Thomas updated MCHANGELOG-80:
-----------------------------

Attachment: changelog_svn_revision.patch

added type="revision", fixed ChangeLogHandler, added to txt bumdle, updated site (apt) files, only allowed for SVN b/c only tested with SVN + mvn 2.0.9. sup/BlueFish/

[jira] Commented: (WAGON-246) Wagon.getFilelist does not work for WebDav

2008-10-10T21:48:50Z

[ http://jira.codehaus.org/browse/WAGON-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150542#action_150542 ]

Dan Tran commented on WAGON-246:
--------------------------------

place the below block

//WAGON-246
if ( ! url.endsWith( "/" ) )
{
url += "/";
}

at the beginning of WebDavWagon.isDirectory() method solves the second issue

> Wagon.getFilelist does not work for WebDav
> ------------------------------------------
>
> Key: WAGON-246
> URL: http://jira.codehaus.org/browse/WAGON-246
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
> Affects Versions: 1.0-beta-4
> Environment: xp, maven 2.1 M1
> Reporter: Dan Tran
>
> - getFilelist with URL at the root of dav ( https://dav.codehaus.org/snapshots.repository/mojo ) return ".DS_Store"
> - getFilelist with URL at the root of dav + path/to/validdirectory throws exception:
> Embedded error: Destination path exists but is not a WebDAV collection (directory):
> https://dav.codehaus.org/snapshots.repository/mojo/org/codehaus/mojo/build-helper-maven-plugin/1.2-SNAPSHOT
> details is here
> http://www.nabble.com/About-wagon-jackrabit%27s-webdav-td19926351.html

[jira] Commented: (WAGON-246) Wagon.getFilelist does not work for WebDav

2008-10-10T21:34:50Z

[ http://jira.codehaus.org/browse/WAGON-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150541#action_150541 ]

Dan Tran commented on WAGON-246:
--------------------------------

by forcing a "/" at the end, getFileList works

https://dav.codehaus.org/snapshots.repository/mojo/org/codehaus/mojo/build-helper-maven-plugin/1.2-SNAPSHOT/

-D

[jira] Updated: (WAGON-246) Wagon.getFilelist does not work for WebDav

2008-10-10T21:12:50Z

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

Dan Tran updated WAGON-246:
---------------------------

Description:
- getFilelist with URL at the root of dav ( https://dav.codehaus.org/snapshots.repository/mojo ) return ".DS_Store"

- getFilelist with URL at the root of dav + path/to/validdirectory throws exception:
Embedded error: Destination path exists but is not a WebDAV collection (directory):
https://dav.codehaus.org/snapshots.repository/mojo/org/codehaus/mojo/build-helper-maven-plugin/1.2-SNAPSHOT

details is here

http://www.nabble.com/About-wagon-jackrabit%27s-webdav-td19926351.html

was:

- getFilelist with URL at the root of dav ( https://dav.codehaus.org/snapshots.repository/mojo ) return ".DS_Store"

- getFilelist with URL at the root of dav + path/to/validdirectory throws exception:
Embedded error: Destination path exists but is not a WebDAV collection (directory):
https://dav.codehaus.org/snapshots.repository/mojo/org/codehaus/mojo/build-helper-maven-plugin/1.2-SNAPSHOT

details is here

http://www.nabble.com/About-wagon-jackrabit%27s-webdav-td19926351.html

Summary: Wagon.getFilelist does not work for WebDav (was: Wagon.getFilelist does not work)

[jira] Created: (WAGON-246) Wagon.getFilelist does not work

2008-10-10T21:10:51Z

Wagon.getFilelist does not work
-------------------------------

Key: WAGON-246
URL: http://jira.codehaus.org/browse/WAGON-246
Project: Maven Wagon
Issue Type: Bug
Components: wagon-webdav
Affects Versions: 1.0-beta-4
Environment: xp, maven 2.1 M1
Reporter: Dan Tran

- getFilelist with URL at the root of dav ( https://dav.codehaus.org/snapshots.repository/mojo ) return ".DS_Store"

- getFilelist with URL at the root of dav + path/to/validdirectory throws exception:
Embedded error: Destination path exists but is not a WebDAV collection (directory):
https://dav.codehaus.org/snapshots.repository/mojo/org/codehaus/mojo/build-helper-maven-plugin/1.2-SNAPSHOT

details is here

http://www.nabble.com/About-wagon-jackrabit%27s-webdav-td19926351.html

--
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-2234) reques for junitrecorder project to be rsynced

2008-10-10T18:05:51Z

reques for junitrecorder project to be rsynced
----------------------------------------------

Key: MAVENUPLOAD-2234
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2234
Project: Maven Upload Requests
Issue Type: Wish
Reporter: Rainer W

"com.seitenbau.testing","mavensync@...:/home/groups/j/ju/junitrecorder/htdocs/m2","rsync_ssh","Rainer Weinhold","rainer.weinhold@...",,

--
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: (ARCHETYPE-215) upgrade jnlp archetype for 2.0-alpha-5

2008-10-10T15:09:51Z

upgrade jnlp archetype for 2.0-alpha-5
--------------------------------------

Key: ARCHETYPE-215
URL: http://jira.codehaus.org/browse/ARCHETYPE-215
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

partial archetype

--
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: (ARCHETYPE-214) upgrade izpack archetype for 2.0-alpha-5

2008-10-10T15:09:51Z

upgrade izpack archetype for 2.0-alpha-5
----------------------------------------

Key: ARCHETYPE-214
URL: http://jira.codehaus.org/browse/ARCHETYPE-214
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

partial archetype

--
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: (ARCHETYPE-212) upgrade jee simple archetype for 2.0-alpha-5

2008-10-10T15:07:51Z

upgrade jee simple archetype for 2.0-alpha-5
--------------------------------------------

Key: ARCHETYPE-212
URL: http://jira.codehaus.org/browse/ARCHETYPE-212
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

with jetty, cargo, glassfish v3

--
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: (ARCHETYPE-213) upgrade site archetype for 2.0-alpha-5

2008-10-10T15:07:51Z

upgrade site archetype for 2.0-alpha-5
--------------------------------------

Key: ARCHETYPE-213
URL: http://jira.codehaus.org/browse/ARCHETYPE-213
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

partial archetype

--
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: (ARCHETYPE-210) upgrade mojo archetype for 2.0-alpha-5

2008-10-10T15:05:51Z

upgrade mojo archetype for 2.0-alpha-5
--------------------------------------

Key: ARCHETYPE-210
URL: http://jira.codehaus.org/browse/ARCHETYPE-210
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

--
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: (ARCHETYPE-211) upgrade webapp archetype for 2.0-alpha-5

2008-10-10T15:05:51Z

upgrade webapp archetype for 2.0-alpha-5
----------------------------------------

Key: ARCHETYPE-211
URL: http://jira.codehaus.org/browse/ARCHETYPE-211
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

with usage of cargo and jetty

--
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: (ARCHETYPE-209) upgrade quickstart archetype for 2.0-alpha-5

2008-10-10T15:05:51Z

upgrade quickstart archetype for 2.0-alpha-5
--------------------------------------------

Key: ARCHETYPE-209
URL: http://jira.codehaus.org/browse/ARCHETYPE-209
Project: Maven Archetype
Issue Type: Sub-task
Reporter: Raphaël Piéroni

--
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: (ARCHETYPE-208) Upgrade example archetypes for 2.0-alpha-5

2008-10-10T15:03:51Z

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

Raphaël Piéroni updated ARCHETYPE-208:
--------------------------------------

Fix Version/s: 2.0-alpha-5

> Upgrade example archetypes for 2.0-alpha-5
> ------------------------------------------
>
> Key: ARCHETYPE-208
> URL: http://jira.codehaus.org/browse/ARCHETYPE-208
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Archetypes
> Reporter: Raphaël Piéroni
> Fix For: 2.0-alpha-5
>
>

[jira] Created: (ARCHETYPE-208) Upgrade example archetypes for 2.0-alpha-5

2008-10-10T15:03:51Z

Upgrade example archetypes for 2.0-alpha-5
------------------------------------------

Key: ARCHETYPE-208
URL: http://jira.codehaus.org/browse/ARCHETYPE-208
Project: Maven Archetype
Issue Type: Improvement
Components: Archetypes
Reporter: Raphaël Piéroni
Fix For: 2.0-alpha-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] Updated: (ARCHETYPE-89) archetypeng:create doesn't use configured repos to find artifacts

2008-10-10T15:01:51Z

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

Raphaël Piéroni updated ARCHETYPE-89:
-------------------------------------

Fix Version/s: 2.0-alpha-5

> archetypeng:create doesn't use configured repos to find artifacts
> -----------------------------------------------------------------
>
> Key: ARCHETYPE-89
> URL: http://jira.codehaus.org/browse/ARCHETYPE-89
> Project: Maven Archetype
> Issue Type: Bug
> Affects Versions: 2.0-alpha-2
> Reporter: Brian Fox
> Assignee: Raphaël Piéroni
> Fix For: 2.0-alpha-5
>
>
> I deployed a snapshot of the archetype and create isn't finding it even though i have the maven-snapshot repo in my settings. A secondary problem is that if nothing is found, you get into an infinite loop where it asks you to pick a number that isn't there.
> {noformat}
> $ mvn.bat archetypeng:create
> Using maven.home=c:\Program Files\maven2\bin\\..
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetypeng'.
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building Maven Default Project
> [INFO] task-segment: [archetypeng:create] (aggregator-style)
> [INFO] ----------------------------------------------------------------------------
> [INFO] Preparing archetypeng:create
> [INFO] [archetypeng:select-archetype]
> Choose group:
> 1: org.apache.maven.archetypes
> 2: org.codehaus.mojo.archetypes
> 3: org.apache.maven.its
> Choose a number: (1/2/3): 3
> [INFO] org.apache.maven.its: checking for updates from central
> Choose archetype:
> Choose a number: :
> {noformat}

[jira] Commented: (ARCHETYPE-207) package with artifactId isn't replaced by archetype:generate

2008-10-10T14:49:50Z

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

Raphaël Piéroni commented on ARCHETYPE-207:
-------------------------------------------

this issue comes from create-from-project

> package with artifactId isn't replaced by archetype:generate
> ------------------------------------------------------------
>
> Key: ARCHETYPE-207
> URL: http://jira.codehaus.org/browse/ARCHETYPE-207
> Project: Maven Archetype
> Issue Type: Bug
> Affects Versions: 2.0-alpha-4
> Reporter: nicolas de loof
> Priority: Minor
>
> On a multimodule project (https://platina.svn.sourceforge.net/svnroot/platina/platina-archetype/trunk), each module use as convention groupid + artifactid + module as package.
> When used to create an archetype and the generate a new project, the generated project still have the orinigal ("archetype") name as package, not the expected new project artifactId.
> sample :
> original : com.capgemini.archetype.domain (project artifactId is "archetype")
> actual : {groupid}.archetype.domain
> expected : {groupid}.{artifactId}.domain

[jira] Commented: (MNG-3609) xbean breaks embedding within netbeans by using java.beans.PropertyEditorManager.registerEditor

2008-10-10T14:43:51Z

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

Dain Sundstrom commented on MNG-3609:
-------------------------------------

This is fixed in, the currently unreleased, XBean 3.4.3. The JIRA issue is https://issues.apache.org/jira/browse/XBEAN-111

> xbean breaks embedding within netbeans by using java.beans.PropertyEditorManager.registerEditor
> -----------------------------------------------------------------------------------------------
>
> Key: MNG-3609
> URL: http://jira.codehaus.org/browse/MNG-3609
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
> Affects Versions: 3.0
> Environment: netbeans 6.1, mevenide 3.1.2+
> Reporter: Milos Kleint
> Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
> Attachments: xbean.patch
>
>
> The xbean binary shipping with maven in 2.1 is registering PropertyEditors via java.beans.PropertyEditorManager.registerEditor()
> that's wracking havoc in the IDE's own code that relies on it's own property editors with customizer ui to be present.
> http://www.netbeans.org/issues/show_bug.cgi?id=135868 is the obvious error everyone noticed, there's more subtle ones as well, like being unable to edit properties, or broken form GUI editor that's not processing real numbers correctly.
> I've hotfixed the issue by commenting out the property editor registration in xbean (attached)

[jira] Commented: (MRELEASE-313) add an option to set the profile(s) used to perform the release

2008-10-10T13:15:51Z

[ http://jira.codehaus.org/browse/MRELEASE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150511#action_150511 ]

Basil James Whitehouse III commented on MRELEASE-313:
-----------------------------------------------------

Can this profile also be activated when running release:prepare?

I have a multi-module project that builds a distribution archive that is only activated by a profile since developers don't normally need it and it's quite large (80 MB) and don't want to occupy space in the local Maven repo. In order for this distribute module to have it's version number changed by the release plugin it needs to be part of the release:prepare .

For now I use the performRelease property to activate it, but I'd rather not use that since it could also activate other things I don't normally need. E.g. mvn --batch-mode release:prepare release:perform -DperformRelease

> add an option to set the profile(s) used to perform the release
> ---------------------------------------------------------------
>
> Key: MRELEASE-313
> URL: http://jira.codehaus.org/browse/MRELEASE-313
> Project: Maven 2.x Release Plugin
> Issue Type: Wish
> Affects Versions: 2.0-beta-7
> Reporter: nicolas de loof
> Assignee: nicolas de loof
> Priority: Minor
> Fix For: 2.0-beta-8
>
>
> release:perform runs maven to build the released artifact with the current active profiles (AFAIK)
> It would be nice to have a configuration parameter to set release profiles, so that it does not depend on user environment.

[jira] Created: (SUREFIRE-523) linkXRef should link all tests, not just failed tests

2008-10-10T11:49:50Z

linkXRef should link all tests, not just failed tests
-----------------------------------------------------

Key: SUREFIRE-523
URL: http://jira.codehaus.org/browse/SUREFIRE-523
Project: Maven Surefire
Issue Type: Improvement
Components: report plugin
Affects Versions: 2.4.3
Reporter: Matthew Beermann

Currently, the linkXRef parameter has somewhat misleading documentation; it will link the surefire report to the test source only for /failing/ tests. We think it'd be extremely useful if the report (optionally?) included such links for /all/ tests. Right now, you have to make a mental note of the class name, then dig through the test source manually, which is quite a pain.

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

[jira] Commented: (MRELEASE-273) Regression: NullPointerException at end of standalone "release:perform"

2008-10-10T11:31:51Z

[ http://jira.codehaus.org/browse/MRELEASE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150508#action_150508 ]

Kevin Nardi commented on MRELEASE-273:
--------------------------------------

This is very annoying, as it causes our build system to appear to fail every time, and we have to check the log to see if it really succeeded or not. Can this please be fixed?

> Regression: NullPointerException at end of standalone "release:perform"
> -----------------------------------------------------------------------
>
> Key: MRELEASE-273
> URL: http://jira.codehaus.org/browse/MRELEASE-273
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-6
> Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
> Reporter: Max Bowsher
> Priority: Blocker
> Attachments: release.bug
>
>
> I executed "mvn release:perform -DconnectionUrl=scm:svn:......". The actual performing succeeded, but then the plugin failed with a NullPointerException - it seems that the plugin attempts to unconditionally run code analogous to "mvn release:clean", but this is inappropriate because release:perform is not supposed to require a project to be able to run.
> Output:
> {noformat}
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
> [INFO] Final Memory: 13M/23M
> [INFO] ------------------------------------------------------------------------
> [INFO] Cleaning up after release...
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [DEBUG] Trace
> java.lang.NullPointerException
> at org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
> at org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
> at org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
> at org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
> at org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
> at org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
> at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
> at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
> at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
> at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> 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:224)
> 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)
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
> [INFO] Final Memory: 4M/8M
> [INFO] ------------------------------------------------------------------------
> {noformat}

[jira] Commented: (MASSEMBLY-338) Overridden artifact finalName is ignored by the assembly plugin.

2008-10-10T09:54:50Z

[ http://jira.codehaus.org/browse/MASSEMBLY-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150506#action_150506 ]

Michael Osipov commented on MASSEMBLY-338:
------------------------------------------

Are you refering to: http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html#finalName

this finalName refers to <name>.zip for instance not the artifacts inside that zip.

> Overridden artifact finalName is ignored by the assembly plugin.
> ----------------------------------------------------------------
>
> Key: MASSEMBLY-338
> URL: http://jira.codehaus.org/browse/MASSEMBLY-338
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-1
> Environment: Maven 2.0.9, JDK 6, WinXP SP2
> Reporter: Michael Osipov
> Attachments: assemblyMapping.png
>
>
> I have a multimodule project.
> groupId: net.fckeditor
> Parent ArtifactId: fckeditor-java
> 1. module ArtifactId: java-core; finalName "fckeditor-${artifactId}-${version}" though => e.g. fckeditor-java-core-2.4-SNAPSHOT
> 2. module ArtifactId: java-demo; finalName "fckeditor-${artifactId}-${version}" though
> I did create a bin assembly. The assembly contains the jars but their names do not correspond to the overridden finalNames.
> An example picture is attached and the project can be checked out at our [trac|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk] and the [SVN|http://svn.fckeditor.net/FCKeditor.Java/trunk/] directly.
> Checkout the [bin.xml|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk/src/main/assembly/bin.xml] and comment out the first outputFileNameMapping and run "mvn clean site package assembly:assembly".
> You should be able to reproduce the problem.
> I did find a workaround for the problem by defining the outputFileNameMapping as same as in the modules poms. This works just because all modules have the same finalName remapping.