Latest Activity

Maven 3 support in Hudson Maven Plugin

Olivier Lamy - Mon, 12/13/2010 - 23:39
You have developped hudson plugins using the maven-plugin or you are an early adopter user : so this blog entry is for you !

Some stuff has been done in a branch called main-maven3-support [1] in github to support maven 3 in the Hudson native maven plugin.
The plugin now supports both maven 2 and maven 3.
Note the pom parsing to detect modules now use the maven 3 apis. (ProjectBuilder maven component [2])
You don't have something to install (just choose the maven version for your maven build) the plugin will detect which maven version is used for the maven build and use differents implementation to "listen" the build.

To test it, you can build it .
First build the embedder (note this will move to github soon)

svn co https://svn.java.net/svn/hudson~svn/trunk/hudson/lib/hudson-maven-embedder
cd hudson-maven-embedder
mvn clean install -DskipTests

Then build hudson from the branch

git clone https://github.com/hudson/hudson.git
git checkout main-maven3-support
mvn clean install -DskipTests

And hudson.war is in war/target/hudson.war

I have pushed builds here : http://olamy.googlecode.com/files/hudson.war

Currently : maven2 build on master node doesn't work (under work !)

We need you for more testing and nice feedback (before merging this to master)

You can follow what's happened in the dedicated jira entry : http://issues.hudson-ci.org/browse/HUDSON-4988

Have Fun !
--
Olivier

[1] https://github.com/hudson/hudson/commits/main-maven3-support
[2] http://maven.apache.org/ref/3.0.1/maven-core/apidocs/org/apache/maven/project/ProjectBuilder.html


Categories: Olivier Lamy

Gwt Maven Plugin 2.1.0-1 Released

Olivier Lamy - Mon, 12/06/2010 - 21:31
The Gwt Maven Plugin 2.1.0-1 has been released.

38 issues has been fixed (full changelog).

New features :

* AppEngine Launch
* Css Interface Generator
* More Gwt compiler options : -compileReport, -optimize, -XsoycDetailed, -strict (see the mojo Compile Mojo)
* Compiler Report
* @RemoteServiceRelativePath annotation processing

To use it :

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.1.0-1</version>
</plugin>


Web Site : http://mojo.codehaus.org/gwt-maven-plugin/

Have Fun !
--
Olivier


Categories: Olivier Lamy

Gwt Maven Plugin 2.1.0-1 Staged

Olivier Lamy - Fri, 12/03/2010 - 16:19
Yeah ! The Gwt Maven Plugin 2.1.0-1 has been staged (and release vote started [1] )

Release Notes : http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11860&version=16878

Staging repo : https://nexus.codehaus.org/content/repositories/orgcodehausmojo-047/

Documentation site : http://mojo.codehaus.org/gwt-maven-plugin

What's new in this release : http://mojo.codehaus.org/gwt-maven-plugin/whats_new.html

If you have any trouble please load an issue in jira : http://jira.codehaus.org/browse/MGWT .

Have Fun and push a +1 !

[1] http://goo.gl/DeJue


Categories: Olivier Lamy

What's new in the coming Gwt Maven Plugin 2.1.1

Olivier Lamy - Fri, 11/26/2010 - 18:52
The coming Gwt Maven Plugin 2.1.1 will have new features.

This stuff is currently available as 2.1.1-SNAPSHOT in the codehaus repo : https://nexus.codehaus.org/content/groups/snapshots-group/

Running your application in debug mode with AppEngine Launcher

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.1.1-SNAPSHOT</version>
<configuration>
<server>com.google.appengine.tools.development.gwt.AppEngineLauncher</server>
</configuration>
</plugin>
</plugins>
</build>


See appengine-launcher

Css Interface Generator

See Css Interface Generator

More Gwt compiler options
-compileReport, -optimize, -XsoycDetailed, -strict (see Documentation )

Compiler Report
To have link to the Gwt compiler report in your Maven generated web site
See Compiler Report

Full changelog

Do not hesitate to test and send feedback.
Thanks !


Categories: Olivier Lamy

Sopera opens the development center in Ireland

Sergey Beryozkin - Thu, 11/18/2010 - 11:13
Last week myself and my colleague Colm stepped in into an office that Sopera secured for us in Dublin, Ballsbridge. We can nearly see the IONA Building we used to go to not that long ago from our place. The view from its window is really nice.

We are delighted. Being able to get to the office and work with and talk to your colleagues but also work from home on a given day is the ideal situation for software engineers and it really does feel it is the beginning of the new journey for us, with the only way ahead from here - onwards, especially now that Sopera has been acquired by Talend.
Categories: Sergey Beryozkin

CXF Auto Redirect Feature in action

Sergey Beryozkin - Mon, 11/15/2010 - 18:08
I was working today on testing some CXF JAX-RS client code against Tomcat and Jetty servers. All was going well with Tomcat : after deploying a sample.war to Tomcat and doing :


WebClient wc = WebClient.create("http://localhost:8080/sample";
wc.getCollection(Book.class);
// print the collection


a collection of Books was printed in the console.

However this code stopped working once I deployed a sample.war to Jetty, using a Maven Jetty plugin. I spent some good few hours debugging it before I spotted that Jetty returns HTTP 302 to a "GET /sample" request with the Location header pointing to "http://localhost:8080/sample/", note the trailing slash.

So changing the code to


WebClient wc = WebClient.create("http://localhost:8080/sample/";
wc.getCollection(Book.class);


made it work for both Tomcat and Jetty deployments. One other option to deal with the redirects is to use one of the WebClient methods returning JAX-RS Response rather than a typed one, and check the status and then follow the new URI if needed.

But I found the following code working nicely in the end :


WebClient wc = WebClient.create("http://localhost:8080/sample";
WebClient.getConfig(wc).getHttpConduit().getClient()
.setAutoRedirect(true);
wc.getCollection(Book.class);
Categories: Sergey Beryozkin

Being at ApacheCon 2010

Sergey Beryozkin - Mon, 11/08/2010 - 17:48
I got a chance to attend to the Apache Conference in Atlanta last week thanks to Sopera organizing this trip. It was the first time I was at the ApacheCon, and it was an interesting and unique experience.

First, Sopera had a workshop during the first 2 days of the week, before the conference started, so it was a good opportunity for many of us in the OS team to meet each other and we had some interesting discussions along the way.

ApacheCon brings together an interesting mix of people, some of them having the commercial interest, some representing large commercial and government organizations adopting OS, and some working on OS projects because this is what they really like doing on their own time.

It was interesting to listen to some technical talks. And meeting new people and seeing the former colleagues I used to work with (with some of them I will be working again from now on :-)) was great. And of course, meeting CXF legends such as Glen and Benson was another highlight :-).
Categories: Sergey Beryozkin

Release Maven Gwt Plugin 2.1.0 (gwt 2.1.0 compatible)

Olivier Lamy - Fri, 11/05/2010 - 10:47
Hi Folks,The gwt maven plugin version 2.1.0 has been released.The major change is to be gwt 2.1.0 compatible.
Release Notes - Maven 2.x GWT Plugin - Version 2.1.0
New Feature
  • [MGWT-181] -Add support for GWT compilers -workDir option
  • [MGWT-190] - support GWT 2.1
  • [MGWT-218] - Support for setting the -runStyle parameter for gwt:test
Sub-task
  • [MGWT-191] - gwt:run runs Hosted Mode instead of Dev Mode for GWT 2.1.0.M1
Bug

  • [MGWT-110] - Generated interface not identical to interface generated by GWT tooling
  • [MGWT-111] - gwt:run - Multi-module projects with custom start page not well supported
  • [MGWT-118] - GWT Compile fails with IBM JDK
  • [MGWT-129] - Multi module projects doesn't work properly in HostedMode.
  • [MGWT-142] - java.lang.NoClassDefFoundError: com/google/gwt/dev/Compiler when running plugin on Mac
  • [MGWT-147] - GWT modules with inherited entry point are never compiled
  • [MGWT-149] - generateAsync fails with ParseException (ignoring servicePattern?)
  • [MGWT-151] - skip compile when model file not contain entry point.
  • [MGWT-152] - Incorrect documenation on the Maven site
  • [MGWT-155] - Documentation on GWTTesting is incorrect/Broken link
  • [MGWT-161] - gwt-maven-plugin does not work with spaces in project location on Linux
  • [MGWT-164] - Inheriting module does not inherit its <entry-point> or <servlet> definitions
  • [MGWT-165] - scanning for .gwt.xml files doesn't take into account all source roots
  • [MGWT-171] - ServicePattern is ignored
  • [MGWT-183] - Cannot compile a module that inherits a module with entry points
  • [MGWT-186] - Generic Interface is not generated correctly
  • [MGWT-187] - "utility module" detection is incorrect
  • [MGWT-189] - .class files get copied into WEB-INF/classes without package structure
  • [MGWT-198] - AbstractGwtShellMojo hides failure information when executing the compiler process
  • [MGWT-201] - Sources directories in inherited modules are ignored
  • [MGWT-223] - i18n fails under Eclipse with m2eclipse
  • [MGWT-228] - When running with GWT 2.1.0 the plugin require gwt-dev-<platform> jars
Improvement

  • [MGWT-62] - Possibly bind gwt:compile to the 'prepare-package' phase by default in 'war' projects (maven 2.1)
  • [MGWT-76] - Solution for multi module builds and hosted mode
  • [MGWT-88] - Add mergedWebXml parameter to MergeWebXmlMojo
  • [MGWT-128] - Allow specifying custom environment variables for run/debug goals
  • [MGWT-146] - Explicit setup mode setting
  • [MGWT-148] - Compile also when GWT module file has changed
  • [MGWT-154] - GenerateAsync generate files with unused imports
  • [MGWT-162] - Support for server=n
  • [MGWT-169] - support devmode for multiple modules
  • [MGWT-170] - Find source jars and add them to the classpath when executing the GWT compiler
  • [MGWT-172] - generateAsync suporting "com.google.gwt.http.client.Request" return objects
  • [MGWT-178] - No messages if a module doesn't contain entry points
  • [MGWT-180] - Add Option for bindAddress
  • [MGWT-194] - Update documentation for /war in GWT 2.0.x
  • [MGWT-195] - create documentation for 'comfortable GWT debugging'
  • [MGWT-225] - Update BCEL dependency to fix the broken pom.
Task
  • [MGWT-188] - Update FAQ re: "NoSuchMethodError"
Have Fun !
--
Olivier Lamy on behalf of the The Maven Team

PS : pushing open source release is fun The famous song :-)


Categories: Olivier Lamy

Open Source song :-)

Olivier Lamy - Mon, 11/01/2010 - 15:46
The famous french singer jcfrog has made a nice song on Open Source :-)
Have a look here : http://www.youtube.com/watch?v=CBHFnTlAJ4s
Check out the other one on twitter : http://www.youtube.com/watch?v=oetmdgPRyqw
I hope we will have one for ASF
Have Fun !
-Olivier


Categories: Olivier Lamy

Apache Camel 2.5.0 Released

Hadrian Zbarcea - Mon, 11/01/2010 - 04:34
The 2.5.0 release of Apache Camel is finally out. It is the result of some two and a half months of improvements since the last release in July. You can check the release notes for more details and give it a try.

The PMC is planning to focus now on releasing the 3.0 version of Camel in Q1 of next year. The 2.x version will continue to be actively improved for the foreseeable future (at least through 2011) and we plan to have another camel 2.x release this year.

To help planning the new 3.0 release the Camel PMC conducted a survey during the month of October. Many thanks to all who participated in the survey and made their voice heard. The results of the survey will be made public this week during ApacheCon. If you want to see the goodies coming in the 3.0 version, keep an eye on the roadmap.
Categories: Hadrian Zbarcea

Give us your headaches

Sergey Beryozkin - Wed, 10/27/2010 - 18:24
Have I already mentioned that I liked reading the Richard Branson's auto-biography ?

I honestly think it was a gem of a book which I picked up in the Gatwick airport on the way to Dublin from Minsk. That is a story about the life journey told with a lot of humor, filled with some absolutely hilarious accounts of various events and with some very serious thoughts about doing business and contributing to saving the humanity.

You might want to ask, what is it all to do with the web services or software development given this post is not marked with [OT] ?

During his student days, Richard set up the Student Advisory Centre which consulted students on all the issues they could have, free of charge. One of their slogans was "Give us your headaches". This centre still operates today.

I thought, when I was reading about it, that to some extent, this is what the OS business model was partly about. In OS we are working on projects such as CXF and we are determined to make it all work really well, without any headaches, in the most demanding environments.

The OS business model is partially about providing the insurance that customers will experience no headaches when running such OS-driven projects in their productions. In fact this model has been proven very successful, by such top companies such as RedHat for example.

Are you considering to start using CXF but a bit concerned what will happen further down the road with all the OS development going on into it ?

Give us your headaches :-)
Categories: Sergey Beryozkin

CXF : Here we come !

Sergey Beryozkin - Wed, 10/27/2010 - 17:59
I'm happy to confirm that after a short break I'm going to have a chance to resume working on CXF and its JAXRS project in particular.

I'll join Dan and the rest of the Sopera OS team and we will be determined as ever to bring you the best production-quality web services framework around.

And with your help we will make the CXF users and dev lists the "hippiest place to be", the phrase is borrowed from a Richard Branson's auto-biography.

CXF won't be the only effort we will focus in Sopera but it is going to be one of the main ones.

Stay tuned.
Categories: Sergey Beryozkin

Goodbye JBoss

Sergey Beryozkin - Wed, 10/27/2010 - 16:57
So after less than 6 months after starting to work for JBoss I decided to quit and accept an offer from Sopera. In hindsight, I'm thinking that talking about the career publicly is not always the very best idea - spending such a short period of time at one of the leading company in the industry is not something that will improve my CV.

Back in April/May I was indeed looking forward to that great opportunity and it was not a stop-gap measure by any means. But CXF and CXF JAXRS are calling me back - it is next to impossible to resist. I'll blog about it next but this post is about JBoss and I'd like to talk about it a bit.

Just 6 months ago I had a fairly vague idea about what JBoss were doing, apart from knowing that they were part of RedHat, that it was an application server and that their JBossWS project was providing a CXF JAXWS integration option. And of course I knew about RestEasy.

In the reality, JBoss is a very live, active and progressive project, with a lot of very clever and innovative people working on it and who are really passionate about JBoss. And they have a very open and democratic environment with everyone being able to express their thoughts aloud.

I've promised in my previous post I'd link to various JBoss subprojects. Here are the links to some of them :

JBossWS : Web Service Framework for JBoss AS
RestEasy : JAX-RS implementation with various features
PicketLink : STS, etc
JBossTS : While many are saying that WS transactions support is next to impossible to provide this team just does it
HornetQ : Putting the buzz in messaging


As far as I'm concerned it is obvious I've given away the real opportunity with a great company. That said, the life is about many opportunities, and I'm about to pursue the new and exciting one, with the young and innovative company.

Goodbye JBoss, Hello Sopera !
Categories: Sergey Beryozkin

Apache Maven Site Plugin 3.0-beta-3 for maven 3

Olivier Lamy - Thu, 10/21/2010 - 12:13
The Maven team is pleased to announce the release of the Maven Site Plugin, version 3.0-beta-3 for Maven 3.This version is intended to be the version of the Maven Site Plugin for Maven 3.
The Site Plugin is used to generate a site for the project.
You should specify the version in the section of your project's POM:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-site-plugin</artifactId> <version>3.0-beta-3</version></plugin>
Release Notes - Maven 3.x Site Plugin - Version 3.0-beta-3

Bug
  • [MSITE-500] - Warning message about missing report plugin version shows null instead of plugin groupId:aritfactId
  • [MSITE-504] - Maven site fails to run due to non-report goals
  • [MSITE-505] - Unable to use SVN SCM wagon to upload a site
  • [MSITE-506] - Maven3 conflict with plexus-archiver
  • [MSITE-507] - report plugin doesn't have dependencies section coming from build section configuration
  • [MSITE-508] - attach-descriptor goals leaks file handlers, causing sporadic build failures when gpg tries to sign descriptor during release
  • [MSITE-512] - [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account

Task
  • [MSITE-513] - use release final maven 3.0 artifacts

Have Fun !-- Olivier Lamy on behalf of the The Maven Team


Categories: Olivier Lamy

Maven Selenium Plugin 1.1 (Maven 3 compatible)

Olivier Lamy - Mon, 10/18/2010 - 10:30
Hi,The Maven Selenium Plugin 1.1 version has been released.The most important fix is the Maven 3 compatibility !
ImprovementDon't miss to update the version in your pom
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>selenium-maven-plugin</artifactId> <version>1.1</version> </plugin>
Have Fun !


Categories: Olivier Lamy

Tomcat Maven Plugin 1.1 Released

Olivier Lamy - Sat, 10/09/2010 - 13:16
Tomcat Maven Plugin 1.1 has been released.
Site documentation : http://mojo.codehaus.org/tomcat-maven-plugin/.

Here the release notes :

Bug
  • [MTOMCAT-55] - Can't shutdown tomcat started with tomcat:run with fork=true
  • [MTOMCAT-57] - Secondary war files deployed with incorrect context path
Improvement
  • [MTOMCAT-63] - Make isWar() check consistent with MTOMCAT-23
  • [MTOMCAT-64] - Document how to change the Embedded Tomcat Version
  • [MTOMCAT-65] - Upgrade Tomcat to 6.0.29

Have Fun !


Categories: Olivier Lamy

Should you getIn or getOut?

Hadrian Zbarcea - Thu, 10/07/2010 - 03:37
From recent posts on the camel users@ mailing list there seems to be some confusion related to the use of getIn() and getOut() on a Camel Exchange. The question is relevant to developers who want to implement a processor and need to understand what should happen with the result of their processing. There is a wiki page that attempts to explain the usage of the two methods, but sadly that mostly fuels the confusion than clarifies anything. The page will be corrected soon, you may see a newer, corrected version, but at the time of my writing current is version 4 (which was recently improved and a bit more accurate than version 2).

So the idea (deeply rooted in some older discussion about what the Exchange api should be) is that you should use getIn(), because, uhm, "it's often easier just to adjust the IN message directly" and that has something to do with MEPs and a poor relative of camel called JBI. Before we get into more details, the reality is much simpler, using getIn() or getOut() has not much to do with MEPs and you should do what's right, which is process the in message (most likely), generate an out message (if needed) or update the in (sometimes).

Camel is one of the integration space best frameworks (I'd think the best, but then you'll say I'm biased) and it is true that it was influenced by JBI. Some of its roots are in Apache Servicemix and three Camel PMC members have been at some point involved in drafting the jbi specs: James with jbi 1.0 and Guillaume and Bruce with jbi 2.0. One of the main goals of Camel is to make integration simpler and more intuitive than jbi (and complement jbi in some cases).

Now, just because the jbi 2.0 was inactive for a good while doesn't mean that the Camel Exchange API is broken as some may say. In particular, the jbi 1.0 spec says that "The message exchange model is based on the web services description language 2.0 [WSDL 2.0] or 1.1 [WSDL 1.1]" (jbi-1.0-fr-spec, pg 5) and WSDL is pretty much alive and kicking. Then there is the discussion about the MEPs, which is 100% correct and 100% irrelevant. The reason is that the MEPs refers to the route not what happens within a particular Processor. You could use the exact same Processor on routes that are in-only or in-out.

The concept though is much older than WSDL also. When implementing a function one would pass arguments and return a value. Think of a process() function that gets a Message as an argument and returns another Message.

Message process(Message in) throws Exception;

So the question then becomes should I return the same in Message or another one? Well, that's entirely up to you and what the process() function is supposed to do. The only thing that happens in Camel is that we wrap the two messages in an Exchange (plus the exception and some other metadata, because we needed an execution context) and that's what we pass to process(), so the function signature becomes:

void process(Exchange exchange);

... which is pretty much the definition of the Processor interface. Or you can think of the exchange as being the stack frame prepared for the function execution in the first case (not much of a stretch).

One important thing to note, that may clarify a bit the confusion is that getOut() will not really return the out message, but rather will lazily create an empty DefaultMessage for you (on the first call, and the existing out message on subsequent calls). Therefore there is no out message until you create it by calling getOut(), the assumption being that you called getOut() with the intention of returning the new distinct Message resulted from your processing. As a consequence the assertion getOut() ==null will always fail, because the getOut() call will create a message. To address that there is a hasOut() method in Exchange you could use to tell you if you created the out message (in case you don't know that already).

As you probably know, what camel does is to pass an Exchange along the processor chain in a route and pass the out message of the previous processor as an in message for the next. If the previous processor did not produce an out (there are such processors, a logger for example, logs the in, but does not produce an out), then pass the previous in as an in message for the next processor. During its lifetime, an Exchange starts with an in, goes down the processor chain, outs are created and they replace the ins and the old ins are lost in history. And here's where the mep comes into the picture. If the route is in-out, at the end of processing chain, the last message in the exchange is passed back by the consumer to the caller, otherwise the last message is simply ignored (with an in-only mep, the caller is not waiting for an answer).

A problem faced by users is that if they call getOut() and produce a new message, the headers from the in message get lost (well, the whole message gets lost). One thing to know is that if one needs to access some value at different points during processing, the Exchange has a property map. Objects in that map stay with the Exchange, unlike headers that are tied to messages (and probably have no semantics outside the message). As we saw, messages come and go during processing. Exchange properties don't. Now if you want headers to be preserved, you probably have a very specific processor, that can only exist in particular places in a route and make heavy assumptions about the type of in message they receive. If that's the case, yes, you probably only need to slightly modify the in message and since you did not create an out the modified in will be passed further down the route. If you need to update a header you set on a previous processor (such as a timestamp) but don't really rely on the in message per se, you might consider using exchange properties instead of headers. Consider also that even if you modify the in message to preserve the headers, other processors down the route may produce an out (and hence replace the current in) anyway so headers could still get lost down the route.

That's pretty much it. Let's take a look at a few examples. A throttler processor will most likely not care about the in nor generate an out, it will only introduce a delay in processing (which may be adaptive and may depend on a header or property). A profiler processor will probably update timestamps in exchange properties, again ignoring the in, not producing an out and couldn't care less what the exchange pattern of the exchange is. A logger processor will log the in, won't produce an out, mep is again irrelevant. A crypto processor (partial message protection) will use credentials from the exchange properties to alter parts of the in message, sign/verify/encrypt/decrypt (may be either headers or parts of the body), will likely not produce an out. A proxy processor that allows you to integrate some legacy technology into a camel route, will use the input, format it according to the needs of the technology, use the proprietary api, get the result and put it as a new out on the exchange, possibly along with specific headers. A processor that fetches records from a database will most likely put the result set into a new out message as well. So again, should you use getIn() or getOut()? Things depend much on what your processor needs to do.

Don't do what's easy, do what's right!
Categories: Hadrian Zbarcea

Take the Apache Camel Survey!

Hadrian Zbarcea - Wed, 10/06/2010 - 05:18
A new Apache Camel release is just around the corner (version 2.5.0) and recently we announced taking the 1.x branch off life support. Therefore the race is on to deliver a new major version, Camel 3.0 early in Q1 2011 (see roadmap).

To that end the Camel PMC worked on a survey last week intended to get a better feel of how the community is using Apache Camel, what the major issues are (documentation, I know) and what improvements and new features you want to see in the next releases. The survey, sponsored by Sopera, is anonymous and its results will be made public and used by the committers to create a remarkable experience for you.

We care about you, our users, and, from the feedback we got so far, I am impressed by how much you care about us back. Your voice is important and it's one sure way to move the features you care most about higher on our priority lists and busy schedules. Needless to say, feel free to reach out to us on the mailing lists and IRC channel with questions and suggestions.

So please take the survey (http://s.apache.org/camel-survey) if you didn't already and receive our gratitude for your continued support.
Categories: Hadrian Zbarcea

Hudson Maven Dependency Update Trigger : First Hudson plugin with maven 3 apis

Olivier Lamy - Sun, 10/03/2010 - 09:22
I have made the first release of the Maven Dependency Update Trigger hudson plugin.
Wiki page here : http://wiki.hudson-ci.org//x/jgfDAg
This plugin will check according to the cron expression if your SNAPSHOT dependencies has been updated and (optionnaly) check if your plugins SNAPSHOT has been updated too. And trigger a build if necessary.
This is usefull if you have project dependencies not in the same hudson instance or using an other continuous integration tool.
Note this plugin use maven 3 apis to build maven projects and check dependencies.
Hudson 1.379 is required to use this plugin.



So have fun and give me feedbacks.


Categories: Olivier Lamy

Use maven 3 apis in a hudson plugin

Olivier Lamy - Wed, 09/22/2010 - 22:56
Using maven 3 apis in a hudson needs to change classLoader hierarchy as hudson load some old maven artifacts in the parent classLoader.
So the solution is to use a child first classLoader.
This new classLoader has been introduced in hudson 1.378. (see HUDSON-5360).
So you can now use it to made your plugin dependencies win on hudson core classLoader.
Some steps are needed.
Configuring your hpi plugin

<plugin>
<groupid>org.jvnet.hudson.tools</groupid>
<artifactid>maven-hpi-plugin</artifactid>
<version>1.54</version>
<configuration>
<pluginFirstClassLoader>true</pluginFirstClassLoader>
</configuration>
</plugin>

So now your pluginWrapper.classLoader will be of type PluginFirstClassLoader.

// pluginId is project.artifactId from your plugin pom
PluginWrapper pluginWrapper = Hudson.getInstance().getPluginManager().getPlugin( pluginId );
PluginFirstClassLoader pluginFirstClassLoader = (PluginFirstClassLoader) pluginWrapper.classLoader;


Now everthing is ready but some other tricks are needed :-)

Create a PlexusContainer (note you must use the new "plexus-guice" bridge).
This means you need the following dependency :

<dependency>
<groupId>org.sonatype.sisu</groupId>
<artifactId>sisu-inject-plexus</artifactId>
<version>1.4.1</version>
</dependency>

And very important you must exclude dependencies from the original plexus-container

<dependency>
<groupId>org.sonatype.aether</groupId>
<artifactId>aether-connector-wagon</artifactId>
<version>${aetherVersion}</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-container-default</artifactId>
</exclusion>
</exclusions>
</dependency>


To prevent this you can add an enforcer rule which will chech plexus-container-default inclusion

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0-beta-1</version>
<executions>
<execution>
<goals>
<goal>enforce</goal>
</goals>
<phase>validate</phase>
<id>ensure-no-plexus-container</id>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.codehaus.plexus:plexus-container-default</exclude>
</excludes>
<message>
ensure-no-plexus-container doesn't work anymore with maven 3 librairies. you have to add some exclusions.
</message>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>


How to create the PlexusContainer from the PluginFirstClassLoader :

private PlexusContainer getPlexusContainer(PluginFirstClassLoader pluginFirstClassLoader) throws PlexusContainerException {
DefaultContainerConfiguration conf = new DefaultContainerConfiguration();
ClassWorld world = new ClassWorld();
ClassRealm classRealm = new ClassRealm( world, "project-building", pluginFirstClassLoader );
// olamy yup hackish but it's needed for plexus-shim which needs a URLClassLoader and PluginFirstClassLoader is not
for ( URL url : pluginFirstClassLoader.getURLs() )
{
classRealm.addURL( url );
LOGGER.fine( "add url " + url.toExternalForm() );
}
conf.setRealm( classRealm );

return new DefaultPlexusContainer( conf );
}


Then set the current Thread classLoader (don't miss to restore the original one in a finally statement

PlexusContainer plexusContainer = getPlexusContainer( pluginFirstClassLoader );

Thread.currentThread().setContextClassLoader( plexusContainer.getContainerRealm() );


Now you can play with maven 3 apis

ProjectBuilder projectBuilder = plexusContainer.lookup( ProjectBuilder.class );


A first sample is the plugin called : maven-dependency-update-trigger
: sources and Wiki Page (under construction :-) )
You must have a look at the dependencies used.

The plugin will check your project according to a cron expression and schedule a build if a snapshot dependency has changed (dependency and plugin).

It will be released as son as hudson 1.378 will be released.

Note : hpi:run doesn't work yet for this plugin as it needs some changes in the hpi mojo to handle the new PluginFirstClassLoader.


Pages

Subscribe to Talend Community Coders aggregator