[jira] Commented: (MRM-688) Replace plexus-runtime with standalone jetty bundle
[ http://jira.codehaus.org/browse/MRM-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125999 ] Maria Odea Ching commented on MRM-688: -- Changes made in -r633367: -added config for mail session and archiva & users db in jetty.xml -unpack webapp during packaging so that it would be run during startup > Replace plexus-runtime with standalone jetty bundle > --- > > Key: MRM-688 > URL: http://jira.codehaus.org/browse/MRM-688 > Project: Archiva > Issue Type: Task > Components: build >Affects Versions: 1.0, 1.0.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.1 > > > http://www.nabble.com/Re%3A-Archiva-1.1-Roadmap-p15331690.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: (MRM-727) Archiva does not download plugin artifacts
Archiva does not download plugin artifacts -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Attachments: settings-wrong.xml When i have an initially blank local maven repo and for example start maven with "mvn clean", no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. >From trial and error I found out, that any request to a plugin related >maven-metadata.xml file will fail. If I try the same for a "normal" artifact >maven-metadata.xml (like the one for commons-lang) then archiva downloads the >correct file. -- 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-721) ConsumerException when scanning database
[ http://jira.codehaus.org/browse/MRM-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-721: - Fix Version/s: 1.0.x > ConsumerException when scanning database > > > Key: MRM-721 > URL: http://jira.codehaus.org/browse/MRM-721 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1, 1.0.2 >Reporter: james ahlborn > Fix For: 1.0.x > > > I'm running the 1.0.2 branch, version 632005. I got a bunch of similar > consumerexceptions when i tried to scan the database. however, i only got > them the first time (after upgrading from a previous version of the code on > the 1.0.2 branch), now scans seem to be proceeding without problem. an > example exception is included below. > org.apache.maven.archiva.consumers.ConsumerException: Unable to find > Database Object [org.apache.maven:maven-profile:2.0.7] of type > org.apache.maven.archiva.model.ArchivaProjectModel using no fetch-group > at > org.apache.maven.archiva.consumers.database.DatabaseCleanupRemoveProjectConsumer.processArchivaArtifact(DatabaseCleanupRemoveProjectConsumer.java:119) > at > org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:52) > at > org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:172) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:113) > at > org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:78) > 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$Worker.runTask(ThreadPoolExecutor.java:665) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:595) -- 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-726) snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
[
http://jira.codehaus.org/browse/MRM-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125967
]
james ahlborn commented on MRM-726:
---
I'm not sure if this problem is related to this exception I'm getting in the
logs:
archiva.log.2008-03-01:46980222 [pool-1-thread-1] WARN
org.apache.maven.archiva.consumers.DatabaseUnprocessedArtifactConsumer:update-db-project
- File hmsCommon-jwrap-20070308.050344.pom has an invalid project model
[groupId:null|artifactId:null|version:1.0.3|packaging:null]: The model
artifactId [null] does not match the artifactId portion of the filename:
hmsCommon-jwrap
> snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
> --
>
> Key: MRM-726
> URL: http://jira.codehaus.org/browse/MRM-726
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0.1, 1.0.2
>Reporter: james ahlborn
>Priority: Minor
>
> we have artifacts in our maven1 repository which are fairly old (one of the
> reasons we wanted to use archiva, to clean up the crud!). however, it
> appears that some of the snapshots are not being cleaned up. my guess is
> that it is due to an unrecognized timestamp format:
> For an artifact with artifactId "hmsCommon-jwrap", we have snapshots which
> look like:
> hmsCommon-jwrap-20070308.050344.jar
> // unit test
> public void testLegacyVersion() {
> assertTrue(VersionUtil.isSnapshot("20070308.050344"));
> }
--
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-726) snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
--
Key: MRM-726
URL: http://jira.codehaus.org/browse/MRM-726
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0.1, 1.0.2
Reporter: james ahlborn
Priority: Minor
we have artifacts in our maven1 repository which are fairly old (one of the
reasons we wanted to use archiva, to clean up the crud!). however, it appears
that some of the snapshots are not being cleaned up. my guess is that it is
due to an unrecognized timestamp format:
For an artifact with artifactId "hmsCommon-jwrap", we have snapshots which look
like:
hmsCommon-jwrap-20070308.050344.jar
// unit test
public void testLegacyVersion() {
assertTrue(VersionUtil.isSnapshot("20070308.050344"));
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-721) ConsumerException when scanning database
[ http://jira.codehaus.org/browse/MRM-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125958 ] jahlborn edited comment on MRM-721 at 3/3/08 1:53 PM: --- So, I wiped my database and rebuilt from scratch. This error is still appearing periodically. was (Author: jahlborn): Well, i wiped out my database and started a fresh scan. I have not seen this exception again, so maybe it was just some whacky state that accumulated from previous issues which have since been resolved. > ConsumerException when scanning database > > > Key: MRM-721 > URL: http://jira.codehaus.org/browse/MRM-721 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1, 1.0.2 >Reporter: james ahlborn > > I'm running the 1.0.2 branch, version 632005. I got a bunch of similar > consumerexceptions when i tried to scan the database. however, i only got > them the first time (after upgrading from a previous version of the code on > the 1.0.2 branch), now scans seem to be proceeding without problem. an > example exception is included below. > org.apache.maven.archiva.consumers.ConsumerException: Unable to find > Database Object [org.apache.maven:maven-profile:2.0.7] of type > org.apache.maven.archiva.model.ArchivaProjectModel using no fetch-group > at > org.apache.maven.archiva.consumers.database.DatabaseCleanupRemoveProjectConsumer.processArchivaArtifact(DatabaseCleanupRemoveProjectConsumer.java:119) > at > org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:52) > at > org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:172) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:113) > at > org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:78) > 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$Worker.runTask(ThreadPoolExecutor.java:665) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:595) -- 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-721) ConsumerException when scanning database
[ http://jira.codehaus.org/browse/MRM-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125958 ] james ahlborn commented on MRM-721: --- Well, i wiped out my database and started a fresh scan. I have not seen this exception again, so maybe it was just some whacky state that accumulated from previous issues which have since been resolved. > ConsumerException when scanning database > > > Key: MRM-721 > URL: http://jira.codehaus.org/browse/MRM-721 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1, 1.0.2 >Reporter: james ahlborn > > I'm running the 1.0.2 branch, version 632005. I got a bunch of similar > consumerexceptions when i tried to scan the database. however, i only got > them the first time (after upgrading from a previous version of the code on > the 1.0.2 branch), now scans seem to be proceeding without problem. an > example exception is included below. > org.apache.maven.archiva.consumers.ConsumerException: Unable to find > Database Object [org.apache.maven:maven-profile:2.0.7] of type > org.apache.maven.archiva.model.ArchivaProjectModel using no fetch-group > at > org.apache.maven.archiva.consumers.database.DatabaseCleanupRemoveProjectConsumer.processArchivaArtifact(DatabaseCleanupRemoveProjectConsumer.java:119) > at > org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:52) > at > org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:172) > at > org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:113) > at > org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:78) > 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$Worker.runTask(ThreadPoolExecutor.java:665) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:595) -- 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-725) /archiva/browse URL does not work on WebSphere
[
http://jira.codehaus.org/browse/MRM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steffen Grunwald updated MRM-725:
-
Attachment: MRM-725.patch
Suggested patch considers pathInfo, if servletPath is empty string
> /archiva/browse URL does not work on WebSphere
> --
>
> Key: MRM-725
> URL: http://jira.codehaus.org/browse/MRM-725
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0.1
> Environment: WebSphere 6.1
>Reporter: Steffen Grunwald
> Attachments: MRM-725.patch
>
>
> The browse URL is not recognized, since the RepositoryActionMapper uses the
> ServletPath to determine the "browse" prefix in the path.
> The JEE 5 spec specifies [1]:
> "This method will return an empty string ("") if the servlet used to process
> this request was matched using the "/*" pattern."
> If your appserver works as described the "browse" in the URL can only be
> determined by using getPathInfo().
> [1]
> http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getServletPath()
--
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-725) /archiva/browse URL does not work on WebSphere
/archiva/browse URL does not work on WebSphere
--
Key: MRM-725
URL: http://jira.codehaus.org/browse/MRM-725
Project: Archiva
Issue Type: Bug
Components: web application
Affects Versions: 1.0.1
Environment: WebSphere 6.1
Reporter: Steffen Grunwald
The browse URL is not recognized, since the RepositoryActionMapper uses the
ServletPath to determine the "browse" prefix in the path.
The JEE 5 spec specifies [1]:
"This method will return an empty string ("") if the servlet used to process
this request was matched using the "/*" pattern."
If your appserver works as described the "browse" in the URL can only be
determined by using getPathInfo().
[1]
http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getServletPath()
--
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
