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 and sections under element with appropriate and -added org.apache.maven.wagon wagon-webdav 1.0-beta-2 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: internal https://maven.mycompany.com/repository/internal true true default 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.(FileInputStream.java:106) jvm 1| at java.io.FileInputStream.(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.(FileInputStream.java:106) > jvm 1| at java.io.FileInputStream.(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
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: Mac OS X jnilib download issue
thanks - will apply it now On 19/02/2008, Jim Jackson <[EMAIL PROTECTED]> wrote: > 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/ > > > > -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
Morning! On 19 Feb 2008, Brett Porter wrote: > 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. Ok. Maybe this could be mentioned one the installation page somewhere. Just make this information available. Should I file an issue? > It won't be an issue once MRM-688 is finished for a future version :) Fine :) So changing permissions again and starting archiva another time it now starts up successfully (with the expected exception regarding "Schema 'SA' does not exist". But the user databases are still created in the installation directory and not in PLEXUS_BASE: $ ll apache-archiva-1.0.1/data/ archiva-data/data apache-archiva-1.0.1/data/: total 16 drwxr-xr-x 4 martin martin 4096 2008-02-19 08:13 . drwxrwxr-x 11 martin martin 4096 2008-02-19 08:03 .. drwxr-xr-x 3 martin martin 4096 2008-02-19 08:13 archiva drwxr-xr-x 3 martin martin 4096 2008-02-19 08:03 users archiva-data/data: total 12 drwxr-xr-x 3 martin martin 4096 2008-02-19 08:03 . drwxr-xr-x 6 martin martin 4096 2008-02-19 08:03 .. drwxr-xr-x 4 martin martin 4096 2008-02-19 08:03 repositories Is this behaviour expected? - 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: > 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
first one :) On 19/02/2008, Martin Hoeller <[EMAIL PROTECTED]> wrote: > 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 > > -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Separating the base from the installation not working
${appserver.base} should work, but if not you can hardcode it On 19/02/2008, Martin Hoeller <[EMAIL PROTECTED]> wrote: > On 19 Feb 2008, Martin Hoeller wrote: > > > 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. > > ./archiva-data/conf/plexus.xml seems to be the right one. There is the > following that should probably be changed: > > ... > > url > > jdbc:derby:${plexus.home}/data/users/database;create=true > > ... > > url > > jdbc:derby:${plexus.home}/data/archiva/database;create=true > > > Changing ${plexus.home} to ${plexus.base} changed the location but not as > I wanted as plexus.base seems not to be defined. Can I use PLEXUS_BASE > somehow or do I have to hardcode the path? > > - 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
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