Re: mvn eclipse:eclipse Cache not downloadable sources in Archiva?
failure caching is only enabled for 404's in Archiva 1.1. The best thing to do would be to add **/*-sources.jar to the black list on the proxy connector so it never attempts to get any remotely. - Brett On 21/04/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I´m using Archiva 1.0.2. When calling mvn eclipse:eclipse on a multimodule project, Archiva is always trying to download sources, which tooks a long time for checking, as for example: [INFO] Using source status cache: S:\pdv_cms\GDCAMS\src\target\mvn-eclipse-cache.properties Downloading: http://cams-build2.intern:8080/archiva/repository/internal//org/springframework/spring-core/2.0.2/spring-core-2.0.2-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/3rdParty//org/springframework/spring-core/2.0.2/spring-core-2.0.2-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/internal/org/springframework/spring-core/2.0.2/spring-core-2.0.2-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/internal//avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/3rdParty//avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/internal/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/internal//org/springframework/spring-beans/2.0.2/spring-beans-2.0.2-sources.jar Downloading: http://cams-build2.intern:8080/archiva/repository/3rdParty//org/springframework/spring-beans/2.0.2/spring-beans-2.0.2-sources.jar I configured Archiva to cacheFailure at each proxy-connector - but that doesn´t work. How can I speed up the call of mvn eclipse:eclipse? Is there any configuration available to cache the information about not available sources.jars ? Thanx, Torsten -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: repository stylesheet
I don't believe there's any easy way to do this right now, but we do serve the pages so it could be done. I think it'd be an interesting feature and we'd be happy to help point you in the right direction to help implement it! You might be interested to join [EMAIL PROTECTED] Thanks, Brett On 17/04/2008, Lustig, Marc (Allianz Deutschland AG) [EMAIL PROTECTED] wrote: Actually what I mean is to have such stylish page like when using the Archiva Bowse function. so HOST/archiva/repository/internal/ant/ant-launcher/1.6.5/ should show the same as HOST/archiva/browse/ant/ant-launcher/1.6.5 except the surrounding stuff (menu on the left, top header, footer) Is there a documented way to realize this? If not, is this a feature that the Archiva-team would support? I would be willing to spend time to realize it. -Ursprüngliche Nachricht- Von: Lustig, Marc (Allianz Deutschland AG) Gesendet: Donnerstag, 17. April 2008 13:59 An: archiva-users@maven.apache.org Betreff: repository stylesheet It is possoble to browse the repo using Archiva. However it doesn't look quite stylish. Is there any documented way how to add some theme or template in order to display the repo-files in a better readable and more stylish way? -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: application url context change is it possible
It should be apps/archiva/conf/application.xml, change context/ On 16/04/2008, Paul G [EMAIL PROTECTED] wrote: Running in stand alone mode is it possible to change the context root of the Archiva application. Currently it is set to archiva I would like to set it to repomanager. Any hint's on which config file controls this? -- View this message in context: http://www.nabble.com/application-url-context-change-is-it-possible-tp16719758p16719758.html Sent from the archiva-users mailing list archive at Nabble.com. -- Brett Porter Blog: http://blogs.exist.com/bporter/
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: 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!
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: 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
Re: Proxy connectors fails to download, Archiva needs restart
This was reported by others against 1.0.1, and they've been unable to reproduce with 1.0.2. That release is currently being voted on - you can test it out from here: http://people.apache.org/builds/maven/archiva/1.0.2/ - Brett On 04/04/2008, Jackson, Brian R [EMAIL PROTECTED] wrote: I sniffed the traffic and it's attempting to connect through the network proxy I've setup for some of my other Proxy Connectors. I've double-checked that the Proxy Connector for wdig.releases, the remote repo that is failing, is configured to (direct connection). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] .org] On Behalf Of Jackson, Brian R Sent: Thursday, April 03, 2008 11:36 AM To: archiva-users@maven.apache.org Subject: RE: Proxy connectors fails to download, Archiva needs restart I spoke with Joe, the owner of the remote repository, and we tested it. Apparently the request is not getting to the remote repository as the archiva.log, audit.log and wrapper.log on that server showed no activity at all while mine reports the exception caused by the 500 error. I will now follow up with our MIS and operations team to trace the request as see where it is being blocked. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] .org] On Behalf Of Brett Porter Sent: Thursday, April 03, 2008 9:52 AM To: archiva-users@maven.apache.org Subject: Re: Proxy connectors fails to download, Archiva needs restart On 04/04/2008, Jackson, Brian R [EMAIL PROTECTED] wrote: Why would restarting MY instance of Archiva temporarily fix this issue though? I'll get more information from the remote side when the owner is available. Good point - sorry I forgot that. Let's see what they have to say - though others have also reported this so perhaps there is something else going on here. Thanks, Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Archiva not generating maven-metadata for available revisions
On 03/04/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I was reproducing this consistently, then I restarted Tomcat and I can't get it to reproduce at all anymore. There must have been something problematic cached in memory. Does that mean the metadata is generating properly now? Is there anything else that needs to be fixed? - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Deploy artifact to archiva for the first time - error
Do you get any errors in the Archiva logs? I certainly get 40x errors from Maven when deploying to Archiva using the DAV wagon - what version of the wagon are you using? Can you try using just http:// instead of dav:http:// ? Thanks, Brett On 28/03/2008, Paul G [EMAIL PROTECTED] wrote: Brett, I have tried adding a user with repository observer and manager roles and have also tried giving the guest user the repository manager role as well. But still it does not work. I have even tried putting a wrong password/wrong user name in my settings.xml to see what sort of error I get back, but I still got the same error. I even tried to deploy the snapshot to the realse only repo and I still got the same error. Now I'm really confused, must admit I got artifactory working quicker that this! Below is my user set up in settings.xml server idarchiva.team.snapshot/id usernamedeployer/username passwordpassword1234/password /server Brett Porter wrote: I think this is a result of not having permissions to write that file on the server On 28/03/2008, Paul G [EMAIL PROTECTED] wrote: I have just set Archiva as per the docs my build works fine all the artifacts are downloaded within Archiva. But when I come to deploy to a newly created repository managed by Archiva using web dav I get the following error [INFO] Error deploying artifact: Resource to deploy not found: File: http://localhost:8800/archiva/repository/team_snapshot/psg/scratch/beanUtils/BeanUtilsEx/0.0.1-SNAPSHOT/BeanUtilsEx-0.0.1-20080327.223426-1.jar does not exist This is my pom file distributionManagement repository idarchiva.team.release/id nameInternal Release Repository/name url dav:http://localhost:8800/archiva/repository/team_release/ /url /repository snapshotRepository idarchiva.team.snapshot/id nameInternal Snapshot Repository/name url dav:http://localhost:8800/archiva/repository/team_snapshot/ /url /snapshotRepository /distributionManagement Why is webdav complaining the artifact is not found, surely it is not there as it is the first time I have deployed? Help I'm confused. Below is the full stack trace when running in debug. [INFO] Error deploying artifact: Resource to deploy not found: File: http://loca lhost:8800/archiva/repository/team_snapshot/psg/scratch/beanUtils/BeanUtilsEx/0. 0.1-SNAPSHOT/BeanUtilsEx-0.0.1-20080327.224101-1.jar does not exist [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact : Resource to deploy not found: File: http://localhost:8800/archiva/repository/t eam_snapshot/psg/scratch/beanUtils/BeanUtilsEx/0.0.1-SNAPSHOT/BeanUtilsEx-0.0.1- 20080327.224101-1.jar does not exist at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.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(DelegatingMethodAcces sorImpl.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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error
Re: archiva / internal / snapshot and settings.xml
On 24/03/2008, Jan Nielsen [EMAIL PROTECTED] wrote: Sorry for the pedantic question, but is archiva.default a special ID, or should this ID be changed to match the ID of the repository in the Archiva Managed Repositories section that we want * to go to? Or is it just specific to the mirrors elements? I suspect it's the latter. Correct, it's not special. But, in any case, for some reason when I try mvn site I get: I suspect this is MRM-734. If I try to browse to my Archiva repository I'm prompted to do BasicAuth; when I submit my archiva admin webapp credentials, I can see that my repository does not contain this plugin, but the proxy connector should pick that up, right? I don't know why I'm being prompted for BasicAuth - I didn't configure it anywhere, and I can't seem to turn it off, either. So, can I turn off BasicAuth? Is the authentication the reason I can't resolve this plugin? Or do I need a profile with pluginRepositories which identify this same repository as my plugin repository? That might be an issue too. You can grant guest access to read the repository (instructions are contained on the web site). (Side question: why do we even need to distinguish the plugin repository from non-plugin repositories? Isn't it just a set of artifacts which happen to b Maven plugins?) Yes, it is probably something that will be deprecated in future versions of Maven. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva / internal / snapshot and settings.xml
On 20/03/2008, Henri Gomez [EMAIL PROTECTED] wrote: I wonder how I could trick my settings.xml to get ALL releases from internal and ALL snapshots from snapshot. In Maven 2.0.8 you just need to list each snapshot repository by ID and point it to the Archiva snapshot repo, and place it before the * definition. In Maven 2.0.9 there will be some include/exclude semantics for mirrorOf. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva / internal / snapshot and settings.xml
On 21/03/2008, Henri Gomez [EMAIL PROTECTED] wrote: In Maven 2.0.8 you just need to list each snapshot repository by ID and point it to the Archiva snapshot repo, and place it before the * definition. Do you recommand avoiding MirrorOf * ? No, mirrorOf * is a very useful method of locking down all access to your managed repositories. I highly recommend it. In Maven 2.0.9 there will be some include/exclude semantics for mirrorOf. Hum, did the 2.0.9 include/exclude will also works with maven 2.1-SNAPSHOT, used in m2eclipse or q4e ? Not yet, but I imagine it will be. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva / internal / snapshot and settings.xml
On 21/03/2008, Henri Gomez [EMAIL PROTECTED] wrote: mirror idinternal-snapshot-repository/id nameMaven Repository Manager for snapshots/name urlhttp://repo.mycompany.com/archiva/snapshots/url mirrorOf*snapshots*/mirrorOf /mirror replace mirrorOf with a single ID, and repeat for any other snapshot repos, and it will work. You should be using a very small set of snapshot repositories anyway. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva and nexus indexer
On 19/03/2008, Brett Porter [EMAIL PROTECTED] wrote: Assuming it's a Lucene index, it should be straightforward to create this format - we actually previously had in place a generator for very old versions of m2eclipse. I haven't looked at the index myself. After a quick look with Luke, it appears the format is the same as it has always been, with a couple of additions that appear to be unused on the central repository. So the old code from Archiva 0.9 could just be re-added to serve this. Cheers, Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
Thanks. Do you have maven-metadata.xml or *.xml in the artifacts list at the top of that page? - Brett On 20/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Currently, I have the following enbled: * create-missing-checksums * index-content * repository-purge * repository-purge * validate-checksums -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:24 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Jason, I took a look at this - the only way I could reproduce it was by adding maven-metadata.xml to the list of artifacts in the repository scanning tab - can you confirm whether that is the case for you? Cheers, Brett On 14/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Here is a snippet from the log file: 431177909 [pool-2-thread-1] ERROR org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Consumer [repository-purge] had an error when processing file [/proxy/maven2/org/apache/cxf/cxf-rt-bindings-soap/2.0.3-incubator/maven -metadata.xml]: Invalid path to Artifact: filename format is invalid, -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
On 20/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I just sent my archiva.xml, which should give you a complete picture. Ok, so I will file a new issue, but removing *.xml from your artifacts list temporarily will fix the exception problems you were having with the latest code (since it's picking up metadata files). As for the wrong build numbers, you were probably seeing this: http://jira.codehaus.org/browse/MNG-3441 Cheers, Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
On 14/03/2008, greyfairer1 [EMAIL PROTECTED] wrote: I just cloned the issue as MRM-738, but it's still reported as duplicate of MRM-674, which it is not IMHO. See comments on MRM-738. This problem occurred at an important client of mine, so I'm not eager to install any snapshot versions there, if I'm not sure the problem is fixed. Ok, I've updated the issue. I think your first issue has already been addressed, but I'll look at the second. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Any way to ignore LayoutExceptions?
Yes - I agree. On 08/03/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I could be naïve but in my mind, if you're providing an interface to browse a directory structure, each displayed element should be accessible. It's weird when directory contents (like jar files) are displayed, but the interface throws layout exceptions when they're clicked on. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 12:20 AM To: archiva-users@maven.apache.org Subject: Re: Any way to ignore LayoutExceptions? If you believe the format is actually valid, it's a bug. Some of these have been fixed for 1.0.2 - you might like to check JIRa. - Brett On 07/03/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I've deployed an artifact that does not have the same name as its parent module (long story) and I can't retrieve it, getting this exception: org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: filename format is invalid, should start with artifactId as stated in path. Is there any way I can prevent Archiva from enforcing this restriction? Thanks, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Plugins repository
Do you have some mirror settings in settings.xml? Adding a repository such as this in Maven will have it use both 'central' and 'plugins' identified repositories. - Brett On 07-Mar-2008 14:30:07 CET, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, I am trying to separate plugins from the others repository in order to have artifact releases - ./repository/internal artifact snapshots - ./repository/snapshots plugins (snapshots releases) - ./repository/plugins So I added in my archiva.xml : managedRepository locationD:\serveurs\Archiva-1.0.1/repositories/plugins/location releasestrue/releases snapshotstrue/snapshots refreshCronExpression0 0\,30 * * * ?/refreshCronExpression daysOlder30/daysOlder idplugins/id nameArchiva Managed Plugins Repository/name /managedRepository and in my USER_HOME/m2./settings.xml : pluginRepositories pluginRepository idplugins/id urlhttp://localhost:8080/archiva/repository/plugins/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories but plugins are still downloaded in the 2 others repository (releases snapshots). Did I miss something ? Thank you for your help ___ L'integrite de ce message n'etant pas assuree sur Internet, les societes du groupe Oddo ne peuvent ?tre tenues responsables de son contenu. Ce message et les eventuels fichiers attaches contiennent des informations confidentielles. Au cas o? il ne vous serait pas destine, nous vous remercions de bien vouloir le supprimer et en aviser l'expediteur. This message and the files that may be attached to it contain confidential information. The Oddo group may not be held responsible for their contents, whose accuracy and completeness cannot be guaranteed over the internet. If the message is not addressed to you, kindly delete it and notify the sender. ___ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Archiva selectively failing to proxy one particular artifact
On 01/03/2008, Brown, Carlton [EMAIL PROTECTED] wrote: OK thanks, I figured out what's going on. The checksum was failing for http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.6/maven-2.0.6.p om Testing confirms that it seems the checksums in the central repo are wrong. I manually ran md5 and sha1 sums on that file, and they do not match the sums stored in central. By comparison, the pom for 2.0.7 does not have this problem. Having confirmed this, if I could beg your indulgence for a couple of followup questions: 1) You said you didn't have this problem... I presume you have checksumming set to 'ignore' or 'fix' in Archiva? right 2) Is a 404 really the only error we get on this problem? This is the same thing you'd get for a completely nonexistent artifact, it's kind of misleading. we're looking to fix that for 1.0.2: http://jira.codehaus.org/browse/MRM-159 3) (Rhetorical question) WTF is up with Maven central having bad checksums for Maven's own artifacts, and how can I be the first one to notice this? Did I make some mistake, or is everyone except me ignoring checksums? Yeah, I remember 2.0.6 coming up - I'm not sure why it was never fixed. - Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Derby database relative to `cwd` ?
url=jdbc:derby:archiva/derbydb;create=true is a relative path - you
should provide the full path in here after the jdbc:derby: part.
- Brett
On 28/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote:
In my latest Archiva installation, I noticed that Archiva resolves the
path to the derby database relative to whatever was the current working
directory at the time Tomcat was started.
For example, if I'm in $CATALINA_HOME/bin and I run ./catalina.sh start,
then the derby database gets created under
$CATALINA_HOME/bin/archiva/derbydb.If I restart Tomcat later from a
different directory, it gets created from scratch in that different
directory.
To work around this issue and make sure the derby db dir is always
resolved to the same place, before Tomcat starts in catalina.sh, I must
explicitly call: cd $CATALINA_HOME
Here's part of my archiva.xml, where the path to the derby db gets set:
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
username=sa
password=
driverClassName=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:archiva/derbydb;create=true /
And in catalina.properties I have this:
appserver.home=${catalina.home}
appserver.base=${catalina.home}/archiva
This is Archiva 1.0.1 on Tomcat 6.0.16 with JDK 1.6.0_04, RHEL 5
Thanks in advance,
Carlton
-
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
Re: Derby database relative to `cwd` ?
That's completely out of the control of the application - you are
configuring Tomcat and Derby there.
On 28/02/2008, at 8:29 AM, Brown, Carlton wrote:
Thanks, will try it. But doesn't that behavior seem kind of weird?
The
database is a kind of important resource to risk it getting resolved
to
some random different place whenever you restart Tomcat. One would
expect it to resolve relative to some deterministic location like
${appserver.home} like Archiva logging does.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 27, 2008 3:51 PM
To: archiva-users@maven.apache.org
Subject: Re: Derby database relative to `cwd` ?
url=jdbc:derby:archiva/derbydb;create=true is a relative path - you
should provide the full path in here after the jdbc:derby: part.
- Brett
On 28/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote:
In my latest Archiva installation, I noticed that Archiva resolves
the
path to the derby database relative to whatever was the current
working
directory at the time Tomcat was started.
For example, if I'm in $CATALINA_HOME/bin and I run ./catalina.sh
start,
then the derby database gets created under
$CATALINA_HOME/bin/archiva/derbydb.If I restart Tomcat later
from a
different directory, it gets created from scratch in that different
directory.
To work around this issue and make sure the derby db dir is always
resolved to the same place, before Tomcat starts in catalina.sh, I
must
explicitly call: cd $CATALINA_HOME
Here's part of my archiva.xml, where the path to the derby db gets
set:
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
username=sa
password=
driverClassName=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:archiva/derbydb;create=true /
And in catalina.properties I have this:
appserver.home=${catalina.home}
appserver.base=${catalina.home}/archiva
This is Archiva 1.0.1 on Tomcat 6.0.16 with JDK 1.6.0_04, RHEL 5
Thanks in advance,
Carlton
-
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
Are these issues new, or were they present before (just wondering if it's a regression because of my changes). Anyway, I can add more tests. How is the performance/stability after a little while now? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Looks like I still have some issues. I have attached parts of the log file because the entire file is too large. Let me know if you would like any other information. I am using the same archiva.xml as before. These errors may be due to some non-standard artifacts in our repo, but most of them do seem correct to me. I do know that we have some artifacts that do not have poms though.
Re: archiva-1.0.2 eta?
I see - have you customised the default logging levels? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I think it has something to do with the log file reaching 2 GB in size. I couldn't even restart it until I remove the log files. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 9:44 PM To: archiva-users@maven.apache.org Subject: RE: archiva-1.0.2 eta? The snapshot build crashed on my this evening and had to be stopped. When I stopped it, it had a stale pid and said it wasn't running. However, there was some process still running that I had to kill manually. Either way, there is still some type of issue. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:58 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are these issues new, or were they present before (just wondering if it's a regression because of my changes). Anyway, I can add more tests. How is the performance/stability after a little while now? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Looks like I still have some issues. I have attached parts of the log file because the entire file is too large. Let me know if you would like any other information. I am using the same archiva.xml as before. These errors may be due to some non-standard artifacts in our repo, but most of them do seem correct to me. I do know that we have some artifacts that do not have poms though. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
If you are able to, please test the following build: http://people.apache.org/~brett/builds/apache-archiva-1.0.2-SNAPSHOT-bin.zip (please note this is not an official release) The problems should now be corrected. It would be helpful to check how that runs for a few days so we know whether it is worth putting together as a release including the fixes so far, or if more investigation is needed. Thanks, Brett On 25/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Actually, I misspoke. I checked the logs again today and saw the NPE during the database scanning. I am not sure what is going on because I didn't change any of the database configuration from installed defaults. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 12:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Did you switch to a build of 1.0.2-SNAPSHOT which caused the issue to not become reproducible, or have you stopped observing it in your current installation? Thanks, Brett On 24/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: In particular, I would like the fixes for the following issues: * http://jira.codehaus.org/browse/MRM-674 * http://jira.codehaus.org/browse/MRM-632 * http://jira.codehaus.org/browse/MRM-691 Only the last one still needs to be fixed, if it is still an issue. I am not able to reproduce it anymore. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are there any specific bugs in the bug tracking system that you feel need attention? Archiva 1.0.2 tasked bugs - http://urltea.com/2rqi Archiva overall open (non-future) bugs - http://urltea.com/2rqj - Joakim Jason Chaffee wrote: Is there an ETA on the 1.0.2 release? I would really like to get a couple of bug fixes. -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
Great - thanks for your patience. On 26/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Will do. I will install it today and test if for a couple of days. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, February 25, 2008 7:53 AM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? If you are able to, please test the following build: http://people.apache.org/~brett/builds/apache-archiva-1.0.2-SNAPSHOT-bin .zip (please note this is not an official release) The problems should now be corrected. It would be helpful to check how that runs for a few days so we know whether it is worth putting together as a release including the fixes so far, or if more investigation is needed. Thanks, Brett On 25/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Actually, I misspoke. I checked the logs again today and saw the NPE during the database scanning. I am not sure what is going on because I didn't change any of the database configuration from installed defaults. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 12:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Did you switch to a build of 1.0.2-SNAPSHOT which caused the issue to not become reproducible, or have you stopped observing it in your current installation? Thanks, Brett On 24/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: In particular, I would like the fixes for the following issues: * http://jira.codehaus.org/browse/MRM-674 * http://jira.codehaus.org/browse/MRM-632 * http://jira.codehaus.org/browse/MRM-691 Only the last one still needs to be fixed, if it is still an issue. I am not able to reproduce it anymore. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are there any specific bugs in the bug tracking system that you feel need attention? Archiva 1.0.2 tasked bugs - http://urltea.com/2rqi Archiva overall open (non-future) bugs - http://urltea.com/2rqj - Joakim Jason Chaffee wrote: Is there an ETA on the 1.0.2 release? I would really like to get a couple of bug fixes. -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: archiva-1.0.2 eta?
Did you switch to a build of 1.0.2-SNAPSHOT which caused the issue to not become reproducible, or have you stopped observing it in your current installation? Thanks, Brett On 24/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: In particular, I would like the fixes for the following issues: * http://jira.codehaus.org/browse/MRM-674 * http://jira.codehaus.org/browse/MRM-632 * http://jira.codehaus.org/browse/MRM-691 Only the last one still needs to be fixed, if it is still an issue. I am not able to reproduce it anymore. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are there any specific bugs in the bug tracking system that you feel need attention? Archiva 1.0.2 tasked bugs - http://urltea.com/2rqi Archiva overall open (non-future) bugs - http://urltea.com/2rqj - Joakim Jason Chaffee wrote: Is there an ETA on the 1.0.2 release? I would really like to get a couple of bug fixes. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Archiva crashes after a couple of days
On 23/02/2008, Eric Miles [EMAIL PROTECTED] wrote: Wow, you got us beat. Those are pretty large repos. Maybe the Archiva team can comment on this. I'm interested to hear what they say. I run it on localhost with just around 500M which is all the stuff from central that I use on a daily basis. We've successfully run it on a copy of the central repository which I believe has a similar number of artifacts but is not as large. I have also run it on an 80G repo that was mostly very large files, so a smaller number of artifacts. We have got some reports of excessive memory use (which might cause this) over a large number of proxy requests and James has been investigating that recently. I think we can certainly resolve this problem with more investigation if it continues - but it really needs some more information on what is happening in that environment and narrowing down the possible causes. Cheers, Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
The doc could well be a bit wrong in step 2 - please file a bug for that :) I do use it successfully with the following script to start it though: #!/bin/sh version=1.0.1 PLEXUS_BASE=$HOME/Library/Application\ Support/Archiva /Applications/Archiva/apache-archiva-$version/bin/macosx-universal-32/run.sh $@ No modifications to the installation are needed. Maybe you were missing an export of PLEXUS_BASE before starting? (the above doesn't need it since it's all on one line, the env vars are passed to the second run script). Cheers, Brett On 18/02/2008, Martin Hoeller [EMAIL PROTECTED] wrote: Hi! I'm trying to install archiva 1.0.1 on Linux as a standalone application as running in JBoss gives various errors. The archiva admin guide for standalone installation [0] says | However, the best way to use this installation technique is to separate | the configuration from the installation to make it easy to upgrade to | newer versions in the future. I tried to follow these steps exactly as explained. However, it seems this does not work at all. First, there is no 'data'-directory as mentioned in step 2 (I ignored this for now). Second, as archiva should now hold it's data in the PLEXUS_BASE directory, I thought it shouldn't need to write to the installation directory (PLEXUS_HOME) which seems not to be true. If write access to the PLEXUS_HOME directory is denied archiva startup fails. So I granted write permissions to this directory. Third, the user- and artifact- database seem to be created in the installation base (PLEXUS_HOME) and not PLEXUS_BASE, as PLEXUS_HOME now contains new directories data/archiva and data/users with lots of files in it. Has anybody successfully tried to perform a separation of installation and data in archiva 1.0.1? Any comments are welcome. tia, - martin [0] http://maven.apache.org/archiva/docs/1.0.1/adminguide/standalone.html -- Martin Höller | [EMAIL PROTECTED] *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-30 A-1100 Vienna, Austria | Fax: +43-1-6060114-71 -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
Ah, I see. You shouldn't move the original configuration (specifically the classworlds configuration). I just copy the 3 XML files to the new conf directory. Also, you are write - the PID file is written to the installation (which is probably a bug - we should make sure that is addressed in MRM-688. Thanks! Cheers, Brett On 19/02/2008, Martin Hoeller [EMAIL PROTECTED] wrote: On 19 Feb 2008, Brett Porter wrote: The doc could well be a bit wrong in step 2 - please file a bug for that :) Ok, done that: http://jira.codehaus.org/browse/MRM-701 I do use it successfully with the following script to start it though: #!/bin/sh version=1.0.1 PLEXUS_BASE=$HOME/Library/Application\ Support/Archiva /Applications/Archiva/apache-archiva-$version/bin/macosx-universal-32/run.sh $@ That's what I'd expect to work, but unfortunately it doesn't :-( (I suppose the $@ should be on one line with the run.sh line) Maybe you were missing an export of PLEXUS_BASE before starting? (the above doesn't need it since it's all on one line, the env vars are passed to the second run script). No, I did export PLEXUS_BASE and also tried it in a script like yours. No success. Here are exactly the steps i performed: 1) tar xzvf ~/downloads/apache-archiva-1.0.1-bin.tar.gz 2) mkdir -p archiva-data/logs (NOTE: when I do not create the 'logs' directory archiva throws an exception) 3) mv apache-archiva-1.0.1/conf archiva-data/ 4) chmod ugo-w -R apache-archiva-1.0.1/ 5) ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console The result is: Running Archiva... wrapper | ERROR: Could not write pid file ./archiva.pid: Permission denied It tries to write the PID-File to bin/linux-x86-32/, not './'. If I allow for writing there by doing 6) chmod a+w apache-archiva-1.0.1/bin/linux-x86-32/ 7) ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console The result is another exception: Running Archiva... wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| java.io.FileNotFoundException: [...]/apache-archiva-1.0.1/conf/classworlds.conf (No such file or directory) jvm 1| at java.io.FileInputStream.open(Native Method) jvm 1| at java.io.FileInputStream.init(FileInputStream.java:106) jvm 1| at java.io.FileInputStream.init(FileInputStream.java:66) jvm 1| at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:385) jvm 1| at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:585) jvm 1| at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:240) jvm 1| at java.lang.Thread.run(Thread.java:595) wrapper | -- Wrapper Stopped BTW, I'm running on Debian GNU/Linux, with java version 1.5.0_12. Anyone knows whats the problem here? - martin -- Martin Höller | [EMAIL PROTECTED] *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-30 A-1100 Vienna, Austria | Fax: +43-1-6060114-71 -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
yeah - the application expands itself so the whole directory (services, apps, bin) need to be writeable even if you use an alternate base. I suspect this is what is needed. It won't be an issue once MRM-688 is finished for a future version :) Cheers, Brett On 19/02/2008, Martin Hoeller [EMAIL PROTECTED] wrote: Hi Brett! Thanks for you help so far. On 19 Feb 2008, Brett Porter wrote: Ah, I see. You shouldn't move the original configuration (specifically the classworlds configuration). I just copy the 3 XML files to the new conf directory. Ok, so this is an issue in the mentioned documentation which says Move the conf and data directories. I'll file a JIRA issue for this as soon as I see it confirmed. Also, you are write - the PID file is written to the installation (which is probably a bug - we should make sure that is addressed in MRM-688. Well, even with the PID file writeable and the configuration copied instead of moved, it's still throwing exceptions. The stacktrace I get is as follows: $ ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console Running Archiva... wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| [INFO] Loading on start [role,roleHint]: [org.codehaus.plexus.naming.Naming,dataSources] jvm 1| [INFO] Loading on start [role,roleHint]: [org.codehaus.plexus.contextualizer.Contextualizer,jettyConfiguration] jvm 1| [INFO] Services will be deployed in: '/home/martin/work/archiva/apache-archiva-1.0.1/services'. jvm 1| [INFO] Applications will be deployed in: '/home/martin/work/archiva/apache-archiva-1.0.1/apps'. jvm 1| [INFO] Service Supervisor is deploying plexus-appserver-service-jetty-2.0-alpha-8. jvm 1| [ERROR] Error while deploying service plexus-appserver-service-jetty-2.0-alpha-8.sar. jvm 1| org.codehaus.plexus.appserver.ApplicationServerException: Error executing service deployment id. jvm 1| at org.codehaus.plexus.appserver.service.deploy.DefaultServiceDeployer.deploy(DefaultServiceDeployer.java:91) jvm 1| at org.codehaus.plexus.appserver.service.deploy.DefaultServiceDeployer.deploy(DefaultServiceDeployer.java:65) jvm 1| at org.codehaus.plexus.appserver.lifecycle.phase.ServiceDeploymentPhase$1.onJarDiscovered(ServiceDeploymentPhase.java:45) jvm 1| at org.codehaus.plexus.appserver.supervisor.DefaultSupervisor.scanDirectory(DefaultSupervisor.java:100) jvm 1| at org.codehaus.plexus.appserver.supervisor.DefaultSupervisor.scan(DefaultSupervisor.java:73) jvm 1| at org.codehaus.plexus.appserver.lifecycle.phase.ServiceDeploymentPhase.execute(ServiceDeploymentPhase.java:59) jvm 1| at org.codehaus.plexus.appserver.DefaultApplicationServer.start(DefaultApplicationServer.java:218) jvm 1| at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) jvm 1| at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:128) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:142) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:132) jvm 1| at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:90) jvm 1| at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147) jvm 1| at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:69) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:297) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) jvm 1| at org.codehaus.plexus.appserver.PlexusApplicationHost.start(PlexusApplicationHost.java:155) jvm 1| at org.codehaus.plexus.appserver.PlexusApplicationHost.start(PlexusApplicationHost.java:85) jvm 1| at org.codehaus.plexus.appserver.PlexusApplicationHost.main(PlexusApplicationHost.java:289) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) jvm 1| at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java
Re: Archiva 1.0.1
You need to modify the default whitelist on the java.net repository - as it only downloads javax/** by default. On 12/02/2008, ben short [EMAIL PROTECTED] wrote: Hi, Im trying to setup Archiva at work. I havent change any of the default configuration but when I run mvn clean on my project it fails to find the following plugin. groupIdorg.jvnet.jaxb1.maven2/groupId artifactIdmaven-jaxb1-plugin/artifactId version1.0-rc11/version And its available at the following URL.. http://download.java.net/maven/2/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc11/ Which as far as I can see is should be accessable via the Java.net Repository for Maven 2 Remote proxy. I have the following profile in my settings.xml profile idwork/id repositories repository idinternal/id nameArchiva Managed Internal Repository/name urlhttp://10.10.10.9:8099/archiva/repository/internal/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository repository idsnapshots/id nameArchiva Managed Snapshot Repository/name urlhttp://10.10.10.9:8099/archiva/repository/snapshots/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories /profile Here is the output I get when I try a mvn clean.. E:\Development\Work\rtti-ldb-ws-domain\trunkmvn clean [INFO] Scanning for projects... [INFO] [INFO] Building rtti live departure boards domain [INFO]task-segment: [clean] [INFO] Downloading: http://10.10.10.9:8099/archiva/repository/internal/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc11/maven-jaxb1-plugin-1.0-rc11.pom Downloading: http://10.10.10.9:8099/archiva/repository/internal/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc11/maven-jaxb1-plugin-1.0-rc11.pom Downloading: http://10.10.10.9:8099/archiva/repository/internal/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc11/maven-jaxb1-plugin-1.0-rc11.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.jvnet.jaxb1.maven2:maven-jaxb1-plugin Reason: POM 'org.jvnet.jaxb1.maven2:maven-jaxb1-plugin' not found in repository: Unable to download the artifact from any repository org.jvnet.jaxb1.maven2:maven-jaxb1-plugin:pom:1.0-rc11 from the specified remote repositories: snapshots (http://10.10.10.9:8099/archiva/repository/snapshots), internal (http://10.10.10.9:8099/archiva/repository/internal), central (http://repo1.maven.org/maven2) for project org.jvnet.jaxb1.maven2:maven-jaxb1-plugin [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Feb 11 22:14:38 GMT 2008 [INFO] Final Memory: 2M/6M [INFO] Can anyone give me an idea of what I need todo to get Archiva to download this plugin? -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Possible to remotely trigger a repository scan?
not at present (other than sending a valid cookie and hitting the scan admin link) - but there's a possible workaround. I believe that if you hit the URL of the artifact over WebDAV it will scan just that artifact which should be what you need. I'd need to confirm - it may only be in the proxy code. Cheers, Brett On 12/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: Hi, Is there any way to remotely trigger a repository scan? I'd like to create an Ant task to do this immediately following a build so that the published artifacts will immediately become available. Thanks - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Can Archiva promote a jar?
This is a feature that has already been on the roadmap, but not present in 1.0. Unfortunately there is no easy workaround - it would really be a matter of moving the files on the filesystem, or perhaps using the mvn deploy:deploy-file goal to publish to the certified repo. Another alternative is to have the certified repo proxy the internal one, and construct a whitelist for the artifacts you have certified. Cheers, Brett On 24/01/2008, Chris Helck [EMAIL PROTECTED] wrote: Hi, I'd like to have two managed repos: internal and certified. The internal is used by developers and is wide open to the web. The certified repo is tightly controlled. I'd like a limited set of users to be able to promote a set of poms/jars from the internal repo to the certified repo. Can this be done? Can it be done easily? Example: A new version of commons-lang comes out (say version 3.8) and developers modify their poms to use it. It gets uploaded to the internal repo and everything is ok. When development makes a release, the certification group promotes the new commons-lang pom/jar to their repo and do a certified build against it. If the cert group does not promote the pom/jar then the build fails. Regards, Christopher Helck ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: error downloading resources
it seems you have the managed repository connected to an invalid remote repository somehow. Do you have any remote repositories and proxy connectors configured? On 19/01/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, Can anyone tell me what might be causing the error below whenever there is an attempt to download a resource from my Archiva repository? POM, XML and JAR files all fail. The JDK is 1.5.0_11 and the app server is Tomcat 6.0.10. Thanks java.lang.IllegalArgumentException: protocol = http host = null at sun.net.spi.DefaultProxySelector.select(DefaultProxySelector.java:146) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:764) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:694) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:938) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:83) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:94) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferSimpleFile(DefaultRepositoryProxyConnectors.java:694) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferFile(DefaultRepositoryProxyConnectors.java:542) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:155) at org.apache.maven.archiva.web.repository.ProxiedDavServer.applyServerSideRelocation(ProxiedDavServer.java:447) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:354) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:189) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) at org.apache.maven.archiva.web.repository.RepositoryServlet.service(RepositoryServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: Stop/start Archiva from cron
it might be a missing JAVA_HOME environment variable? The wrapper probably doesn't use Java to stop it. - Brett On 17/01/2008, Ben Lidgey [EMAIL PROTECTED] wrote: We need to stop/start Archiva overnight to allow for backups etc. The cron to stop it seems to work OK, but when trying to start Archiva from a cron job we get the following in the wrapper*.log and it fails to start: STATUS | wrapper | 2008/01/17 06:00:01 | -- Wrapper Started as Daemon STATUS | wrapper | 2008/01/17 06:00:01 | Launching a JVM... ERROR | wrapper | 2008/01/17 06:00:01 | Unable to start JVM: No such file or directory (2) ERROR | wrapper | 2008/01/17 06:00:01 | Unable to start a JVM STATUS | wrapper | 2008/01/17 06:00:01 | -- Wrapper Stopped The crontab for the user under which Archiva is run is 00 20 * * * /home/devadmin/Tools/apache-archiva-1.0/bin/linux-x86-32/run.sh stop /home/devadmin/Tools/archiva_stop.log 00 06 * * * /home/devadmin/Tools/apache-archiva-1.0/bin/linux-x86-32/run.sh start /home/devadmin/Tools/archiva_start.log I am stumped to see why the stop works, but the start doesn't. Does anyone have any ideas or ideas on how I can get more info in the wrapper*.log file to see what file/directory cannot be found? Ben Lidgey Senior Software Engineer e: [EMAIL PROTECTED] Inuk Networks Limited Enterprise House Navigation Park Abercynon CF45 4SN t: +44 (0)844 546 0100 f: +44 (0)844 546 0200 w: www.inuknetworks.com This e-mail is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions expressed are those of the author. If you are not the intended recipient, please be advised that any use, dissemination, printing or copying of this email is strictly prohibited. -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: Archiva freeze because of down site ?
Yeah, improvements to the caching should certainly be filed as a feature request - and we should run through the plan on the dev@ list if possible. As far s your original freezing problem goes - I assigned it to the 1.0.1 version yesterday. I've seen another report too and they are helping to diagnose what the cause is. I had a suspicion it might be because of remote repository connections - I think this evidence is starting to confirm that. - Brett On 21/12/2007, nicolas de loof [EMAIL PROTECTED] wrote: Cache failure option is supposed (AFAIK) to enable such caching, and avoid requesting again and again the same repository, where 404 or timeout occurs. Reading the code, (DefaultRepositoryProxyConnectors) seems the cache is not used before requesting a proxyConnector for an artifact. 404 also are not cached, and IMHO they should for performance consideration (exemple : many artifact have no -sources.jar, but are requested by IDE plugins). The cache configuration is also hardcoded in archiva-policies. Not sure it will fit the requirements for all users and use-cases (missing artifact, network connection borken ...). I'll look at this tomorow, could you please fill an issue in Jira ? Nico. 2007/12/20, Julien CARSIQUE [EMAIL PROTECTED]: Hello, Today, archiva was (again freezed) but restart didn't solve the problem. Looking in the logs, I saw that one of our remote repositories was dead; removing it solved the problem. Archiva do not cache information about unavailable site to not calling it for each artifact ? Could be a useful improvement ? PS: I didn't have any answer about my mail Cannot use archiva browse function after 2 days running; we still have to restart archiva every one, two or three days because it freezes. Please, help would be very welcome; thanks. This morning, Archiva was freezed again; here's the top on the server : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ 25619 archiva 19 0 209m 186m 103m R 17.0 21.1 53:14.14 25751 archiva 20 0 209m 186m 103m R 16.8 21.1 47:34.28 28163 archiva 14 0 209m 186m 103m S 16.6 21.1 40:42.57 28124 archiva 14 0 209m 186m 103m S 16.4 21.1 41:44.36 26348 archiva 19 0 209m 186m 103m R 15.7 21.1 43:01.91 -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: [Archiva] network proxy always used
It sounds like a bug, but it's hard to tell. Can you file an issue in JIRA, and if possible attach your configuration file? (check passwords have been removed). Is the internal repository available on the filesystem either by being on the same machine or as a share? This should work instead if it is available. - Brett On 18/12/2007, Reynard Jacques [EMAIL PROTECTED] wrote: Hello, I've installed Archiva 1.0 as a Maven proxy repository for internet and corporate repositories. I've added the remote Internet Repositories, the network proxy and the proxy connectors. It works well for the internet repositories but when Archiva tries to connect to the corporate repository in the same subnetwork, Archiva uses the network proxy despite the proxy connector is set to Direct Connection. If no proxy connectors is defined, Archiva didn't try to get data form the corporate repository. Could you tell me if it is a bug or a mistake in the configuration ? I really need to be able to configure some remote repositories through a proxy and one direct. Thanks in advance for your answer Jacques REYNARD -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: Proxying SNAPSHOT repositories
I've been seeing this also - I'm not yet sure of the conditions under which they don't work. I have seen it work for the majority of snapshots - but particularly those with long versions beforehand seem problematic. I intend to investigate next week - if you can create an issue that'd be helpful. Cheers, Brett On 15/12/2007, gumnaam23 [EMAIL PROTECTED] wrote: I have setup Archiva Managed Internal Repository as my whole and sole mirror in my settings.xml. The settings.xml does not contain any other repository information, just the mirror entry . The Archiva Manged Internal Repository is set to proxy 4/5 external repositories, One of which contains certain SNAPSHOTs that I have as dependencies. The proxy connector for this repository has snapshot policy set to always, I also tried daily, hourly. But the SNAPSHOT is never downloaded any my build fails. The log files show no special activity, how do I debug this issue ? -- View this message in context: http://www.nabble.com/Proxying-SNAPSHOT-repositories-tp14336170p14336170.html Sent from the archiva-users mailing list archive at Nabble.com. -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: Can't find plugins through Archiva
this might be a persisted problem on your client after a previous failed attempt on Archiva. If you delete org/apache/maven/plugins from your local repository (~/.m2/repository on the maven machine) and try again, does it work? If not - please check the archiva logs for reasons the request might be refused. - Brett On 12/12/2007, Shazia Bashir [EMAIL PROTECTED] wrote: Hi, im just testing out Archiva to use as a http proxy. Everything seems to working just find, besides plugins, if i run plugins goals the plugins cant be found, and i am using the central as a remote repository: h http://repo1.maven.org/maven2 mvn clean: The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not exist or no valid version could be found mvn deploy: The plugin 'org.apache.maven.plugins:maven-deploy-plugin' does not exist or no valid version could be found All help appreciated. Thanx Shazia -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
Re: Deploy Maven 1 artifacts to Archiva
What version of Maven are you using? I believe webdav can work under 1.1, though I haven't tried it. You can also use an alternate deployment technique (scp, ftp) to drop it directly into the repository directory on the server - Archiva will pick it up on the next repository scan. Cheers, Brett On 10/10/2007, Zach Legein [EMAIL PROTECTED] wrote: Hi All, How can I deploy an internal maven1 artifact as a snapshot to Archiva? It seems I need to use wagon-webdav, which doesn't exists for maven1. How do I configure my project.properties file to do this? Thanks -zach -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
