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
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
