[
http://jira.codehaus.org/browse/MRM-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113533
]
Emmanuel Venisse commented on MRM-545:
--------------------------------------
You can look at the Continuum installation doc
(http://maven.apache.org/continuum/documentation/1_1/installation/tomcat.html).
Continuum and Archiva installs are very similar.
> Documentation for configuring for Tomcat is invalid
> ---------------------------------------------------
>
> Key: MRM-545
> URL: http://jira.codehaus.org/browse/MRM-545
> Project: Archiva
> Issue Type: Bug
> Components: documentation
> Affects Versions: 1.0-beta-2
> Environment: Windows XP, Tomcat-5.5.17/Tomcat-5.5.20, JDK-1.5.0_06
> Reporter: William Ferguson
> Priority: Critical
> Fix For: 1.0
>
> Attachments: bad-log-filename.log, mail-auth-class-not-found.log
>
>
> Following http://maven.apache.org/archiva/guides/getting-started.html for
> Tomcat didn't get me started.
> I'll go through it point by point
> # Create a directory in tomcat called archiva, at the same level as bin,
> conf, logs and the others.
> # Copy the war file from apps/archiva/lib into the new directory
> There is not apps/archiva/lib in the 1.0-beta-2 distribution.
> apps contains a single file : archiva-plexus-application-1.0-beta-2.jar which
> does itself contain a war file, so I extracted that file and copied it to the
> TOMCAT_HOME/archiva folder.
> NB IMHO modifying TOMCAT in this manner smells all wrong.
> # Create a conf/Catalina/localhost/archiva.xml file with the following data:
> yadda, yadda
> The docBase attribute refers to archiva-webapp-1.0-SNAPSHOT.war instead of
> archiva-webapp-1.0-beta-2.war
> No idea why a javax.mail.Session needs to be configured here, haven't seen
> any documentation in Archiva that suggests it send, receives email. But this
> was a slight pain when configuring for Tomcat-5.5.20 as I needed to follow
> the extra steps for the missing classes. If the MailSession is not required
> it would be better to avoid this pain by simplifying the config.
> Again modifying TOMCAT like this does not feel right. Surely this config
> could be contained within the webapp.
> # Copy $HOME/.m2/org/apache/derby/derby/10.1.3.1/derby-10.1.3.1.jar (or from
> the remote repository) into the Tomcat common/lib
> I am *really* against this as I have now introduced Derby-10.1.3.1 into the
> classpath of 8all* my other applications running on that Tomcat instance.
> Surely this library could be packaged up into the webapp.
> # To deal with a current bug, you'll also need to add the following to your
> $catalina.home/conf/web.xml in the relevant section (search for jspx):
> Again, surely this could be included in the config for the Archiva webapp
> instead of introduced into Tomcat generally. This heavy handed approach makes
> maintenance difficult, eg upgrading to a new version of Tomcat is now
> extremely onerous.
> OK, so having followed the instructions above, when I try to startup Tomcat
> the first thin I get is a failure with the logging sub system. see attached
> bad-log-filename.log. I believe this is due to the fact that
> ${appserver.base} in log4j.xml has never been set:
> {code}
> <param name="file" value="${appserver.base}/logs/archiva.log" />
> {code}
> Next, it fails as it can't find javax.mail.Authenticator (this is
> Tomcat-5.5.17).
> NB I never saw any indication that "schema SA does not exist" as the final
> note suggests. But perhaps this was because Archiva never got that far.
> Certainly no application is available at http://localhost:8080/archiva/
> Anyway, by this stage I became discouraged enough that I gave up.
> Its a shame really as I would have liked to be able to compare Archiva
> against Proximity and Artifactory, both of which I managed to get setup in
> under 10 mins including vastly restructuring the default repository config
> that they ship with.
> Brett, hope that helps.
> Further notes:
> I really don't like modifying the contents of TOMCAT_HOME other than to
> deploy a WAR to TOMCAT_HOME/webapps.
> And the infrastructure team weren't impressed either and its makes
> maintenance high cost.
> Better to keep all config solely within the confines of the webapp or use a
> environment variable to declare a separate proxy_home where all the config is
> contained (like Artifactory does).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
