Separating the base from the installation not working
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 signature.asc Description: PGP signature
Reverse artifact lookup?
Hi all, This question may in fact be generalized to Maven, but I'm wondering if there is any reverse lookup mechanism for jar artifacts. For example, I have this mystery dependency called foo.jar. Is there a way to query a Maven-compliant repository to search on the checksum to determine the group, module, revision, etc? I think Archiva has this feature, but could it proxy such a query to the Maven 2 repository? 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.
Re: Not able to login to archiva using newly created user
On Feb 17, 2008 11:59 PM, Pahwa, Sunita [EMAIL PROTECTED] wrote: Which file I need to change in the data folder of archiva to flip the validated bit? You would need to use a client like Squirrel SQL to connect to the database and edit it using SQL statements. The quickest way to fix this is probably to add the following line to security.properties: email.validation.required=false See: http://redback.codehaus.org/configuration.html Also, When I click on resend validation for newly created user, it gives me following error: ... 2008-02-18 12:24:38,942 [SocketListener0-0] ERROR org.codehaus.plexus.redback.xw ork.mail.Mailer:default - Unable to send message, subject [Welcome to Maven Archiva] org.codehaus.plexus.mailsender.MailSenderException: Error while sending the message. Is there more to the stack trace? I didn't see the root cause in what you pasted. We don't need the whole thing, just look for the real reason it's having trouble. My guess is that you need to configure the smtp server so it can send mail. -- Wendy
Re: Reverse artifact lookup?
On Feb 18, 2008 7:33 AM, Brown, Carlton [EMAIL PROTECTED] wrote: This question may in fact be generalized to Maven, but I'm wondering if there is any reverse lookup mechanism for jar artifacts. For example, I have this mystery dependency called foo.jar. Is there a way to query a Maven-compliant repository to search on the checksum to determine the group, module, revision, etc? I think Archiva has this feature, but could it proxy such a query to the Maven 2 repository? Archiva does have that feature, but it only works on the content in its own repositories. If you have the disk space, you can rsync the entire central repo locally and point Archiva at it, in which case Archiva's checksum search feature would do what you wanted. How do you see proxying a query through to the central Maven repo working? In the short term, I've found that putting the checksum into a Google search usually turns up information about the jar. The central repo doesn't seem to be showing up on search results, but some other repos do, as well as various other clues. I tried it with the md5 and sha1 checksums for the JUnit 3.8.1 jar. HTH, -- Wendy
Mac OS X jnilib download issue
We store Mac OS X jnilib artifacts in our unmanaged maven
repository. During our transition to a standalone archiva 1.0.1
instance running on linux (RHEL5), I was able to deploy our jnilib
artifacts, but I was not able to download them as a dependency in a
different project. I received the dependency not found in any
repository error. When running the repository scan, the log file
showed this:
3076623 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [metadata-updater] had an error when processing file [/var/
www/html/managed-maven2/fobs4jmf/macosx/i386/libfobs4jmf/0.4.1.4-
SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib]: Unable to
convert to artifact reference: fobs4jmf/macosx/i386/libfobs4jmf/
0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
org.apache.maven.archiva.consumers.ConsumerException: Unable to
convert to artifact reference: fobs4jmf/macosx/i386/libfobs4jmf/
0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processF
ile(MetadataUpdaterConsumer.java:167)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFile
Closure.execute(ConsumerProcessFileClosure.java:57)
at org.apache.commons.collections.functors.IfClosure.execute
(IfClosure.java:117)
at org.apache.commons.collections.CollectionUtils.forAllDo
(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.di
rectoryWalkStep(RepositoryScannerInstance.java:138)
at org.codehaus.plexus.util.DirectoryWalker.fireStep
(DirectoryWalker.java:173)
at org.codehaus.plexus.util.DirectoryWalker.scanDir
(DirectoryWalker.java:391)
at org.codehaus.plexus.util.DirectoryWalker.scanDir
(DirectoryWalker.java:385)
...
Caused by:
org.apache.maven.archiva.repository.layout.LayoutException: Invalid
path to Artifact: filename format is invalid,expected timestamp
format in filename.
at
org.apache.maven.archiva.repository.content.DefaultPathParser.toArtifact
Reference(DefaultPathParser.java:131)
at
org.apache.maven.archiva.repository.content.AbstractDefaultRepositoryCon
tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
at
org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryCont
ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processF
ile(MetadataUpdaterConsumer.java:161)
I narrowed down the issue to a regex in
org.apache.maven.archiva.repository.content.FilenameParser. The
artifact filename extension is limited to four characters and the
version was coming back with '0.4.1.4-20080217.211715-4.j'. By
changing the extension length to six characters, the issue was resolved.
I'd like to offer the following patch to support .dylib and .jnilib
files for mac os x.
org.apache.maven.archiva.repository.content.FilenameParser
43c43
private static final Pattern extensionPattern = Pattern.compile
( (.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]{1,4}$),
---
private static final Pattern extensionPattern = Pattern.compile
( (.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]{1,6}$),
Cheers,
Jim Jackson
deploying to archiva repository
I am using archiva 1.0.1 standalone version. I am trying to deploy my artifact to archiva 'internal' repository using 'mvn: deploy'. 1) I have done following changes to my artifact's POM: -added repository and snapshotRepository sections under distributionManagement element with appropriate id and url -added build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions /build 2) In Maven's setting.xml, added one server configuration with archiva user name and password. User name is for administrator having 'repository manager' rights. On mvn:deploy, it gives following error: WARNING: No credentials available for the 'Repository Archiva Managed Internal Repository' authentication realm at localhost In Archiva log, following error shows up NFO: RepositoryServlet: Authorization Denied [ip=127.0.0.1 ,isWriteRequest=true, ermission=archiva-upload-repository,repo=internal] : no matching permissions Can anyone tell me, how to resolve this. What should be the id for server in settings.xml? The user id given in settings.xml has role of 'Repository Manager' . I have followed all the steps specified at http://maven.apache.org/archiva/docs/1.0/userguide/deploy.html but it is not working. Thanks in advance.
maven, archiva, and hibernate
Hi, Currently, I am having an issue with maven while using an internal archiva repository. Our development repository is hosted on a local server and in any project poms, we include the repository like this: repositories repository idinternal/id urlhttps://maven.mycompany.com/repository/internal/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots layoutdefault/layout /repository /repositories Also, I am using the 2.0 version of the hibernate3-maven-plugin. The problem is that whenever I build my project, the hibernate plugin does not create the database table structure correctly. Constraints are in the wrong order. However, when I build the project in offline mode, the hibernate plugin works correctly. I have tried using a different version of the hibernate plugin in case there is a bad version in local server's repository, but that does not solve the problem. As long as I am connected to the local repository, my build fails. If I run the build just using the repository on my own computer, the build passes. Does anyone have any suggestions for steps to take to solve this issue? Please let me know what other resources I can include to help solve this issue. Thanks, Ben
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
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 signature.asc Description: PGP signature
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
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:229) jvm 1| at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) 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|
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
Re: Mac OS X jnilib download issue
Brett,
MRM-703. The patch drops the maximum length constraint.
Cheers,
Jim Jackson
On Feb 18, 2008, at 3:23 PM, Brett Porter wrote:
Thanks Jim!
Would you mind putting this in JIRA as an attached patch? Also, I'd
suggest just dropping the maximum length constraint altogether - I
don't see that it adds anything?
Thanks,
Brett
On 19/02/2008, Jim Jackson [EMAIL PROTECTED] wrote:
We store Mac OS X jnilib artifacts in our unmanaged maven
repository. During our transition to a standalone archiva 1.0.1
instance running on linux (RHEL5), I was able to deploy our jnilib
artifacts, but I was not able to download them as a dependency in a
different project. I received the dependency not found in any
repository error. When running the repository scan, the log file
showed this:
3076623 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default
-
Consumer [metadata-updater] had an error when processing file [/
var/
www/html/managed-maven2/fobs4jmf/macosx/i386/libfobs4jmf/0.4.1.4-
SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib]: Unable to
convert to artifact reference: fobs4jmf/macosx/i386/libfobs4jmf/
0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
org.apache.maven.archiva.consumers.ConsumerException: Unable to
convert to artifact reference: fobs4jmf/macosx/i386/libfobs4jmf/
0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.proce
ssF
ile(MetadataUpdaterConsumer.java:167)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessF
ile
Closure.execute(ConsumerProcessFileClosure.java:57)
at org.apache.commons.collections.functors.IfClosure.execute
(IfClosure.java:117)
at org.apache.commons.collections.CollectionUtils.forAllDo
(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance
.di
rectoryWalkStep(RepositoryScannerInstance.java:138)
at org.codehaus.plexus.util.DirectoryWalker.fireStep
(DirectoryWalker.java:173)
at org.codehaus.plexus.util.DirectoryWalker.scanDir
(DirectoryWalker.java:391)
at org.codehaus.plexus.util.DirectoryWalker.scanDir
(DirectoryWalker.java:385)
...
Caused by:
org.apache.maven.archiva.repository.layout.LayoutException: Invalid
path to Artifact: filename format is invalid,expected timestamp
format in filename.
at
org.apache.maven.archiva.repository.content.DefaultPathParser.toArtif
act
Reference(DefaultPathParser.java:131)
at
org.apache.maven.archiva.repository.content.AbstractDefaultRepository
Con
tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
at
org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryC
ont
ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.proce
ssF
ile(MetadataUpdaterConsumer.java:161)
I narrowed down the issue to a regex in
org.apache.maven.archiva.repository.content.FilenameParser. The
artifact filename extension is limited to four characters and the
version was coming back with '0.4.1.4-20080217.211715-4.j'. By
changing the extension length to six characters, the issue was
resolved.
I'd like to offer the following patch to support .dylib and .jnilib
files for mac os x.
org.apache.maven.archiva.repository.content.FilenameParser
43c43
private static final Pattern extensionPattern = Pattern.compile
( (.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]{1,4}$),
---
private static final Pattern extensionPattern = Pattern.compile
( (.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]{1,6}$),
Cheers,
Jim Jackson
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
On 19 Feb 2008, Brett Porter wrote: oops - you need to edit plexus.xml too. Which one, a find -name plexus.xml gives me this: ./archiva-data/conf/plexus.xml ./apache-archiva-1.0.1/conf/plexus.xml ./apache-archiva-1.0.1/apps/archiva/conf/plexus.xml I assume it's either the first or the second one. If you could file one bug that captures all the problems with this given document (preferably with a patch ;) it would be much appreciated. Ok, I'll file one as soon as my archiva is running as it should :) Many thanks to your Brett! - 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 signature.asc Description: PGP signature
Re: Separating the base from the installation not working
On 19 Feb 2008, Brett Porter wrote:
${appserver.base} should work, but if not you can hardcode it
YES! Finally got it working! Many thanks again to you Brett!
I'll go and file an issue with the updated documentation.
- 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
signature.asc
Description: PGP signature
