Ce script execute donc pour chaque job les étapes suivantes :

• Si le job est de type Maven alors j’enregistre la liste de destinataires depuis le « reporter » et je le retire du job.
• Dans tous les cas je regarde les « publishers » actuels et si il y a les notifications standards ou du plugin mail-ext j’enregistre la liste de destinataires (donc la liste de mail-ext écrase celle de la notification standard si elle existait qui elle même écrase celle de maven si elle existait) et je retire le ou les « publishers ».
• Je crée et rajoute au job mon nouveau « publisher » mail-ext configuré selon mes besoins.

J’ai ainsi pu mettre à jour tous les jobs de mon serveur sans erreur et sans tâche manuelle fastidieuse.

Ci dessous le script groovy (n’étant ni expert en groovy et encore moins dans les APIs d’Hudson que je découvre, ce code doit être facilement améliorable).

import hudson.plugins.emailext.*
import hudson.plugins.emailext.plugins.trigger.*
import hudson.plugins.jira.*
import hudson.model.*
import hudson.maven.*
import hudson.maven.reporters.*
import hudson.tasks.*

// For each project
for(item in Hudson.instance.items) {
  def recipients
  println("JOB : "+item.name);

  // Find current recipients defined in project

  if(item instanceof MavenModuleSet) {
    println(">MAVEN MODULE SET");

    // Search for Maven Mailer Reporter
    println(">>Reporters");
    for(reporter in item.reporters) {
      println(">>> "+reporter);
      if(reporter instanceof MavenMailer) {
        recipients = reporter.recipients
        // remove it
        item.reporters.remove(reporter)
      }
    }
  } else
  if(item instanceof FreeStyleProject) {
    println(">FREESTYLE PROJECT");
  }

  println(">>Publishers");
  for(publisher in item.publishersList) {
    println(">>> "+publisher);
    // Search for default Mailer Publisher
    if(publisher instanceof Mailer) {
      recipients = publisher.recipients
      // remove it
      item.publishersList.remove(publisher)
    } else
    // Or for Extended Email Publisher
    if(publisher instanceof ExtendedEmailPublisher) {
      recipients = publisher.recipientList
      item.publishers.remove(publisher)
      // remove it
      item.publishersList.remove(publisher)
    }
  }

  // If we found recipients list to send mail
  if(recipients!=null){
    println (">CURRENT RECIPIENT : "+recipients)
    // We create a new Extended Email Publisher
    def eep = new ExtendedEmailPublisher();
    eep.recipientList = recipients
    eep.defaultSubject = "\$DEFAULT_SUBJECT"
    eep.defaultContent = "\$DEFAULT_CONTENT"
    // With some triggers
    eep.configuredTriggers.add(new FailureTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new FixedTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new StillFailingTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new StillUnstableTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new UnstableTrigger(
      email : new EmailType(sendToRecipientList : true,
         body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    // And we add/replace it in the project
    item.publishersList.replace(eep);
  }else{
    println (">NO RECIPIENT")
  }

  println("\n=======\n");
}

• Le plug-in supporte désormais les projets en structure « flat » ou aussi nommée « en râteau ». Pour ces projets ( pour diverses bonnes ou moins bonnes raisons ) le POM parent n’est pas en même temps le réacteur des sous modules. Le parent est un sous-module à part entière. Jusqu’à présent le plug-in release ne fonctionnait pas sur ce type de projet. C’est enfin une chose corrigée.
• Les bugs les plus récalcitrants du goal branch sont corrigés. Vous pouvez utiliser ce dernier par exemple pour créer une branche depuis le trunk avant de faire la release pour passer sur une branche dite de stabilisation. Ou alors vous pouvez créer la branche depuis un tag pour créer une branche de maintenance de la version en question. Dans tous les cas le plugin prend en charge la modification des versions dans les POMs, chose que l’on sait bien ennuyeuse (et dangereuse) à faire à la main.
• Le plug-in release contrôle à nouveau correctement les modifications locales (fichiers modifiés ou ajoutés et non commités) avant de démarrer le processus de release ou de création d’une branche. Cette fonctionnalité était buggée depuis la version 2.0-beta-8 (cf. MRELEASE-481).
• Enfin, je pense qu’il s’agit de la correction la plus attendue de tous : Il n’est plus nécessaire pendant la phase de préparation d’installer les artifacts du projet dans le repository local. A l’origine, lié à un problème dans le noyau de Maven, Il était très souvent nécessaire de configurer le goal prepare du plugin pour faire une installation des artifacts plutot qu’une vérification sans quoi la release échouait faute de trouver les dépendances entre modules. Cela avait les désavantages de couter du temps (le packaging de gros artifacts comme des WARs ou EARs prend beaucoup de temps au niveau du build à cause de l’utilisation intensive des IOs de la machine) et surtout de pouvoir produire lors de cette phase qu’une partie des binaires de la version en cours de release si cette dernière echouait. C’est pour cela que la phase prepare ne doit faire qu’exécuter les tests sans créer les binaires et si tout se passe bien c’est la phase perform qui générera ces derniers. Ceci est désormais rentré dans le bon ordre et suit l’idée d’origine du plugin (la fameuse raison des deux phases).

La documentation du plugin est à jour. Vous pouvez retrouver le détail des modifications dans la Release Note de cette version.

Bonne release à tous !!

Question aux produits concurrents : Vous faites comment pour offrir ce service à vos utilisateurs ?

<disclaimer> As a member of the Archiva team (though rarely active, I admit) I will try to defend it throughout this article. However, being a professional consultant first and foremost, I hope to keep my objectivity. I’ll let you be the judge … </disclaimer>

Having recently migrated a significant number of repository servers from Apache Archiva to Sonatype Nexus, I would like to share with you the process I followed, some tips, and point out a few pitfalls I encountered.
A big Thank you to Tarpoon, C’est pas dur and all of my team for helping.

Introduction

Background

A little background to this migration: We had a large enterprise-scale implementation with dozens of JEE projects of all sizes (from a mouse to the ocean liner – and NO! I am not talking about the Titanic!), and at least 200 active developers accessing the system simultaneously during the day.
Most projects are using Maven. To help teams to make better and faster builds we offered a complete infrastructure for continuous integration: a big server (Dual QuadCore Xeon with 16GB RAM running Red Hat Enterprise Linux 5.1),  hosting an Atlassian Bamboo continuous integration server with (approximately): 110 (real time) continuous integration builds, 40 (daily) maven sites builds, 20 (daily) Sonar builds. It also hosted a Maven repository server (Archiva 1.1.1 before migrating), which stored a little less than a dozen local repositories and provided a proxy and cache for twenty external repositories (for almost 400GB of data).
The majority of that space was used by the repository of internal snapshots (200GB) and the repository of internal releases (150GB). To understand these sizes you must know that some projects may produce (for good or bad reasons) some EARs up to 100MB in size. By adding the sizes of JARs and WARs that compose these EARs, each deployment quickly grows to take up a lot of space.

Why change?

For several months we were having stability issues with our integration environment. From one build to another we would see execution times fluctuate widely. We also had intermittent errors that were not related to projects, but to the infrastructure :

• 500 or 502 errors on uploads in Archiva without any apparent reason (I tried to track down the issues without success),
• Many periods of unavailability of Archiva or Bamboo after exceeding the maximum number of open file descriptors allowed for the user. We must concede that these tools handle a lot of files (downloads, uploads, and other manipulations on a large number of artifacts). Archiva easily exceeds the default limit of 1024 descriptors which forced us to increase it. But even at 2048 Archiva would still occasionally exceed the limit.
• Inability to download snapshots if the local repository used by Bamboo was emptied just prior to that. This resulted in regular failures of our Maven sites or Sonar builds.

We recently submitted a bug against Archiva (MRM-1136), for which I spent several hours diagnosing the issue (problems with management of meta-data issued by Maven 2.1.0). To resolve the issue would require us to quickly upgrade to Archiva 1.1.4 or 1.2.

All of these problems, even though they were only occasional, strongly discredited our continuous integration service. How could we criticize a project for not using our CI if it kept sending them false negatives? They already have enough work with addressing real errors in their builds. The continuous integration environment must be as reliable as a Swiss watch.

It was time for us to act.

We could update Archiva, which would entail significant validation costs without much improvement. Apart from the incompatibility with Maven 2.1.0, nothing suggested that the new version fixed any of our problems and there were few improvements/new features at that time, due to lack of time by the maintainers.

The other choice was to get another tool with the potential to meet the new requirements.

The feedback from the community about Nexus was very encouraging. Moreover, the latter pro version opens up new possibilities for the future with its innovative features:

• Staging repositories to put artifacts being validated in a temporary area prior to delivery.
• Opportunity to proxy and aggregate eclipse update sites. Currently we are doing it by hand, which is expensive, complicated (I hate P2), and boring.
• and more…

As the situation seemed to be calling for it, we decided to try our luck with Nexus.

Migration

Let’s get started.

Existing environment

A little overview of our existing environment. Before the migration, our environment was like this:

The environment before the migration

We were hosting our internal repositories in what Archiva calls managed repositories. There is one for releases, one for snapshots and another one for third-party libraries (often those delivered by closed-source vendors).
To cache external repositories (configured as « remote repositories ») we are using two more repositories (one for external releases and one for external snapshots).

Our Archiva shows two groups: One to access released artifacts, and another one for snapshots. We never set up a unique group with access to both of them because in our tests we noticed that Archiva often had issues merging descriptors coming from several repositories (maven-metadata.xml), and it can have dramatic consequences if you mix up releases and snapshots.

Groups allow to greatly simplify Maven configuration, avoiding the need to declare too many repositories. Moreover, they enhance your Maven experience, speeding up your builds. Each missing dependency request is sent only once to each group, while the process in the background polls each repository in the group and maintains a cache about missing dependencies to further speed up the build. Sending missing dependency requests to several repositories is an inexcusable waste of time.

Repository users (developers and the continuous integration server) access them using these settings :

<settings>
  <profiles>
    <profile>
      <id>default</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>http://serveur.entreprise.fr/archiva/repository/releases/ </url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>false</enabled></snapshots>
        </repository>
        <repository>
          <id>snapshots</id>
          <url>http://serveur.entreprise.fr/archiva/repository/snapshots/ </url>
          <releases><enabled>false</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
      </repositories>
     <pluginrepositories>
        <pluginrepository>
          <id>central</id>
          <url>http://serveur.entreprise.fr/archiva/repository/releases/ </url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>false</enabled></snapshots>
        </pluginrepository>
        <pluginrepository>
          <id>snapshots</id>
          <url>http://serveur.entreprise.fr/archiva/repository/snapshots/ </url>
          <releases><enabled>false</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </pluginrepository>
      </pluginrepositories>
    </profile>
  </profiles>
  <activeprofiles>
    <activeprofile>default</activeprofile>
  </activeprofiles>
</settings>

By redefining the central server address (normally located here: http://repo1.maven.org/maven2/) we configured Maven to look only for released artifacts in our group in Archiva. This gives us access to both internal and external releases. In the same way, the repository snapshots allow us to obtain development versions of all artifacts.

Constraints

Migrating a server isn’t easy when you have 200 developers using it every day.

First, we had to be sure to only stop the service for a very short time (or we would have to do it outside of working hours… ouch!!!). Stopping the continuous integration server temporarily isn’t such a big problem. Asking all teams to use maven in offline mode, and not to use our repositories is more difficult. Usually, we don’t have to wait long before someone needs to download a new artifact or a project has to do a release.

Secondly, it was mandatory for us to keep the compatibility with preexisting Maven settings. Due to the large number of projects and developers it would be impossible to change all repositories settings in Maven configuration. It would impact all projects and all developers if we changed the upload URLs (distributionManagement) and download settings (repositories).

The process

To reduce cost, we decided to not perform our tests in a test environment. This would require us to duplicate the entire integration environment we have in production.
After some basic tests performed on the tool, the real baptism by fire was the scalability of the server (with an increasing volume of data and number of users).
During migration system resources allowed us to easily handle both servers in parallel. We chose the strategy to run Archiva and Nexus in parallel and to switch services to the new server one after another, while keeping the fallback option to revert if necessary.

We had enough space to rebuild caches of external repositories (this required only a few gigabytes), however we could not duplicate our internal repositories, which are too large, and we could have consistency issues. We also did not want to give both products access to internal repositories, because we feared they might access them simultaneously and corrupt our data. Therefore we began our migration leaving our internal repositories on Archiva planning to move them to Nexus at the end of migration.

For URL compatibility we used rewriting rules on the Apache server. It would switch between old and new URLs in a transparent manner.

Installing Nexus

We performed a classic installation of Nexus 1.3.2 (the opensource and standalone bundle) adjusting a few parameters such as the HTTP port, the paths of data and log directories to conform to the organization of our server. All this was quickly done because unlike Archiva we did not have to create a database (which had to be in mysql to follow our standards). Our server was up and ready to be configured.

Configuration of groups and external repositories

We started the Nexus configuration by creating proxy repositories. We also added, for purposes of migration, proxies for our internal repositories hosted on Archiva.

The GUI is ergonomic which makes the registration of 20 external repositories very bearable. Thank you ExtJS!

Unlike Archiva which proposes to store the artifacts of external repositories in the same local repository, Nexus stores the contents of each in a dedicated repository (proxy).

Regarding settings of external repositories, it should be noted that we lose the opportunity provided by Archiva to have white and black lists of artifacts coming from each external repository. Nexus uses the concept of « routes » for this type of filtering. Unfortunately we can apply those routes only at a group level and not on a repository.
Since some lists that we have in Archiva are only for performance issues (e.g. do not query a repository in which we know that a certain artifact is not located), we decided to not duplicate this setup in Nexus waiting to see if there were real problems.

In our setting we faced a first disappointment. As we have to proxy some repositories hosted internally (the one delivered by the Sonar server and all of those always on Archiva during the migration) we were forced to declare the company web proxy on each proxy repository. It is impossible to define the web proxy in the global configuration of Nexus and to disable it on a given proxy repository (NEXUS-2317).

While our external repositories configuration was almost complete, we had our first big setback. We discovered that it was impossible to proxy repositories which are in the legacy layout of maven 1 (at Atlassian and dev.java.net for example).
To achieve this we need to create virtual repositories which are used by Nexus to convert a repository from one format to another. Tough luck, because two bugs (NEXUS-1909, NEXUS-1910) prevented us from doing it.
Fortunately for us, the Nexus team has been very responsive and was able to incorporate the corrections to these bugs in version 1.3.3 which was published the day after our discovery. Otherwise we have to admit that we probably would not have continued our tests on Nexus.
We have updated our server which allowed us to see that the process was very simple since the application, its configuration, and the data were all well separated.

We finalized the configuration of Nexus by creating groups. That is the same concept as in Archiva (which copied it).
The configuration of groups is however relatively poorly designed in terms of ergonomics. We had to select each repository we wanted to add to the group and then put it in the correct order in the list. The order is very important, because Nexus will use it to search for artifacts. We must therefore place internal repositories prior to external ones. The problem is that this list displays only the name of each repository (and the name is often truncated because of its length). So you should be careful in naming your repositories to be able to easily sort them when you have several dozen in a group.

We followed Nexus recommendations by creating a single group that exposes all releases and all snapshots. (This will help us avoid having to battle the screen for configuring a group twice ).

From now we were supposed to be able to download all artifacts needed to build our projects with Nexus.

After several successful tests on our desktop we tested the whole system with our continuous integration server.
We deleted its local repository and updated its configuration:

<settings>
  <mirrors>
    <mirror>
      <!--This sends everything else to /public -->
      <id>nexus</id>
      <mirrorof>*</mirrorof>
      <url>http://serveur.entreprise.fr/nexus/content/groups/public/ </url>
    </mirror>
  </mirrors>
  <profiles>
    <profile>
      <id>default</id>
      <!--Enable snapshots for the built in central repo to direct -->
      <!--all requests to nexus via the mirror -->
      <repositories>
        <repository>
          <id>central</id>
          <url>http://central </url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
      </repositories>
     <pluginrepositories>
        <pluginrepository>
          <id>central</id>
          <url>http://central </url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </pluginrepository>
      </pluginrepositories>
    </profile>
  </profiles>
  <activeprofiles>
    <!--make the profile active all the time -->
    <activeprofile>default</activeprofile>
  </activeprofiles>
</settings>

Please note: I am not at all a fan of using the mirror * which requires us to put releases and snapshots in the same group. However, this is the only solution, as there is no way to tell Maven to find releases on one mirror location and snapshots on another one. I find this dangerous because e.g. when you call a plugin without defining its version (a plugin in command line such as eclipse:eclipse or archetype:generate) you may retrieve a snapshot version of it. Thus you have to take care to follow the recommendation of Maven to define all the versions of plugins that are used in your project descriptor (directly or by inheritance) to avoid surprises. In our context we won’t have this issue since the recommendation is followed by all projects using a parent POM that is setting all versions for them.

The environment with Nexus and Archiva running in parallel was now ready to go :

The environment while migrating

Nothing changed for developers who still use Archiva while the continuous integration server retrieves all artifacts from Nexus.

Tuning

After testing it a few days we could see that Nexus sometimes had difficulty quickly delivering artifacts. The time has come to look at a few more advanced settings.

Routes allow to restrict the list of repositories that Nexus has to verify when we request an artifact to a group. This can be done via permissions or prohibitions.

The first route we create is the one which tells to Nexus to search for our artifacts (.*/com.mycompany/.*) only in proxy repositories giving access to our internal artifacts on Archiva. When the switch to Nexus will be completely finalized, this route will point only to our internal repositories hosted by Nexus.

We also add rules for .*/org/apache/.* and .*/org/codehaus/.* which are heavily used by Maven, so that artifacts are retrieved only from the central repository and snapshots repositories of each community.

This gave a pretty good boost to our Nexus implementation.

After several days of use by the continuous integration server, Nexus was running fine. Therefore we got ready for the second part of our migration: hosting of our internal repositories on Nexus.

Setting internal repositories and security

Before we could move internal repositories from Archiva to Nexus we had to create hosted repositories. We created directories for our repositories in a different location from Archiva, as to not let both products access the same data. We reused repository identifiers used in Archiva to easily create rewriting rules on Apache HTTP server.

We spent some time learning the security mechanism in Nexus. Settings are so fine that even the most basic use cases require convoluted settings.

We began by creating privileges (read, write, update) on each hosted repository. We created roles that grouped some privileges on hosted repositories together. In our case, one role to deploy released artifacts on repositories (for projects teams) and another role to deploy snapshots on repositories (for continuous integration server).

We finished by creating users with roles defined above without forgetting the role to download from any repository.

Internal repositories were ready, all was left to do was to move data to Nexus and to stop Archiva.

The final steps

To keep the compatibility between Archiva and Nexus we had to do two things.
For each internal repository on which we’ll have to upload artifacts we explicitly wrote a rule to transform the URL from Archiva to Nexus.
Apache configuration example:

RewriteRule ^/archiva/repository/internal-releases/(.*) http://localhost/nexus/content/repositories/internal-releases/$1 [P]
RewriteRule ^/archiva/repository/internal-snapshots/(.*) http://localhost/nexus/content/repositories/internal-snapshots/$1 [P]
RewriteRule ^/archiva/repository/third-parties/(.*) http://localhost/nexus/content/repositories/third-parties/$1 [P]

For all other types of read access we just created a rule which transfered them to our unique group in Nexus.
Apache configuration example:

RewriteRule ^/archiva/repository/[a-z\-]+/(.*) http://localhost/nexus/content/groups/public/$1 [P]

Now we were ready to migrate:

1. Stop Nexus.
2. Stop Archiva.
3. Install rewriting rules on Apache.
4. Move content of internal repositories from Archiva to Nexus.
5. Restart Nexus.

On D-day we made the switch in less than 10 minutes. Nexus took a few hours to index the hundreds of GB of data, but without taking much of a performance hit.

The final environment

Despite some pitfalls we encountered, the migration wasn’t technically really complex. We did it in 2 weeks and we spent less than half that time actually working on it.

Now we are studying how to configure scheduled services. Sonatype made a major effort on product documentation. It allows us to quickly discover all its features. However, we are disappointed when we want to go further than the reference guide. Some best practices about the usage of the tool in a corporate environment are still missing:

• What scheduled tasks should be used?
• Under what circumstances?
• When?
• Why should we repair metadata?
• Why should we delete caches?
• How are we supposed to use the trash?

Results

Two weeks after the migration we drew a first conclusion of our Nexus experience.

Let’s begin by changes on issues we previously had with Archiva and which led us to attempt the Nexus adventure.

The number of file descriptors simultaneously opened

It’s a little bit early to declare victory, however after running for two weeks we can see that our problem on the number of file descriptors opened simultaneously disappeared. Whereas Archiva easily exceeded the 1024 descriptors opened, Nexus uses only 400 which enormously reduces the load on the server.

Number of file descriptors simultaneously opened by Archiva

Number of file descriptors simultaneously opened by Nexus

Memory consumption

Even if we had enough RAM, Archiva is a big consumer of memory. Archiva took an average of 1.3 GB to run. Nexus requires many less and works with 400MB (Even my Eclipse requires more ). It saves almost 1GB that we can now allocate to our builds.

Memory consumption by Archiva

Memory consumption by Nexus

Not found snapshots

Sadly this problems always persists. Because migration to Nexus hasn’t fixed it, we investigated a little bit more and discovered two causes for it :

• The first one is a bug in Maven (MNG-4142) : It’s a subtle problem halfway between the use of artifacts with classifiers and a corruption of metadata in the local repository.
• The second one is a set of bugs in Nexus (NEXUS-1333, NEXUS-2036): The scheduled service used to repair metadata deletes them if it cannot read it. The problem is that it doesn’t succeed to read them if you are using some deprecated properties like {parent.*} (replaced by ${project.parent.*}) or ${pom.*} (replaced by ${project.*}). Note that NEXUS-2036 is marked as fixed on version 1.3.4.

Nothing is perfect

A bug we didn’t have before appeared with the usage of Nexus. Because of our usage of rewriting rules in apache, Maven now complains that cookies are rejected when we upload artifacts on an internal repository (NEXUS-1967). This is a minor issue which doesn’t alter our system, but is annoying because it pollutes our Maven logs on the integration server.

But we had a good surprise

Resource savings on the server (IO, RAM) and the quality of Nexus on the speed to upload artifacts (whatever their size) lead to an important improvement of quality of service and stability of the continuous integration server. As you can see below on some graphs taken from different builds in Bamboo there’s a big difference between before and after Nexus. Build times decreased and are consistent like never before.

Conclusion

Did we find the silver bullet ? Of course, no. I have already listed some constraints and problems we had and there are probably many others to discover (the team already has a good backlog). Any product can be improved. Despite all that, how could I say something other than… migrate! It’s unfortunate for me to have to admit this as a member of the Archiva team, but my own research proves it. Nexus is a product of great quality, which delivers the service you need for your development projects very well. Furthermore, developed by full-time employees (thank you Sonatype), it enjoys an easily accessible and responsive support (I recommend the channel #nexus on #irc.codehaus.org). Archiva itself is governed by the laws of open source, suffers from the lack of time of its maintainers (even if they are doing as much as they can) which doesn’t help it to stay in the competition.

So, enjoy and benefit from service and quality by adopting Nexus!

Courrez immédiatement vous inscrire si ça n’est pas déjà fait car même si la salle est beaucoup plus grande que d’habitude, les places partent vites !!
Je vous conseil aussi vivement de vous inscrire pour la 3eme mi-temps (aka cocktail dinatoire), car c’est un moment privilégié pour rencontrer et discuter avec toutes les personnes de la communauté.

A mon grand regret, pour cause de déplacement professionnel, je ne pourrai pas être des vôtres puisque je suis à 9000Km de là, à Hanoï. Je suivrai cependant avec plaisir la soirée depuis la Wave Google (pour une fois que Google Wave va peut être enfin me servir à quelque chose). Pour tous ceux qui auraient eu la bonne idée d’acheter notre livre Apache Maven, sachez que Nicolas De loof, mon co-auteur, sera là et qu’il adore faire des dédicaces !!

Je terminerai en remerciant publiquement une dernière fois SUN Microsystems pour tout ce qu’ils ont pu apporter à Java. La communauté n’a pas toujours été tendre avec eux et pourtant qui aime bien châtie bien. La communauté Java n’en ressortira que plus forte et plus soudée pour se faire entendre du géant Oracle.

Signé : Le mec au simple polo fatigué, baskets, et moyennement rasé.

• Beginning Java EE 6 – Apress – Antonio Goncalves
• Spring par la pratique – Eyrolles – Julien Dubois
• Hibernate Search – Manning – Emmanuel Bernard
• Apache Maven – Pearson – Nicolas De loof, Arnaud Héritier

Je n’ai plus qu’ à sortir m’acheter un stylo (il va falloir qu je me souvienne comment on l’utilise !).

Pearson - Apache Maven

Rapide news pour vous annoncer que depuis aujourd’hui vous pouvez acheter sur le site Pearson notre livre au format PDF. Cette version est donc un peu moins cher (27,20 € au lieu des 32€).

MAJ 04 Décembre 2009 : Pendant le mois de décembre sur le site pearson pour l’achat de la copie imprimée, la version PDF est offerte.

Bonne lecture.

Pearson - Apache Maven

Ca y est, il est là !!!

Il est né le divin enfant …. Oui, le père noël est un peu en avance cette année Et pourtant, est ce qu’il n’est pas beau notre cadeau ? Notre livre en français (co-écrit avec Nicolas De loof) consacré à Maven est dans toutes les librairies dès ce matin (Pearson, Amazon, FNAC, Le monde en « tique », …).

Pffff, c’était pas gagné !

Il aura fallu un an entre le premier mail avec notre éditeur Pearson et sa publication aujourd’hui. Bien sûr pas à temps plein, nous avons un véritable travail (de temps en temps) et aussi une de famille (et oui le geek se reproduit .. ). Pour arriver au résultat escompté, cela nous aura demandé quelques efforts, de la discipline, de la patience (la stabilité de M$ Word est pitoyable dès que le document commence à faire quelques pages) et du temps (pas mal d’après-midi de week-end pour l’un et de soirées/nuits pour l’autre). Mais voilà il est là et nous avons tout de même pris beaucoup de plaisir à le rédiger.

Alors pourquoi avoir relevé ce défi ?

Parce que nous aimons partager nos connaissances, mais aussi les challenges. Et oui, pour des geeks comme nous qui passeraient bien leurs journées et nuits à coder (euhhh, c’est ce que l’on fait d’ailleurs ??), sortir un traitement de texte n’est pas vraiment notre plus grand plaisir.
Cela fait 6 ans environ que tous les deux nous utilisons Maven et ce dernier nous a rendu de très grands services dans des contextes très variés. Pourtant il faut avouer que dans les diverses équipes que nous avons pu croiser son adoption était loin d’être évidente, voir même catastrophique.
En questionnant ceux qui avaient tant de difficultés avec l’outil nous nous rendions compte que les causes du mal étaient souvent similaires : Les équipes n’ont pas le temps ( et ne prennent pas le temps ) de comprendre l’outil. En effet la documentation sur le site web et les wikis est plutôt rebutante et désorganisée.
Il existe pourtant déjà plusieurs livres disponibles gratuitement en téléchargement (Maven: The Definitive Guide, Better Builds with Maven) ou plus classiquement en librairie (Apache Maven 2 Effective Implementation). Mais la réputation des français et de leur rapport avec les langues étrangères n’est plus à faire. C’est peine perdu. L’idée de digérer 300 pages, ou plus, en anglais sur un sujet pas obligatoirement distrayant n’est guère motivante.
Avec Nicolas nous avons donc décidé d’apporter notre contribution à la communauté Maven francophone en écrivant un livre original sur le sujet qui puisse permette à tout le monde, du débutant à l’expert d’apprendre sans s’ennuyer.

C’est un long roman, c’est une belle histoire ….

Ce livre est donc construit comme un roman avec de l’action, du suspense, de l’amour et des trahisons. Bon j’exagère un peu, nous sommes loin des grands classiques de la littérature mais nous avons fait notre possible pour contextualiser l’ensemble de nos explications. Nous avons tout simplement repris les expériences que nous avons vécu ces dernières années et nous avons bâti le livre dessus. Pour illustrer tous nos propos, nous avons choisi de raconter l’évolution d’une entreprise. Nous démarrons sur une start-up construite par deux copains pour en arriver jusqu’à son intégration dans une multinationale avec toutes les rencontres enrichissantes qu’ils ont pu faire en chemin.
Ainsi nous montrons à la fois ce que Maven apporte localement à un projet qui démarre et ce qu’il apporte pour l’entreprise qui souhaite standardiser ses développements et réduire à long terme le coût du « build » de ses projets. Notre livre n’a pas pour but d’être exhaustif. Vous ne trouverez pas dedans la documentation détaillée de la vingtaine d’options du plugin « compiler ». Par contre, nous vous expliquons les cas d’usages les plus récurrents de Maven, tirés de nos expériences du terrain, et comment sur ces cas précis il faut le mettre en oeuvre. Nous expliquons avant tout pourquoi Maven est ainsi fait, et nous détaillons tous les concepts que vous serez amener à manipuler. Notre but est que vous compreniez l’outil et son fonctionnement afin que vous l’utilisiez de la manière la plus adéquate possible. Les sujets couverts sont variés :

• le descripteur de projet (POM),
• les dépendances et les librairies (gestion des dépots),
• le paramétrage de la construction du projet (utilisation de langages alternatifs comme groovy, …),
• les tests unitaires, d’intégration (dbunit,…), d’ihm(selenium), fonctionnels (fitnesse), de performance (jmeter), …
• les projets JEE,
• l’intégration aux environnements de développement (eclipse, netbeans, intellij),
• l’automatisation du processus de livraison,
• la gestion de la qualité (pmd, checkstyle, findbugs, sonar, …),
• l’écriture de plugins Maven,
• le packaging sur mesure (assembly),
• les modèles de projets (archetypes),
• l’avenir de Maven (boule de crystal es-tu là ?)
• … (je dois en oublier)

Nous espérons que vous trouverez dans cet ouvrage tout ce qu’il vous manquait pour comprendre Maven et l’apprécier à sa juste valeur. Nous avons fait notre possible pour diffuser autant de connaissances que possible (même entre nous nous avons réussi à découvrir des choses ). L’idéal serait que vous preniez autant de plaisir à le lire que nous en avons eu à l’écrire car notre but est réellement que vous ayez envie d’aller jusqu’à la dernière page.

Nous vous souhaitons une bonne lecture. N’hésitez pas à nous faire part de vos commentaires. La perfection n’existe pas et nous adorons nous améliorer.

A noter : L’ouvrage Maven: The Definitive Guide, aka « Le gros pavé de référence » est en cours de traduction et devrait être disponible d’ici quelques mois. Ce dernier pourra faire un bon complément à notre ouvrage pour creuser un sujet spécifique sur Maven.

Qui est qui ?

Les personnages ci-dessous sont les protagonistes de l’histoire contée dans notre livre. Ce sont des francophones de la communauté Java ou Maven. Je vous laisse les commentaires pour essayer de les trouver (les ressemblances ne sont parfois pas évidentes ). Vous avez toutes les réponses à la fin de notre ouvrage donc ne trichez pas !

[View with PicLens]

Le descriptif officiel

Editeur : Pearson France
Collection : Référence
Auteurs : Nicolas De loof, Arnaud Héritier
Niveau : Tous niveaux
Catégorie : Programmation
Prix : 32 €
Référence : 978-2-7440-2337-8
Date de parution : 20 Novembre 2009

Maven, l’outil open-source de gestion et d’automatisation de développement Java, a le vent en poupe. Les raisons : il systématise, rationalise et simplifie le développement collaboratif de projets Java, faisant gagner aux entreprises comme aux développeurs du temps et de l’argent !

Les auteurs, membres de l’équipe de développement Maven, aidés par toute la communauté francophone, ont imaginé de présenter Maven 2 sous un angle original et didactique, à travers un projet fictif, inspiré de leurs expériences sur le terrain, dont ils détaillent toutes les phases successives. Ce projet évolue au fil des besoins et de la contribution de développeurs aux profils différents, vous familiarisant avec les concepts fondamentaux de Maven et leur mise en œuvre pratique, mais aussi avec les fonctionnalités plus avancées. Vous profitez également des recommandations et bonnes pratiques pour optimiser votre utilisation de Maven.

Vous découvrez ainsi de manière ludique et grâce à des exemples concrets le potentiel de Maven, et tous les avantages qu’il peut apporter à vos propres projets.

Sommaire

• Introduction
• Au-delà de java.lang
• Un peu plus que compiler
• Mettre en place des tests unitaires
• Mettre en place des tests d’intégration
• Gestion avancée des dépendances
• Quand le projet devient trop lourd
• Maven et JEE
• Maven et les IDE
• Le jour J : la livraison
• Utiliser un outil non supporté
• L’assurance qualité
• Respecter un format de distribution
• Un nouveau projet démarre
• Avons-nous fait le bon choix
• Nos recommandations
• Épilogue
• Lexique

À propos des auteurs

Nicolas De loof est techno-veilleur et architecte Java pour une grande SSII française. Avec 12 ans de développement dans ses bagages, il a rejoint l’équipe de développement Maven en 2007, en particulier pour le support de GWT. Créateur du BreizhJug, groupe d’utilisateurs de Java Rennais, en 2008, il participe activement au microcosme Java francophone.
Arnaud Héritier est responsable des pratiques et outils de développement chez eXo Platform. Cela fait 10 ans qu’il participe aux développements d’applications en Java que ce soit en tant que programmeur ou architecte. Il contribue à différents projets open-sources et en particulier à Maven dont il a rejoint l’équipe de développement Maven en 2004 et a intégré son comité de direction en 2005.

Je vous promet une soirée sans langue de bois. Ceux qui me connaissent savent que je n’ai pas ma langue dans ma poche, et que je n’hésite pas à critiquer l’outil lorsque cela est fondé. Je vous donne donc rendez-vous le 12 Novembre et n’oubliez pas de vous inscrire. Si vous souhaitez voir des sujets particuliers traités pendant la session ou encore si vous avez des questions, n’hésitez pas à m’en parler via les commentaires de cet article. J’ai encore tout le temps d’adapter le contenu à vos demandes.

MAJ du 14 Novembre 2009
Ci-dessous retrouvez les slides de la session.

Apache Ivy : Gestionnaire de dépendances très connu pour son intégration avec Apache Ant il offre une solution qui se veut simple et évolutive pour gérer ses librairies dans différents types et formats de référentiels. Xavier Hanin, créateur du projet, devrait le défendre en visio conférence (si je ne débranche pas interet ).

EasyAnt : A mi-chemin entre Ant et Maven, cet outil offre toute la souplesse du premier tout en simplifiant l’utilisation par des développeurs en supportant de nombreuses conventions du deuxième. Il étend l’offre technique de Ant à l’aide d’une architecture extensible à base de plugins et intègre nativement des services de plus haut niveaux comme Ivy. EasyAnt sera défendu par le créateur du projet : Jean-Louis Boudart.

Gradle : Dans lignée de EasyAnt, Gradle est un outil de build orienté scripts qui apporte un niveau de services « à la maven » (gestion des dépendances, build multi-modules, …). Par contre ce dernier à la grande particularité de lever les « limitations » (?) du langage XML pour offrir un véritable langage de scripts : Groovy. Gradle sera défendu par Grégory Boissinot,consultant chez Zenika.

Nous nous attacherons tous à vous montrer les spécificités de nos produits, leurs avantages, et nous n’hésiterons pas à décrier les inconvénients des autres . De manière plus constructive, nous vous expliquerons quels sont les cas que les produits adressent le mieux et comment ils peuvent devenir complémentaires.

Venez nombreux à assister à ce match du siècle et n’oubliez pas de vous inscrire !!

Builders Battle au NormandyJUG

MAJ du 21 octobre 2009
Ci-dessous retrouvez les slides de la session.