[
http://jira.codehaus.org/browse/MRM-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MRM-545.
----------------------------
Resolution: Fixed
I've made minor adjustments to the doc, and there is some more comprehensive
doc on the wiki.
The mail is needed for sending user account details. It can be safely omitted
if you don't need forgotten password accounts to work and will be admining by
hand.
The derby jar must be in the common/lib so that it works as a JNDI data source
from Tomcat, which is instantiated before the web application classloader is
started.
I've removed the workaround since that appears not to be needed any more.
> 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
> Assignee: Brett Porter
> 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
