Cannot configure Legacy Artifact Path Resolution of Non-standard path
Hi guys, I'm having troubles configuring legacy artifact path for maven-jaxb-plugin. Artifact is located here: http://download.java.net/maven/1/com.sun.tools.xjc.maven2/maven-plugins/ I believe, the M1 standard is to rather put maven plugins inside the plugins directory instead of maven-plugins. Anyway, I tried configuring it via admin: Path: com.sun.tools.xjc.maven2/maven-plugins/maven-jaxb-plugin-1.1.jar GroupId: com.sun.tools.xjc.maven2 ArtifactId: maven-jaxb-plugin Version: 1.1 Classifier: Type: maven-plugin And get this on submit: artifact reference does not match the initial path : com.sun.tools.xjc.maven2/plugins/maven-jaxb-plugin-1.1.jar Also, the auto complete feature does not correctly slice the input initially: ArtifactId: maven Version: jaxb-plugin-1.1 I just manually deployed to archiva instead using the pom and the jar file from this repo. Thanx! regards, mykol
Re: Cannot configure Legacy Artifact Path Resolution of Non-standard path
hi nicolas, here you go: http://jira.codehaus.org/browse/MRM-768 On Tue, Apr 8, 2008 at 3:37 PM, nicolas de loof [EMAIL PROTECTED] wrote: legacy artifact path configuration is a way for archiva to support maven1 clients (maven1 request URL is not fine-grained enough to safelly detect the artifactId / version / classifier). When you want to acces a legacy-layout repository using a proxy connector, you don't need to configure anything. Your issue is that archiva search the expected artifact in /plugins/ and not in /maven-plugins/ In archiva source code ( AbstractLegacyRepositoryContent.java ) I can read : typeToDirectoryMap.put( ArtifactExtensionMapping.MAVEN_PLUGIN, plugin ); BUT when deploying a project to a legacy repo, the maven ArtifactHandler (in maven-artifact.jar) set : roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintmaven-plugin/role-hint configuration typemaven-plugin/type extensionjar/extension IMHO, archiva tries to use the same type for two incompatible artifacts : maven1 plugins and maven2 ones. As requesting a maven2 plugin from a maven1 repository is really not a common use case, this may not have been discovered yet. Please open an Issue for this. Nicolas. 2008/4/8, Michael Mallete [EMAIL PROTECTED]: Hi guys, I'm having troubles configuring legacy artifact path for maven-jaxb-plugin. Artifact is located here: http://download.java.net/maven/1/com.sun.tools.xjc.maven2/maven-plugins/ I believe, the M1 standard is to rather put maven plugins inside the plugins directory instead of maven-plugins. Anyway, I tried configuring it via admin: Path: com.sun.tools.xjc.maven2/maven-plugins/maven-jaxb-plugin-1.1.jar GroupId: com.sun.tools.xjc.maven2 ArtifactId: maven-jaxb-plugin Version: 1.1 Classifier: Type: maven-plugin And get this on submit: artifact reference does not match the initial path : com.sun.tools.xjc.maven2/plugins/maven-jaxb-plugin-1.1.jar Also, the auto complete feature does not correctly slice the input initially: ArtifactId: maven Version: jaxb-plugin-1.1 I just manually deployed to archiva instead using the pom and the jar file from this repo. Thanx! regards, mykol
Re: timeouts configuration
the feature is present in trunk and will be released with Archiva 1.1. On 09/04/2008, aldana [EMAIL PROTECTED] wrote: hi, currently proxy repository of http://repository.codehaus.org/ had been very slow in respondance. this made archiva hang (see log below). after removing this repository as proxy connector everything worked fine again. instead of deleting this another setting would be nice, so if there are download problems or a certain timeout has been reached, respective proxy connector should be ignored for a certain time gap. 1150450336 [Thread-5] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:database-update - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.NullPointerException at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:56) at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:170) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:111) 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:619) - manuel aldana aldana((at))gmx.de homepage: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/timeouts-configuration-tp16558750p16558750.html Sent from the archiva-users mailing list archive at Nabble.com. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Archiva purge
Hi Brett, it is not docuented, but you need to restart archiva. Thanks for teh hint. Stefano yes, it should. Do you see a block summary in the logs that says the repository was scanned? If so, was the purge consumer listed? On 05/04/2008, Stefano Fornari [EMAIL PROTECTED] wrote: Hi All, I am using archiva 1.0.1 and I would like to use the purge functionality to purge the snapshots older than 10 days. I had configured the repository already some time ago, but I just recently realized I have to enable the repository-purge consumer. So I did it a week ago. Should this change take place and apply immediately from the next scan? looking into the repository there are still snapshots older than 10 days... Any hint is appreciated. Thanks in advance. stefano -- Stefano Fornari - Funambol CTO === Home: http://www.funambol.org Documents: http://www.funambol.org/documentation/documents.html FAQ: http://www.funambol.org/support/faq.html WIKI: https://wiki.objectweb.org/sync4j/ Mailinglist archives: http://groups.yahoo.com/group/Sync4j (login required) http://sourceforge.net/mailarchive/forum.php?forum_id=215 (sync4j-users) http://sourceforge.net/mailarchive/forum.php?forum_id=48877 (funambol-dev)
Re: metadata -updater does not appear to be working!
Hi Jason, Can you file this as a request? I think at present the updater corrects the versions flag, but not the snapshot information (it also doesn't correct the plugin group metadata). - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact. -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
I will file it today. Is there any chance of getting it into a 1.0.2 release? I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:36 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Hi Jason, Can you file this as a request? I think at present the updater corrects the versions flag, but not the snapshot information (it also doesn't correct the plugin group metadata). - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: metadata -updater does not appear to be working!
On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base/archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven/archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426view=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: metadata -updater does not appear to be working!
Ah, sorry I wasn't clear. I was referring to the timestamp on the filesystem - if you touch the JAR you listed and scan again, is the metadata updated? Likewise, does adding a new build instead of removing work? - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
If the metadata has been updated, then the deploy works fine and the metadata in updated correctly. If the metadata has not been update, the deploy still works fine, but the build numbers get off and there will be missing builds in the repo. I am not sure of other scenarios. We have not encountered any. Deleting files and fixing metatdata files has been a problem for us for awhile and we have had to do it manually in the past, so that it is why it is nice to have this feature in Archiva. However, I would like to see it correct the metatdata file without needing to touch any files after deleting files. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:34 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: 1) touching the old jar, seems to work. ok, I'll add that info to the bug 2) I add new builds with maven and not Archiva, and it will increment from the last build number so the next build will not be 4, it will be 6. If, the metatdata file isn't updated first. right - but if the metadata is up to date, then there's no problem? That is, are there scenarios other than deleting builds where the metadata is not updated? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:08 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Ah, sorry I wasn't clear. I was referring to the timestamp on the filesystem - if you touch the JAR you listed and scan again, is the metadata updated? Likewise, does adding a new build instead of removing work? - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Unable to build archiva trunk
Hi, just tried to build archiva 1.0.2-SNAPSHOT and getting following error: [INFO] Building Archiva Base :: Common [INFO]task-segment: [compile] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-plugins/2-SNAPSHOT/maven-plugins-2-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 Reason: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 for project null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 saying the artifact for maven-plugins:2-SNAPSHOT ist not available, so far so good. But if You have a clooser look this artifact is referenced by maven-resources-plugin:2.3-20060725.131549-1, mmmhhh build date 2006xxx. Ok, lets have a look in http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-resources-plugin/2.3-SNAPSHOT/ and voila there is a newer version, but it isn't referenced from the maven-metadata.xml file. And maven gets this very old snapshot version referencing maven-plugins:2-SNAPSHOT. Could someone correct this metadata, please? Roland
Re: Unable to build archiva trunk
fixed On 09/04/2008, Roland Klein [EMAIL PROTECTED] wrote: Hi, just tried to build archiva 1.0.2-SNAPSHOT and getting following error: [INFO] Building Archiva Base :: Common [INFO]task-segment: [compile] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-plugins/2-SNAPSHOT/maven-plugins-2-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 Reason: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 for project null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 saying the artifact for maven-plugins:2-SNAPSHOT ist not available, so far so good. But if You have a clooser look this artifact is referenced by maven-resources-plugin:2.3-20060725.131549-1, mmmhhh build date 2006xxx. Ok, lets have a look in http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-resources-plugin/2.3-SNAPSHOT/ and voila there is a newer version, but it isn't referenced from the maven-metadata.xml file. And maven gets this very old snapshot version referencing maven-plugins:2-SNAPSHOT. Could someone correct this metadata, please? Roland -- Brett Porter Blog: http://blogs.exist.com/bporter/
[ANNOUNCE] Apache Archiva 1.0.2 Released
The Apache Archiva team is pleased to announce the release of Archiva 1.0.2 Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It has features like repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. Aside from these, it can also act as a nearby (proxy) cache of popular global repositories. The latest release is now available here: http://maven.apache.org/archiva/download.html If you have any questions, please consult: - the web site: http://maven.apache.org/archiva/ - the archiva-user mailing list: http://maven.apache.org/archiva/mail-lists.html New in Archiva 1.0.2 * Configurable Proxy Error Handling Two new options have been added to the proxy connector configuration page: - On remote error - gives control over whether to stop immediately, continue to try for a successful proxy, or ignore an error - Return error when - gives control over whether to return an existing artifact if present or fail regardless if a remote error occurs when updating an artifact Change Log for Archiva 1.0.2 === * [MRM-159] - should not respond with a 404 if proxying a file results in a remote error * [MRM-532] - Unable to specify the location of the index files through the web ui * [MRM-598] - Validation error on new repository creation and other fields under certain conditions * [MRM-608] - Unable to find project model for [...] if the initial import of the POM failed * [MRM-617] - Reporting does not work due to bug in client-side JavaScript validation * [MRM-618] - PLEXUS_BASE does not work for local databases * [MRM-622] - database not being updated with project model information * [MRM-626] - ClassCastException when saving proxy connector with property defined * [MRM-627] - Archiva doesn't download SNAPSHOTs for proxied repositories. * [MRM-642] - archiva-common tests rely on relative paths * [MRM-655] - The logs are duplicated in the archiva.log and wrapper.log file. * [MRM-659] - archiva cannot serve ejb artifacts from a maven1 repository * [MRM-661] - remote repository removals are not saved after restart * [MRM-664] - Cannot download a strut-module artifact in a Legacy repository * [MRM-674] - LayoutException when downloading SNAPSHOT test-sources * [MRM-683] - Archiva version missing from pages and logs * [MRM-687] - Project model cannot be added to database if it inherits groupId and/or version from parent POM * [MRM-689] - Incorrect war name in example for tomcat * [MRM-690] - using undefined appserver.base * [MRM-691] - Can't get any of the consumers to work without through a NPE * [MRM-701] - Buggy documentation on separating the base from the installation * [MRM-703] - Artifacts with extensions longer than fours characters breaks repository scanning. * [MRM-713] - extensionPattern in FilenameParser is incorrect * [MRM-715] - error adding artifacts to Lucene under some circumstances * [MRM-719] - NPE during repository scan * [MRM-725] - /archiva/browse URL does not work on WebSphere * [MRM-727] - Archiva does not download plugin artifacts in Geronimo * [MRM-734] - Unable to update metadata - No versions found for reference * [MRM-746] - unable to include *.xml in artifacts list as it picks up maven-metadata.xml * [MRM-750] - Adding a network proxy doesn't require an identifier * [MRM-755] - No content type for .pom files denoted in file archiva-mime-types.txt - workaround included * [MRM-758] - unable to schedule cron expressions that contain a comma * [MRM-761] - Exception when trying to retrieve a Maven 1 artifact of type zip * [MRM-762] - Footer doesn't stretch across repositoryScanning and database pages * [MRM-763] - Default cron expression for database update is invalid * [MRM-764] - default policies are not selected in the add proxy connector page * [MRM-504] - Find Artifact page needs more onscreen information/ instructions * [MRM-656] - Admin guide for installing WAR needs updating * [MRM-666] - Edit Managed Repository page should indicate the repo id being edited * [MRM-700] - Review the documentation on deploying to Archiva for inconsistent repository ids * [MRM-720] - Upgrade Lucene from 2.0 to 2.3.1 Thanks, The Apache Archiva team
