Installer Hudson sur un serveur OVH

Pour installer le serveur d'intégration continue Hudson sur un serveur dédié OVH tournant Ubuntu, le plus pratique c'est de partir du package Debian et de suivre les instructions.

Le script va créer un utilisateur hudson, installer les binaires, les fichiers de configuration et le script de démarrage/arrêt.

Par défaut, l'espace disque est sous /home.

Si vous n'avez pas repartitionné votre serveur, vous pouvez déplacer la home et les logs de hudson.

# Stoppons Hudson

sudo /etc/init.d/hudson stop

# Passons sous /home/hudson

sudo mv /var/lib/hudson /home

sudo ln -s /home/hudson /var/lib/hudson

sudo mkdir /home/hudson/log

sudo mv /var/log/hudson/hudson.log /home/hudson/log/hudson.log

sudo ln -s /home/hudson/log/hudson.log /var/log/hudson/hudson.log

sudo chown -R hudson:nogroup /home/hudson

# Demarrons Hudson

sudo /etc/init.d/hudson start

La version Debian est un peu en retard sur la dernière version d'Hudson, voici comment la mettre à jour:

# Stoppons Hudson

sudo /etc/init.d/hudson stop

# Sauvegarde du war existant et download de la derniere version

cd /usr/share/hudson

sudo mv hudson.war hudson.war.old

sudo wget http://hudson-ci.org/latest/hudson.war

# Demarrons Hudson

sudo /etc/init.d/hudson start

Public Maven repositories and wrong POMs

I experienced an issue with log4j 1.2.15: it comes with a POM that wrongly forces you to include extra dependencies that should be optional (e.g. Java mail if you don't plan to use the SMTPAppender feature). This issue has been reported as bug #43304 to log4j team.

My first reaction was to exclude these dependencies in my project pom.xml but this did not work (I did not take time to investigate why). Anyway, it was faster for me to patch the log4j POM in our intranet repository.

Lesson learned: managing dependencies can be hard and you should not depend on public repositories as they can be wrong sometimes. Make sure your team has an Intranet repository and make it simple to update with a good repository manager like Artifactory.

Not fully convinced by Maven 2

After several weeks of trying to migrate our build process to Maven 2, we decided to stop due to:

• Incompatibility with WebLogic: we use BEA Weblogic ant tasks that are not compatible with Maven build lifecycle phases. For instance, appc mixes generate-sources, compile and package; for this reason the maven-weblogic-plugin that uses these tasks has same flaw. So if you need to use other Maven plugins you must implement workarounds and attach them to unnatural phases to ensure they get executed before or after appc. See my previous post.
  

• Lack of flexibility: by nature, Maven is not flexible, the only ways to get more flexibility is to use profiles, maven-antrun-plugin or to write your own plugin in java: not really simple nor very productive especially if you need to write simple workarounds. It's strange because there seems to be a growing tendency in open source build tools to enable more flexibility: ant 1.8 feature list includes logic/control flow features from ant-contrib (for, if, while, etc…), gant uses groovy as build scripting language on top of ant, buildr uses Ruby.

• Lack of auditability: with Maven's convenient way to download missing parts and self update, it's difficult to know exactly what was used to build one version of your product. The fact that Maven mixes tool's dependencies of the tool (maven+plugins) and dependencies of the projects being built into one single local repository surely does not help here. it would be better if separation of concerns was implemented in local repository to ensure that the dependencies managed by the developers do not get polluted by dependencies that are out of its control scope.

• Issues are difficult to diagnose: I've got examples about classpath, system properties where it's difficult to find the culprit between Maven, plugins or dependencies.

• Plugins quality ranks from excellent to terrible: this is not a Maven issue by itself but combined with above mentioned difficulty to diagnose it can lead to painful situations.

• Maven's defect backlog is quite impressive and I'm not sure that the situation is going to improve soon.

So, our next approach will be to use ant for building and restrict Maven to managing dependencies and generating project site and quality reports.

WebLogic 9.2 is not Maven 2 friendly

Using Maven 2 is more difficult when you use a platform like BEA WebLogic 9.2 because of their "split directory" convention which creates a gap with Maven's own conventions.

A first approach could be to avoid using the split directory structure, however it's not that easy because it comes with a set of specific ant tasks to pre-compile your JSPs, generate a web service from an EJB, package an ear file, ...
These tasks are not open sourced and are too high level to be easily integrated into Maven: for instance, if you want to pre-compile your JSPs, you cannot use anymore jspc because it has been deprecated in favor of appc which depends on the split directory structure.
This makes almost impossible to write an equivalent Maven plugin for a 3rd party, only BEA could do it.

Another issue with these tasks is that they are defined in weblogic.jar: a 50 MB jar which contains a lot of stuff that may collides with dependencies in your classpath, especially because BEA chose to specify a relative classpath in its jar manifest.

An alternative is to use the WebLogic ant tasks from Maven using the antrun plugin, unfortunately this plugin is poorly documented and does not offer easy options to configure a classpath to integrate weblogic.jar. Also, antrun retrieves its own version of ant from Maven's repository that may collide with the one required by WebLogic's tasks; you can find workarounds for this but then you will have to trick Maven to make it think that it has generated the artifact generated by appc.

So, unless BEA endorses Maven and provides its own plugins, it will be difficult to use Maven for a non trivial WebLogic application. My next step will be to try to use ant and Maven's antlib in order to be able to use Maven's dependency management.

P.S.: I just found Hussein Badakhchani's excellent post about maven and appc, I may try his approach as well.