[jira] Commented: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127064 ] Maria Odea Ching commented on MRM-216: -- The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact - update metadata file Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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: (MRM-738) DaysOld Repository Purge Consumer throws Invalid Path to Artifact
DaysOld Repository Purge Consumer throws Invalid Path to Artifact
-
Key: MRM-738
URL: http://jira.codehaus.org/browse/MRM-738
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0
Environment: Tomcat 6.0.14
Windows Server 2003
Reporter: Geert Pante
Assignee: Brett Porter
I have the repository purge consumer enabled and configured as {{Repository
Purge By Days Older Than}} to 0 and {{Repository Purge By Retention Count}} set
to 3.
This is with a clean database.
I have more than 3 versions of org.irene:irene:2.0-SNAPSHOT already uploaded
into the repository.
When the repository is scanned:
{noformat}
290870 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [repository-purge] had an error when processing file
[D:\archiva-web\data\repositories\snapshots\org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar]:
Invalid path to Artifact: filename format is invalid,expected timestamp format
in filename.
org.apache.maven.archiva.consumers.ConsumerException: Invalid path to Artifact:
filename format is invalid,expected timestamp format in filename.
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(RepositoryPurgeConsumer.java:189)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
at
org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
at
org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:138)
at
org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:120)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:64)
at
org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:106)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Thread.java:595)
Caused by:
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeException:
Invalid path to Artifact: filename format is invalid,expected timestamp format
in filename.
at
org.apache.maven.archiva.consumers.core.repository.RetentionCountRepositoryPurge.process(RetentionCountRepositoryPurge.java:102)
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(RepositoryPurgeConsumer.java:185)
... 20 more
290885 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [metadata-updater] had an error when processing file
[D:\archiva-web\data\repositories\snapshots\org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar]:
Unable to convert to artifact reference:
org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar
org.apache.maven.archiva.consumers.ConsumerException: Unable to convert to
artifact reference:
org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processFile(MetadataUpdaterConsumer.java:167)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
at
org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
at
[jira] Commented: (MRM-738) DaysOld Repository Purge Consumer throws Invalid Path to Artifact
[
http://jira.codehaus.org/browse/MRM-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127108
]
Geert Pante commented on MRM-738:
-
The DaysOldRepositoryPurge has the same problem, but it does not use the
DefaultPathParser. I could download the file, however, so it's probably not a
duplicate of MRM-674.
There is also no qualifier at the end of the file name, so there is no problem
like in -tests.jar.
2008-03-13 16:35:58,809 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.Reposito
ryScanner:default - Consumer [repository-purge] had an error when processing
file [/data01/archiva/
data/repositories/snapshots/com/ford/vcc/gent/cip/eNextGenId-vem-slave/3.0-SNAPSHOT/eNextGenId-vem-s
lave-3.0-20080312.152330-21.pom]: Invalid path to Artifact: filename format is
invalid,expected time
stamp format in filename.
org.apache.maven.archiva.consumers.ConsumerException: Invalid path to Artifact:
filename format is i
nvalid,expected timestamp format in filename.
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(Re
positoryPurgeConsumer.java:189)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(C
onsumerProcessFileClosure.java:57)
...
Caused by:
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeException:
Invalid path
to Artifact: filename format is invalid,expected timestamp format in filename.
at
org.apache.maven.archiva.consumers.core.repository.DaysOldRepositoryPurge.process(DaysOld
RepositoryPurge.java:141)
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(Re
positoryPurgeConsumer.java:185)
... 23 more
DaysOld Repository Purge Consumer throws Invalid Path to Artifact
-
Key: MRM-738
URL: http://jira.codehaus.org/browse/MRM-738
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0
Environment: Tomcat 6.0.14
Windows Server 2003
Reporter: Geert Pante
Assignee: Brett Porter
I have the repository purge consumer enabled and configured as {{Repository
Purge By Days Older Than}} to 0 and {{Repository Purge By Retention Count}}
set to 3.
This is with a clean database.
I have more than 3 versions of org.irene:irene:2.0-SNAPSHOT already uploaded
into the repository.
When the repository is scanned:
{noformat}
290870 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [repository-purge] had an error when processing file
[D:\archiva-web\data\repositories\snapshots\org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar]:
Invalid path to Artifact: filename format is invalid,expected timestamp
format in filename.
org.apache.maven.archiva.consumers.ConsumerException: Invalid path to
Artifact: filename format is invalid,expected timestamp format in filename.
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(RepositoryPurgeConsumer.java:189)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
at
org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
at
org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:138)
at
org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:120)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:64)
at
org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:106)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
[jira] Commented: (MRM-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127154 ] Arun Nachimuthu commented on MRM-728: - I deployed continuum into the same tomcat instance and even this web application has the same issue. works with firefox and not with IE7 I will try and use ethreal or other tcp analyser and see the difference in the content exchanged on the wire between browser and server for firefox and ie. After successful admin login archiva reacts as if user is guest --- Key: MRM-728 URL: http://jira.codehaus.org/browse/MRM-728 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: linux Reporter: Robin Roos Fix For: 1.0.x Attachments: archiva.log I ran Archiva on my windows box and, after configuring the admin user, I was able to login. The header of the web page identified me as Administrator (admin) and I could see all the expected functions on the left hand frame. So far so good. I had Archiva installed on a linux box and started. I surfed to the box from Windows and configured the admin user. But when I logged in as admin I got a page with only Search/FindArtifact/Browse functions. The header page reads Login - Register. It is as if I am not logged in and am seeing the guest functions. Note that if I log in with a deliberately incorrect password then I get an error message as expected. But logging in with the right credentials appears to fail silently. As a result I cannot deploy any artifacts into Archiva, I cannot roll out the maven/subversion/archiva based edition of our in-house project, and I fear my time is limited! -- 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: (MRM-738) DaysOld Repository Purge Consumer throws Invalid Path to Artifact
[
http://jira.codehaus.org/browse/MRM-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-738:
-
Fix Version/s: 1.0.2
DaysOld Repository Purge Consumer throws Invalid Path to Artifact
-
Key: MRM-738
URL: http://jira.codehaus.org/browse/MRM-738
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0
Environment: Tomcat 6.0.14
Windows Server 2003
Reporter: Geert Pante
Assignee: Brett Porter
Fix For: 1.0.2
I have the repository purge consumer enabled and configured as {{Repository
Purge By Days Older Than}} to 0 and {{Repository Purge By Retention Count}}
set to 3.
This is with a clean database.
I have more than 3 versions of org.irene:irene:2.0-SNAPSHOT already uploaded
into the repository.
When the repository is scanned:
{noformat}
290870 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [repository-purge] had an error when processing file
[D:\archiva-web\data\repositories\snapshots\org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar]:
Invalid path to Artifact: filename format is invalid,expected timestamp
format in filename.
org.apache.maven.archiva.consumers.ConsumerException: Invalid path to
Artifact: filename format is invalid,expected timestamp format in filename.
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(RepositoryPurgeConsumer.java:189)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
at
org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
at
org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:138)
at
org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
at
org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:120)
at
org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:64)
at
org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:106)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Thread.java:595)
Caused by:
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeException:
Invalid path to Artifact: filename format is invalid,expected timestamp
format in filename.
at
org.apache.maven.archiva.consumers.core.repository.RetentionCountRepositoryPurge.process(RetentionCountRepositoryPurge.java:102)
at
org.apache.maven.archiva.consumers.core.repository.RepositoryPurgeConsumer.processFile(RepositoryPurgeConsumer.java:185)
... 20 more
290885 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [metadata-updater] had an error when processing file
[D:\archiva-web\data\repositories\snapshots\org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar]:
Unable to convert to artifact reference:
org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar
org.apache.maven.archiva.consumers.ConsumerException: Unable to convert to
artifact reference:
org\irene\irene\2.0-SNAPSHOT\irene-2.0-20071214.204316-1-test-sources.jar
at
[jira] Issue Comment Edited: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127064 ] oching edited comment on MRM-216 at 3/13/08 8:24 PM: --- The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact (for Maven 2 artifacts) - update metadata file was (Author: oching): The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact - update metadata file Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127168 ] Maria Odea Ching commented on MRM-216: -- Additional fix: - Added form validation and other validations in action class (-r636953) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127170 ] Maria Odea Ching commented on MRM-216: -- Additional fix: - generate or update checksums of metadata file (-r636957) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127171 ] Maria Odea Ching commented on MRM-216: -- Added instructions on how to deploy an artifact via the web UI form in archiva-docs (-r636970) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-216. Resolution: Fixed Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: Maria Odea Ching Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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] Assigned: (MRM-608) Unable to find project model for [...] if the initial import of the POM failed
[ http://jira.codehaus.org/browse/MRM-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-608: Assignee: Maria Odea Ching Unable to find project model for [...] if the initial import of the POM failed --- Key: MRM-608 URL: http://jira.codehaus.org/browse/MRM-608 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0 Environment: Windows32 Reporter: Arne Degenring Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 Attachments: archiva.log, data.zip It seems that Archiva is not properly updating the database if the initial import of the POM failed due to a parse error, even after the original problem has been corrected, the repository has been rescanned, and the database updated again. Steps to reproduce: 1. Start with a fresh Archiva 1.0 installation 2. Drop a group containing an artifact with a broken POM (illegal XML) to Archiva's internal repo directory 3. Run Scan Repository Now and Update Database Now. The log shows a ProjectModelException because the broken POM could not be parsed. 4. Fix the broken POM. Run Scan Repository Now and Update Database Now again. 5. Use the Browse page to browse to the artifact - you get the error message: Unable to find project model for [junit:junit:3.7]. I've attached the zipped contents of the data directory after performing the steps above, and the log file. Notice that there might be general repository scanning problem in 1.0 that could be related, see http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.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: (MRELEASE-333) allowTimestampedSnapshots is not applied to report plugins
allowTimestampedSnapshots is not applied to report plugins -- Key: MRELEASE-333 URL: http://jira.codehaus.org/browse/MRELEASE-333 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Environment: Any Reporter: Kalle Korhonen Related to already resolved MRELEASE-124. allowTimestampedSnapshots make it possible to force a release with uniquely versioned snapshots as dependencies, but the parameter has no effect on report snapshots dependencies. Looking at the code in the patch it seems the parameter is only applied to straight-up project dependencies. If you are forced to use reports that are only available as snapshots (currently e.g. the dashboard plugin), you are out of luck unless you deploy custom versions of the plugin in your internal repository or disable the reports for the release. -- 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-284) prepare step should check if local sources are complete
[ http://jira.codehaus.org/browse/MRELEASE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127058 ] Dominique Jean-Prost commented on MRELEASE-284: --- Thanks to Samuel for explaining the case I thought to when I raised the bug. It's true that tools like scm are not there to fix communication problems within development teams, and the release plugin isn't there for neither. Anyway, I guess such a little enhancement (as I'm writing this, I wonder if I should not have raised this problem as an enhancement instead of a bug...) can improve the release process, which is never trivial to my mind. prepare step should check if local sources are complete --- Key: MRELEASE-284 URL: http://jira.codehaus.org/browse/MRELEASE-284 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Dominique Jean-Prost Prepare step checks that all files are committed which is great. Prepare step should also check that the local dir is complete, ie, that there are no files missing in local dir (update needed) -- 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-334) Can't release project due to non released dependencies
Can't release project due to non released dependencies -- Key: MRELEASE-334 URL: http://jira.codehaus.org/browse/MRELEASE-334 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Kamen Petroff Attachments: maven-release-manager.patch I guess the problem is already known. But once again in maven-release-manager 1.0-alpha-4 org/apache/maven/shared/release/phase/CheckDependencySnapshotsPhase.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-334) Can't release project due to non released dependencies
[ http://jira.codehaus.org/browse/MRELEASE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamen Petroff updated MRELEASE-334: --- Attachment: maven-release-manager.patch Sorry, this is the working patch! Can't release project due to non released dependencies -- Key: MRELEASE-334 URL: http://jira.codehaus.org/browse/MRELEASE-334 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Kamen Petroff Attachments: maven-release-manager.patch, maven-release-manager.patch I guess the problem is already known. But once again in maven-release-manager 1.0-alpha-4 org/apache/maven/shared/release/phase/CheckDependencySnapshotsPhase.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-399) URL for javadoc attachments on Unix is invalid
[
http://jira.codehaus.org/browse/MECLIPSE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MECLIPSE-399:
---
Priority: Minor (was: Trivial)
URL for javadoc attachments on Unix is invalid
--
Key: MECLIPSE-399
URL: http://jira.codehaus.org/browse/MECLIPSE-399
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Unix, Eclipse 3.3
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: javadoc-file-uri.patch
Currently, the plugin constructs the URL for the javadoc attachment via
{code:java}
jar:file:/ + javadocpath + !/
{code}
Now, consider a unix path like /home/me/.m2/snip.jar. This will produce
the URL jar:file://home/me/.m2/snip.jar!/. Note the double slash after
file: which will cause home to be parsed as a hostname instead of a
directory. This misinterpretation makes Eclipse fail to access the javadocs.
Acceptable URLs would either be jar:file:/home/... or
jar:file:///home/
The simple solution is to use
{{[java.io.File.toURI()|http://java.sun.com/javase/6/docs/api/java/io/File.html#toURI()]}}
for this job. This method will not only properly handle slashes but also
care for encoding of characters that may appear in filesystem paths but are
illegal in URLs (most prominently spaces).
--
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: (MPIR-76) Dependencies report is incorrect
[
http://jira.codehaus.org/browse/MPIR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127087
]
Jim Christenson commented on MPIR-76:
-
I have the same problem with a different set of dependencies. Doesn't seem to
matter what order I put them in, one dependency does not get listed in the
project dependencies. It does get listed in the Transitive list. One
additional note, it does not get listed in the dependency tree.
Dependencies report is incorrect
Key: MPIR-76
URL: http://jira.codehaus.org/browse/MPIR-76
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Environment: Maven 2.0.7, SUN JVM 1.5.0_12, Windows XP
Reporter: Duncan Doyle
When generating a site from the following POM, the Dependencies report is
incorrect.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdTest/artifactId
packagingjar/packaging
version0.0.1-SNAPSHOT/version
nameTest/name
descriptionTest Dependency Graphs/description
dependencies
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version1.1/version
scopecompile/scope
/dependency
!-- override commons-logging's transitive dependency on servlet-api 2.3
--
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.4/version
scopecompile/scope
/dependency
/dependencies
distributionManagement
site
idTestDependencyGraph/id
urlfile://${site.distribution.directory}/TestDependencyGraph/url
/site
/distributionManagement
/project
{code}
The Dependencies report of this project's generated site doesn't show the
javax.servlet:servlet-api 2.4 as a compile dependency. Instead it shows it as
a transitivie dependency. My guess is that it finds the servlet-api 2.3
transitive dependency of commons-logging. However, the strange thing is that
it does show the 2.4 version number in the report.
The Dependency Graph has the same error, it shows the servlet-api as a
transitive dependency of commons-logging instead of a compile dependency of
my own project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3370) Fail build on circular dependencies
[ http://jira.codehaus.org/browse/MNG-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127088 ] Gilles Scokart commented on MNG-3370: - batik:batik-bridge and batik:batik-script:jar version 1.6-1 (used for example by fop) also have circular dependency. (See also MNG-3459) Fail build on circular dependencies --- Key: MNG-3370 URL: http://jira.codehaus.org/browse/MNG-3370 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Mark Hobson Currently circular dependencies are merely logged at debug level and not generally reported to the user. The general consensus is that circular dependencies are bad, so I believe that they should be reported as early on as possible. Previously the repository's low quality metadata was cited as a reason not to fail the build, but I would have thought such issues should have been rectified by now. Ideally we would throw a CyclicDependencyException in DefaultArtifactCollector. If this is deemed too invasive, then we should at least increase the log level in DebugResolutionListener to warning. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3459) Circular dependency stops depednency resolution
Circular dependency stops depednency resolution --- Key: MNG-3459 URL: http://jira.codehaus.org/browse/MNG-3459 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.8 Reporter: Gilles Scokart batik:batik-bridge and batik:batik-script:jar version 1.6-1 have a circular dependency. Depending where you start to depend on one of those, you will receive different dependencies. For example, if I have a module with a dependency of fop, I got this dependencies: [INFO] test1:testart:jar:1.0-SNAPSHOT [INFO] \- org.apache.xmlgraphics:fop:jar:0.93:compile [INFO]+- org.apache.xmlgraphics:xmlgraphics-commons:jar:1.1:compile [INFO]+- batik:batik-svg-dom:jar:1.6-1:compile [INFO]| +- batik:batik-dom:jar:1.6-1:compile [INFO]| | +- batik:batik-css:jar:1.6-1:compile [INFO]| | +- batik:batik-xml:jar:1.6-1:compile [INFO]| | \- xerces:xercesImpl:jar:2.5.0:compile [INFO]| \- batik:batik-parser:jar:1.6-1:compile [INFO]+- batik:batik-bridge:jar:1.6-1:compile [INFO]| \- batik:batik-script:jar:1.6-1:compile [INFO]+- batik:batik-awt-util:jar:1.6-1:compile [INFO]| \- batik:batik-util:jar:1.6-1:compile [INFO]| \- batik:batik-gui-util:jar:1.6-1:compile [INFO]+- batik:batik-gvt:jar:1.6-1:compile [INFO]+- batik:batik-transcoder:jar:1.6-1:compile [INFO]+- batik:batik-extension:jar:1.6-1:compile [INFO]+- batik:batik-ext:jar:1.6-1:compile [INFO]| \- xml-apis:xmlParserAPIs:jar:2.0.2:compile [INFO]+- commons-logging:commons-logging:jar:1.0.4:compile [INFO]+- commons-io:commons-io:jar:1.1:compile [INFO]+- org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:compile [INFO]\- org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:compile But If I have a module with direct dependencies on batik-script, I have : [INFO] test1:testart:jar:1.0-SNAPSHOT [INFO] \- batik:batik-script:jar:1.6-1:compile [INFO]+- batik:batik-bridge:jar:1.6-1:compile [INFO]+- batik:batik-svg-dom:jar:1.6-1:compile [INFO]| +- batik:batik-dom:jar:1.6-1:compile [INFO]| | +- batik:batik-css:jar:1.6-1:compile [INFO]| | +- batik:batik-xml:jar:1.6-1:compile [INFO]| | \- xerces:xercesImpl:jar:2.5.0:compile [INFO]| \- batik:batik-parser:jar:1.6-1:compile [INFO]+- batik:batik-gvt:jar:1.6-1:compile [INFO]| \- batik:batik-awt-util:jar:1.6-1:compile [INFO]| \- batik:batik-util:jar:1.6-1:compile [INFO]|\- batik:batik-gui-util:jar:1.6-1:compile [INFO]| \- batik:batik-ext:jar:1.6-1:compile [INFO]| \- xml-apis:xmlParserAPIs:jar:2.0.2:compile [INFO]\- rhino:js:jar:1.5R4.1:compile In the first case, the dependency rhino:js:jar is not included. In the second, it is. (See also MNG-3370 ) -- 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: (MDEP-155) writing classpath into a file doesn't work anymore
writing classpath into a file doesn't work anymore -- Key: MDEP-155 URL: http://jira.codehaus.org/browse/MDEP-155 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath Affects Versions: 2.0 Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: mac os x version: 10.4.11 arch: i386 Family: unix Reporter: Marc Guenther Assignee: Brian Fox Priority: Minor The following command from the Usage section (http://maven.apache.org/plugins/maven-dependency-plugin/usage.html) does not work anymore: mvn dependency:build-classpath -Dmaven.dep.cpFile=cp.txt It writes the classpath to the log, not to the specified file. This used to wirk in 2.0-alpha-4. Using outputFile doesn't work either. Another question: where does the maven.dep. prefix come from? This isn't documented anywhere. -- 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: (MDEP-155) writing classpath into a file doesn't work anymore
[ http://jira.codehaus.org/browse/MDEP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127094 ] Brian Fox commented on MDEP-155: The docs are wrong, see here for the correct expression: http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html#cpFile mdep is just a prefix used to keep the dependency values from conflicting with other plugins. It is recommended that plugins do this, but most of them don't. You can always check the proper expression on the goal page like shown above. writing classpath into a file doesn't work anymore -- Key: MDEP-155 URL: http://jira.codehaus.org/browse/MDEP-155 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath Affects Versions: 2.0 Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: mac os x version: 10.4.11 arch: i386 Family: unix Reporter: Marc Guenther Assignee: Brian Fox Priority: Minor The following command from the Usage section (http://maven.apache.org/plugins/maven-dependency-plugin/usage.html) does not work anymore: mvn dependency:build-classpath -Dmaven.dep.cpFile=cp.txt It writes the classpath to the log, not to the specified file. This used to wirk in 2.0-alpha-4. Using outputFile doesn't work either. Another question: where does the maven.dep. prefix come from? This isn't documented anywhere. -- 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: (MDEP-155) writing classpath into a file doesn't work anymore
[ http://jira.codehaus.org/browse/MDEP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127095 ] Marc Guenther commented on MDEP-155: Ah, that's why it didn't work, and that's why I didn't find the documentation for that prefix :) Thanks, I'm using -Dmdep.outputFile=... nown, and it works. writing classpath into a file doesn't work anymore -- Key: MDEP-155 URL: http://jira.codehaus.org/browse/MDEP-155 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath Affects Versions: 2.0 Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: mac os x version: 10.4.11 arch: i386 Family: unix Reporter: Marc Guenther Assignee: Brian Fox Priority: Minor The following command from the Usage section (http://maven.apache.org/plugins/maven-dependency-plugin/usage.html) does not work anymore: mvn dependency:build-classpath -Dmaven.dep.cpFile=cp.txt It writes the classpath to the log, not to the specified file. This used to wirk in 2.0-alpha-4. Using outputFile doesn't work either. Another question: where does the maven.dep. prefix come from? This isn't documented anywhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-297) Assembly broke on GNU/Linux - NullPointerException
Assembly broke on GNU/Linux - NullPointerException -- Key: MASSEMBLY-297 URL: http://jira.codehaus.org/browse/MASSEMBLY-297 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: $ mvn -version Maven version: 2.0.8 Java version: 1.5.0_15 OS name: linux version: 2.6.18-8.el5 arch: amd64 Family: unix Reporter: Robin Roos Attachments: buildlog.txt, unix.xml I have an assembly descriptor src/main/assembly/unix.xml which works on Windows but broke on Unix. When I commented out the following lines of the assembly descriptor then it worked on Unix: fileSet includes includeREADME*/include includeLICENSE*/include includeNOTICE*/include /includes filteredtrue/filtered /fileSet I have no README*, LICENSE* or NOTICE* files in my src tree. I have no filters defined in my pom.xml. The filteredtrue/filtered makes the assembly invoke filtering if the pom does define filters. With the above fileSet included in the fileSets element I get the following exception on assembly (on Unix only): (I had variously used lib and /lib as target directory when debugging this so ignore discrepencies in this regard) [INFO] Processing DependencySet (output=lib) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.io.File.lt;initgt;(File.java:194) at org.apache.maven.shared.model.fileset.util.FileSetManager.scan(FileSetManager.java:598) at org.apache.maven.shared.model.fileset.util.FileSetManager.getIncludedFiles(FileSetManager.java:186) at org.apache.maven.plugin.assembly.format.FileSetFormatter.formatFileSetForAssembly(FileSetFormatter.java:67) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.addFileSet(AddFileSetsTask.java:133) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.execute(AddFileSetsTask.java:87) at org.apache.maven.plugin.assembly.archive.phase.FileSetAssemblyPhase.execute(FileSetAssemblyPhase.java:54) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) 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: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: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: 9 seconds [INFO] Finished at: Thu Mar 13 12:42:17 GMT 2008 [INFO] Final Memory: 19M/470M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3370) Fail build on circular dependencies
[ http://jira.codehaus.org/browse/MNG-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127113 ] Paul Benedict commented on MNG-3370: If A depends on B and B depends on A, I don't see why the build should fail. You need both A and B on your classpath to compile. Circular dependencies can be solved by putting in place holders (i.e., proxies) and then making a second pass to clean them up. So I think the logging should switch from DEBUG to WARN, but definitely be resolved. Fail build on circular dependencies --- Key: MNG-3370 URL: http://jira.codehaus.org/browse/MNG-3370 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Mark Hobson Currently circular dependencies are merely logged at debug level and not generally reported to the user. The general consensus is that circular dependencies are bad, so I believe that they should be reported as early on as possible. Previously the repository's low quality metadata was cited as a reason not to fail the build, but I would have thought such issues should have been rectified by now. Ideally we would throw a CyclicDependencyException in DefaultArtifactCollector. If this is deemed too invasive, then we should at least increase the log level in DebugResolutionListener to warning. -- 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-3431) Pom Extensions not supported for Toolchains
[ http://jira.codehaus.org/browse/MNG-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127114 ] Shane Isbell commented on MNG-3431: --- Using a scope of provided for my dotnet toolchain extension jar, solves the class cast exception (comment above). So everything works in 2.1. I'm just left with the original problem of getting the extension picked up for 2.0.9. Pom Extensions not supported for Toolchains --- Key: MNG-3431 URL: http://jira.codehaus.org/browse/MNG-3431 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Shane Isbell Priority: Minor When I add a pom extension referening a jar containing an implementation of a toolchain and toolchain factory, the toolchain plugin does not pick up my extensions. I get an exception on mvn install: Caused by: java.lang.ClassNotFoundException: org.apache.maven.dotnet.extensions.toolchain.DotnetToolchainFactory -- 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-1962) gwt-rolodex (a cool, tiny image browsing widget for gwt) up on public maven
gwt-rolodex (a cool, tiny image browsing widget for gwt) up on public maven --- Key: MAVENUPLOAD-1962 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1962 Project: maven-upload-requests Issue Type: Wish Reporter: Chris Jones Attachments: gwt-rolodex-1.1-bundle.jar As far as the domain goes, I work for yesmail. The best I can do in terms of proof is that I've put our demo applications for this widget on a yesmail site: http://devcenter.yesmail.com/com.yesmail.gwt.helpmoviedemo.RolodexDemoApp/RolodexDemoApp.html Yesmail has also signed a corporate CLA with google for contributions to gwt () I've also attached the bundle file for convenience Thanks! -- 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: (MAVENUPLOAD-1962) gwt-rolodex (a cool, tiny image browsing widget for gwt) up on public maven
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127128 ] Chris Jones commented on MAVENUPLOAD-1962: -- the following line in the description: Yesmail has also signed a corporate CLA with google for contributions to gwt () ...should read: Yesmail has also signed a corporate CLA with google for contributions to gwt (I'm listed on that CLA), but this widget isn't directly related to that since its released independently under the Apache 2.0 license. gwt-rolodex (a cool, tiny image browsing widget for gwt) up on public maven --- Key: MAVENUPLOAD-1962 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1962 Project: maven-upload-requests Issue Type: Wish Reporter: Chris Jones Attachments: gwt-rolodex-1.1-bundle.jar As far as the domain goes, I work for yesmail. The best I can do in terms of proof is that I've put our demo applications for this widget on a yesmail site: http://devcenter.yesmail.com/com.yesmail.gwt.helpmoviedemo.RolodexDemoApp/RolodexDemoApp.html Yesmail has also signed a corporate CLA with google for contributions to gwt () I've also attached the bundle file for convenience Thanks! -- 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: (MECLIPSE-399) URL for javadoc attachments on Unix is invalid
[
http://jira.codehaus.org/browse/MECLIPSE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MECLIPSE-399:
---
Attachment: javadoc-file-uri.patch
Extended patch to contain unit test.
URL for javadoc attachments on Unix is invalid
--
Key: MECLIPSE-399
URL: http://jira.codehaus.org/browse/MECLIPSE-399
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Unix, Eclipse 3.3
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: javadoc-file-uri.patch, javadoc-file-uri.patch
Currently, the plugin constructs the URL for the javadoc attachment via
{code:java}
jar:file:/ + javadocpath + !/
{code}
Now, consider a unix path like /home/me/.m2/snip.jar. This will produce
the URL jar:file://home/me/.m2/snip.jar!/. Note the double slash after
file: which will cause home to be parsed as a hostname instead of a
directory. This misinterpretation makes Eclipse fail to access the javadocs.
Acceptable URLs would either be jar:file:/home/... or
jar:file:///home/
The simple solution is to use
{{[java.io.File.toURI()|http://java.sun.com/javase/6/docs/api/java/io/File.html#toURI()]}}
for this job. This method will not only properly handle slashes but also
care for encoding of characters that may appear in filesystem paths but are
illegal in URLs (most prominently spaces).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3460) org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a different local repo
org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a
different local repo
---
Key: MNG-3460
URL: http://jira.codehaus.org/browse/MNG-3460
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.9
Reporter: Brian Fox
Fix For: 2.0.9
The test assumes you haven't changed your repo:
// Assume that junit exists
activationFile.setExists(
${user.home}/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3460) org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a different local repo
[
http://jira.codehaus.org/browse/MNG-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3460:
---
Assignee: Brian Fox
Fix Version/s: 2.0.9
org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a
different local repo
---
Key: MNG-3460
URL: http://jira.codehaus.org/browse/MNG-3460
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.9
Reporter: Brian Fox
Assignee: Brian Fox
Fix For: 2.0.9
The test assumes you haven't changed your repo:
// Assume that junit exists
activationFile.setExists(
${user.home}/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3460) org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a different local repo
[
http://jira.codehaus.org/browse/MNG-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3460.
--
Resolution: Fixed
org.apache.maven.profiles.DefaultProfileManagerTest fails if you use a
different local repo
---
Key: MNG-3460
URL: http://jira.codehaus.org/browse/MNG-3460
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.9
Reporter: Brian Fox
Assignee: Brian Fox
Fix For: 2.0.9
The test assumes you haven't changed your repo:
// Assume that junit exists
activationFile.setExists(
${user.home}/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-473) Documentation for additionalClassPath feature
Documentation for additionalClassPath feature - Key: SUREFIRE-473 URL: http://jira.codehaus.org/browse/SUREFIRE-473 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.2 Reporter: Pascal Lambert Priority: Minor Here is the example documentation for implemented feature additionalClasspath http://jira.codehaus.org/browse/SUREFIRE-118 -- 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: (SUREFIRE-473) Documentation for additionalClassPath feature
[ http://jira.codehaus.org/browse/SUREFIRE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Lambert updated SUREFIRE-473: Attachment: surefire-additional-classpath.patch Documentation for additionalClassPath feature - Key: SUREFIRE-473 URL: http://jira.codehaus.org/browse/SUREFIRE-473 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.2 Reporter: Pascal Lambert Priority: Minor Attachments: surefire-additional-classpath.patch Here is the example documentation for implemented feature additionalClasspath http://jira.codehaus.org/browse/SUREFIRE-118 -- 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: (MCHECKSTYLE-88) html report encoding inconsistent with french localized messages encoding
html report encoding inconsistent with french localized messages encoding - Key: MCHECKSTYLE-88 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-88 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.1 Environment: GNU/Linux, sun java 1.6, french localization, UTF-8 environment Reporter: Luc Maisonobe Priority: Minor When generating a report in a french/UTF-8 environment, the report title and section headers are translated into french with accented characters encoded in UTF-8. However, the html file uses ISO-8859-1 encoding due to this tag in the header: meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/meta This result in weid display. -- 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-270) Add support for classpathentry attributes
[ http://jira.codehaus.org/browse/MECLIPSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127137 ] Christian Hall commented on MECLIPSE-270: - Can someone outline what it would take to fix this issue? Is it something that someone new to the source code could create a patch for? This feature is pretty critical if components are dependent on externally compiled aspects in the maven repo. I know very little about the M2Eclipse support as well, but I would think in adding this feature it would be good to make sure it works for that aspect of the plug-in as well. I'd be happy to look into this if I can carve out some time, but I don't know what I am offering having not seen the code base. If there is some way for a newbie to help with this, let me know. Add support for classpathentry attributes - Key: MECLIPSE-270 URL: http://jira.codehaus.org/browse/MECLIPSE-270 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Components: AJDT support Affects Versions: 2.3 Reporter: Mike Youngstrom With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute nested inside of the .classpath file's classpathentry element Like so: classpathentry kind=var path=M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5.jar sourcepath=M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5-sources.jar attributes attribute name=org.eclipse.ajdt.aspectpath value=true/ /attributes /classpathentry It would be nice if it were possible to add attributes to classpathentry's with some kind of configuration syntax where maybe the dependency artifact and group are specified and then the attributes for that dependency. Mike -- 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: (MAVENUPLOAD-1958) a fix for jgroups 2.4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127140 ] pierre monestie commented on MAVENUPLOAD-1958: -- So according to the 'evangelism': We don't change dependencies in poms already in the repository anymore as builds need to be reproducible. Which means in this case the builds using Jgroups needs to be reproducibly broken?? I guess that's why I don't go to church anymore, I've never quite liked evangelism :) I proposed an easy fix, but oh well. I'm guessing no one is using that artifact. a fix for jgroups 2.4.1 --- Key: MAVENUPLOAD-1958 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1958 Project: maven-upload-requests Issue Type: Wish Reporter: pierre monestie Assignee: Carlos Sanchez Attachments: jgroups-all-2.4.1-bundle.jar I do not own this project however the maven repository for it is broken, as it refers to a non existing bsf. The attachement contains the correct pom.xml+jar for jgroups 2.4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1958) a fix for jgroups 2.4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127143 ] Carlos Sanchez commented on MAVENUPLOAD-1958: - I wouldnt be surprised if somebody before you added the missing dependency to their local repo and used jgroups, that's why ew are careful with changing them. And I'm giving you solutions, I dont see why the missing version cant be uploaded a fix for jgroups 2.4.1 --- Key: MAVENUPLOAD-1958 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1958 Project: maven-upload-requests Issue Type: Wish Reporter: pierre monestie Assignee: Carlos Sanchez Attachments: jgroups-all-2.4.1-bundle.jar I do not own this project however the maven repository for it is broken, as it refers to a non existing bsf. The attachement contains the correct pom.xml+jar for jgroups 2.4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-88) html report encoding inconsistent with french localized messages encoding
[ http://jira.codehaus.org/browse/MCHECKSTYLE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127145 ] Benjamin Bentmann commented on MCHECKSTYLE-88: -- Luc, you should also a) indicate your Maven version b) attach your POM or at least provide the config for the maven-site-plugin and its version c) attach a debug output of the report generation, e.g. mvn site -X Otherwise it's hard for people to track your problem down to the failing component. html report encoding inconsistent with french localized messages encoding - Key: MCHECKSTYLE-88 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-88 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.1 Environment: GNU/Linux, sun java 1.6, french localization, UTF-8 environment Reporter: Luc Maisonobe Priority: Minor When generating a report in a french/UTF-8 environment, the report title and section headers are translated into french with accented characters encoded in UTF-8. However, the html file uses ISO-8859-1 encoding due to this tag in the header: meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/meta This result in weid display. -- 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-1963) Mockito 1.2 upload request
Mockito 1.2 upload request -- Key: MAVENUPLOAD-1963 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1963 Project: maven-upload-requests Issue Type: Wish Reporter: Igor Czechowski http://mockito.googlecode.com/svn/branches/1.2/maven/mockito-all-1.2-bundle.jar http://code.google.com/p/mockito/ http://code.google.com/u/iczechowski/ I'm a project member in Mockito and want to use the org.mockito groupId You can see my name listed in Project members section at http://code.google.com/p/mockito/ and additionally at http://code.google.com/u/iczechowski/ The bundle has no external dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3461) Mirrors should not apply to file:// repositories
Mirrors should not apply to file:// repositories Key: MNG-3461 URL: http://jira.codehaus.org/browse/MNG-3461 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Brian Fox I ran into some issues recently with the IT tests. I use a mirrorof * to redirect everything to a repo manager but this is also redirecting the file based repositories. I can't think of any good reason this should apply to anything other than remote repos. I have two proposals: 1. Change maven so that file based repos ignore all mirror settings 2. Change maven so that file based repos ignore the wildcard but will respond if the mirror specifically names it. I can't think of any reason why a mirror should override a local repo so I suggest we go with #1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-297) Assembly broke on GNU/Linux - NullPointerException
[ http://jira.codehaus.org/browse/MASSEMBLY-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MASSEMBLY-297: Attachment: MASSEMBLY-297.zip I got the maven-assembly-plugin:2.2-beta-2 failing on the attached mini project even on a Windows box. It works if either - using 2.2-beta-1 or - disabling filtering for the fileset in question Robin, can it be that you use auto-update for the plugins and that your tries on Windows simply used a different version of the plugin than on Unix? Assembly broke on GNU/Linux - NullPointerException -- Key: MASSEMBLY-297 URL: http://jira.codehaus.org/browse/MASSEMBLY-297 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: $ mvn -version Maven version: 2.0.8 Java version: 1.5.0_15 OS name: linux version: 2.6.18-8.el5 arch: amd64 Family: unix Reporter: Robin Roos Attachments: buildlog.txt, MASSEMBLY-297.zip, unix.xml I have an assembly descriptor src/main/assembly/unix.xml which works on Windows but broke on Unix. When I commented out the following lines of the assembly descriptor then it worked on Unix: fileSet includes includeREADME*/include includeLICENSE*/include includeNOTICE*/include /includes filteredtrue/filtered /fileSet I have no README*, LICENSE* or NOTICE* files in my src tree. I have no filters defined in my pom.xml. The filteredtrue/filtered makes the assembly invoke filtering if the pom does define filters. With the above fileSet included in the fileSets element I get the following exception on assembly (on Unix only): (I had variously used lib and /lib as target directory when debugging this so ignore discrepencies in this regard) [INFO] Processing DependencySet (output=lib) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.io.File.lt;initgt;(File.java:194) at org.apache.maven.shared.model.fileset.util.FileSetManager.scan(FileSetManager.java:598) at org.apache.maven.shared.model.fileset.util.FileSetManager.getIncludedFiles(FileSetManager.java:186) at org.apache.maven.plugin.assembly.format.FileSetFormatter.formatFileSetForAssembly(FileSetFormatter.java:67) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.addFileSet(AddFileSetsTask.java:133) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.execute(AddFileSetsTask.java:87) at org.apache.maven.plugin.assembly.archive.phase.FileSetAssemblyPhase.execute(FileSetAssemblyPhase.java:54) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) 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: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: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]
[jira] Created: (MRRESOURCES-32) apache-jar-resource-bundle NOTICE file is not consistent with apache policy
apache-jar-resource-bundle NOTICE file is not consistent with apache policy --- Key: MRRESOURCES-32 URL: http://jira.codehaus.org/browse/MRRESOURCES-32 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-beta-2 Reporter: David Jencks Attachments: apache-jar-resource-bundle.diff Recent discussions on the apache legal-discuss list have made it extremely clear that the generated NOTICE file from the current (1.3) apache-jar-resource-bundle is not consistent with apache policy on contents of NOTICE files. After working hard to clarify what the policy might be I've come up with a bundle whose output has not produced any objections. We're using this currently in geronimo but would like to get this into a more global location for an imminent apacheds release. The main change is that the NOTICE file contains only the apache notice. You can append other notices using the appended-resources directory. This corresponds to the policy that the NOTICE file apply to exactly what is actually in the jar, not at all to any dependencies it may need to actually be used, and that the NOTICE file not have any excess verbiage such as horizontal rules or explanatory text. The dependencies are listed by license in an additional informative DEPENDENCIES file. There are a couple weird things that it would be great if someone could figure out: - I can't get a blank line between the project name and the notice in the NOTICE file - I can't figure out how to configure a projectName so it is used in the NOTICE file project name. -- 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: (MASSEMBLY-297) Assembly broke on GNU/Linux - NullPointerException
[ http://jira.codehaus.org/browse/MASSEMBLY-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MASSEMBLY-297: Affects Version/s: 2.2-beta-2 Assembly broke on GNU/Linux - NullPointerException -- Key: MASSEMBLY-297 URL: http://jira.codehaus.org/browse/MASSEMBLY-297 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: $ mvn -version Maven version: 2.0.8 Java version: 1.5.0_15 OS name: linux version: 2.6.18-8.el5 arch: amd64 Family: unix Reporter: Robin Roos Attachments: buildlog.txt, MASSEMBLY-297.zip, unix.xml I have an assembly descriptor src/main/assembly/unix.xml which works on Windows but broke on Unix. When I commented out the following lines of the assembly descriptor then it worked on Unix: fileSet includes includeREADME*/include includeLICENSE*/include includeNOTICE*/include /includes filteredtrue/filtered /fileSet I have no README*, LICENSE* or NOTICE* files in my src tree. I have no filters defined in my pom.xml. The filteredtrue/filtered makes the assembly invoke filtering if the pom does define filters. With the above fileSet included in the fileSets element I get the following exception on assembly (on Unix only): (I had variously used lib and /lib as target directory when debugging this so ignore discrepencies in this regard) [INFO] Processing DependencySet (output=lib) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.io.File.lt;initgt;(File.java:194) at org.apache.maven.shared.model.fileset.util.FileSetManager.scan(FileSetManager.java:598) at org.apache.maven.shared.model.fileset.util.FileSetManager.getIncludedFiles(FileSetManager.java:186) at org.apache.maven.plugin.assembly.format.FileSetFormatter.formatFileSetForAssembly(FileSetFormatter.java:67) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.addFileSet(AddFileSetsTask.java:133) at org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask.execute(AddFileSetsTask.java:87) at org.apache.maven.plugin.assembly.archive.phase.FileSetAssemblyPhase.execute(FileSetAssemblyPhase.java:54) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) 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: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: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: 9 seconds [INFO] Finished at: Thu Mar 13 12:42:17 GMT 2008 [INFO] Final Memory: 19M/470M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly
[jira] Commented: (MNG-3461) Mirrors should not apply to file:// repositories
[ http://jira.codehaus.org/browse/MNG-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127158 ] Carlos Sanchez commented on MNG-3461: - #2 if I explicitly want to mirror a file repo I should be able to Mirrors should not apply to file:// repositories Key: MNG-3461 URL: http://jira.codehaus.org/browse/MNG-3461 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Brian Fox I ran into some issues recently with the IT tests. I use a mirrorof * to redirect everything to a repo manager but this is also redirecting the file based repositories. I can't think of any good reason this should apply to anything other than remote repos. I have two proposals: 1. Change maven so that file based repos ignore all mirror settings 2. Change maven so that file based repos ignore the wildcard but will respond if the mirror specifically names it. I can't think of any reason why a mirror should override a local repo so I suggest we go with #1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-144) Fails archetype:create when specify archetypeVersion
[ http://jira.codehaus.org/browse/ARCHETYPE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127163 ] BABA,Yasuyuki commented on ARCHETYPE-144: - Thank you. Archetype generation succeed when I had the archetype artifact on my local repository. But, has no archetype artifact on my local repo, unable to download archetype artifact and fails generation. [EMAIL PROTECTED] ~]$ mvn archetype:generate -DarchetypeRepository=http://maven.seasar.org/maven2/ -DgroupId=com.example.foo -DartifactId=barapp -DarchetypeGroupId=org.seasar.cubby -DarchetypeArtifactId=cubby-archetype -DarchetypeVersion=1.0.1 -B [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:generate] (aggregator-style) [INFO] [INFO] Preparing archetype:generate [INFO] No goals needed for project - skipping Downloading: http://repo1.maven.org/maven2/com/example/foo/wagon-http-shared/1.0-beta-2/wagon-http-shared-1.0-beta-2.pom Downloading: http://repo1.maven.org/maven2/com/example/foo/wagon-http-shared/1.0-beta-2/wagon-http-shared-1.0-beta-2.pom [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [archetype:generate] [INFO] Archetype defined by properties org.apache.maven.archetype.downloader.DownloadNotFoundException: Requested download does not exist. at org.apache.maven.archetype.downloader.DefaultDownloader.download(DefaultDownloader.java:62) at org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.exists(DefaultArchetypeArtifactManager.java:310) at org.apache.maven.archetype.ui.DefaultArchetypeGenerationConfigurator.configureArchetype(DefaultArchetypeGenerationConfigurator.java:103) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:168) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) 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: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.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.seasar.cubby -DartifactId=cubby-archetype -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.seasar.cubby -DartifactId=cubby-archetype -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.seasar.cubby:cubby-archetype:jar:1.0.1 at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveAlways(DefaultArtifactResolver.java:79) at org.apache.maven.archetype.downloader.DefaultDownloader.download(DefaultDownloader.java:54) ... 21
[jira] Commented: (MNG-3461) Mirrors should not apply to file:// repositories
[ http://jira.codehaus.org/browse/MNG-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127165 ] Brian Fox commented on MNG-3461: I guess I can live with that. The reason I was thinking of still skipping the file ones is that you may have a name conflict and you didn't mean the one with the file, but the one with the http. Mirrors should not apply to file:// repositories Key: MNG-3461 URL: http://jira.codehaus.org/browse/MNG-3461 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Brian Fox I ran into some issues recently with the IT tests. I use a mirrorof * to redirect everything to a repo manager but this is also redirecting the file based repositories. I can't think of any good reason this should apply to anything other than remote repos. I have two proposals: 1. Change maven so that file based repos ignore all mirror settings 2. Change maven so that file based repos ignore the wildcard but will respond if the mirror specifically names it. I can't think of any reason why a mirror should override a local repo so I suggest we go with #1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MNG-3284: This is still causing problems. See the IT output here: https://ci.sonatype.org/job/Maven-2.0.x-freestyle/18/console Cached plugins are used, even when the specifically declared - Key: MNG-3284 URL: http://jira.codehaus.org/browse/MNG-3284 Project: Maven 2 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: Nigel Magnay Assignee: John Casey Priority: Critical Fix For: 2.0.9 Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar In the attached project, you can build module A, then build module B, but the top level aggregator project will fail at B. The reason this happens is that maven seems to cache plugins. When B is built in isolation, all things are fine - but when built in aggregation, one of the plugins that it uses has already been instantiated, and so it uses that one. This is incorrect, since the declared version is different in B, and is relying on functionality not present in the version declared in A. I have seen similar behaviour when a plugin relies on other plugins to get work done - all of a sudden a build mysteriously stops working, because of a completely unrelated plugin. This is pretty painful because - it's possible to get into a 'no solution', where one project relies on one behaviour so can't upgrade, and one project relies on new behaviour, so can't downgrade. - you get builds that work OK in isolation, but not in their project. This is bad. Also builds tied together in bigger aggregator projects can fail in mysterious ways (mysterious because the user /has/ specified the plugin version, and maven has ignored them, or it's a plugin dependency that got there first) - subtle build ordering changes can cause new failures (the example has B depend on A - but the bug might only manifest itself in certain build orders that change even when B and A don't). -- 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-399) URL for javadoc attachments on Unix is invalid
[
http://jira.codehaus.org/browse/MECLIPSE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-399.
Resolution: Fixed
URL for javadoc attachments on Unix is invalid
--
Key: MECLIPSE-399
URL: http://jira.codehaus.org/browse/MECLIPSE-399
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Unix, Eclipse 3.3
Reporter: Benjamin Bentmann
Assignee: Arnaud Heritier
Priority: Minor
Attachments: javadoc-file-uri.patch, javadoc-file-uri.patch
Currently, the plugin constructs the URL for the javadoc attachment via
{code:java}
jar:file:/ + javadocpath + !/
{code}
Now, consider a unix path like /home/me/.m2/snip.jar. This will produce
the URL jar:file://home/me/.m2/snip.jar!/. Note the double slash after
file: which will cause home to be parsed as a hostname instead of a
directory. This misinterpretation makes Eclipse fail to access the javadocs.
Acceptable URLs would either be jar:file:/home/... or
jar:file:///home/
The simple solution is to use
{{[java.io.File.toURI()|http://java.sun.com/javase/6/docs/api/java/io/File.html#toURI()]}}
for this job. This method will not only properly handle slashes but also
care for encoding of characters that may appear in filesystem paths but are
illegal in URLs (most prominently spaces).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-298) Includes/Excludes within unpackOptions are ignored
Includes/Excludes within unpackOptions are ignored Key: MASSEMBLY-298 URL: http://jira.codehaus.org/browse/MASSEMBLY-298 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Maven 2.0.8, Intel Mac 10.5, JDK 5.0 Reporter: Nathaniel Harward Attachments: module-set-assembly-phase.patch I have the following snippet in my assembly descriptor which does not work: --snip-- moduleSet includes includemy:module/include /includes binaries unpacktrue/unpack unpackOptions excludes excludeMETA-INF/**/exclude exclude**/.do_not_remove/exclude /excludes /unpackOptions outputFileNameMapping/ outputDirectory//outputDirectory fileMode644/fileMode directoryMode755/directoryMode /binaries /moduleSet --snip-- Debug output shows: --snip-- [DEBUG] includes: **/* [DEBUG] excludes: none --snip-- I believe the problem is at line 271/272 of ModuleSetAssemblyPhase (in the 2.2-beta-2 revision, anyway) -- it calls task.setUnpack( binaries.isUnpack() ); but does not set the unpack options (if present), hence they are ignored :( Patch is attached, and works just fine in my case above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3462) Settings: Proceeding slash should be removed from URLs
Settings: Proceeding slash should be removed from URLs -- Key: MNG-3462 URL: http://jira.codehaus.org/browse/MNG-3462 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build, Settings Affects Versions: 2.0.8 Reporter: Paul Benedict Priority: Minor When repositories and mirrors have their URL end with a slash, you will see a double-slash in the URL. Example configuration: mirrors mirror idmergere/id mirrorOfcentral/mirrorOf nameMergere/name urlhttp://repo.mergere.com/maven2//url /mirror /mirrors Output: mvn help:effective-pom Downloading: http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.pom 1K downloaded Downloading: http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.jar 19K downloaded -- 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: (MENFORCER-39) Allow simplified range checking
Allow simplified range checking --- Key: MENFORCER-39 URL: http://jira.codehaus.org/browse/MENFORCER-39 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-alpha-3, 1.0 Reporter: Paul Benedict Assignee: Brian Fox Priority: Minor The rule [1.0.0,) means at least 1.0.0 inclusive and anything greater. The comma should be optional for single-value ranges. It can be inferred simply from the brackets and braces what the intention is. So [1.0.0) should also be a valid version range. -- 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
