My slides are available online.
]]>If you're interested to meet up register on the Facebook event.
We have also organized a joint XWiki and Maven tech meetup on the 9th of October, at Terracotta. Indeed Terracotta has been extermely kind not only to lend us a room but also to cater for some pizzas and snacks :) Thanks Terraccotta!
The address is:
Terracotta Inc. 650 Townsend St. Suite 325 San Francisco, CA 94103 USA +1 415 738 4059
Jason Van Zyl, creator of Maven will be there too!
I hope to see a lot of you there!
]]>I'm also happy to report that XWiki (the company and open source project I work for) is a Sonatype Partner. I'd love to see Maven products built on top of XWiki. I think XWiki's flexibility makes it an ideal platform for building those products and at the same time empowering them with collaborative features. In the near future I'll work closely with Jason and his team to integrate XWiki and Maven and hopefully we'll see some cool things out of this.
Well done guys and long live Sonatype!
]]>"Better Builds with Maven”"
- is a comprehensive 'How-to' guide for use with Maven 2.0.4 and later
- is available free of charge and includes supporting sample code
- covers how to use Maven 2.0 to better manage the build, test and release cycles associated with software development
- is written for beginning and intermediate Maven users
- is authored by Maven experts
- Jason Van Zyl, Chief Architect and founder of Maven
- Vincent Massol, author of "Maven: a Developers Notebook"
- with chapters and key content and code contributions from leading Apache Software Foundation Maven Project members: Brett Porter, John Casey and Carlos Sanchez.
- is published by Mergere, Inc
Content Includes:
- An introduction to Maven 2.0
- Creating, compiling and packaging your first project
- Best practices and real-world examples
- Creating J2EE builds and using J2EE models
- Extending builds through plugins
- Monitoring source code, testing, dependencies and releases
- Leveraging repositories, Continuum for continuous integration and transitive dependencies
- Converting existing Ant builds to Maven
Download a free copy at http://library.mergere.com.
I hope this book will help boost Maven2's adoption.
]]>I guess it depends on the definiton of "successful". My definition of a successful OSS project is:
If we go by point 1, I think that the main 2 projects I have started (Cactus and Cargo) are not doing too bad. Cargo is still new but it seems to be on track and its user base is growing very quickly.
However on points 2 and 3, I'm not so sure I'm doing well. Mind you, Cargo has quite a lot of committers (growing every week!) and they're all doing a great job. I'm just thinking about the level beyond (look at the activity on the Maven project, Spring or other projects as an example of what I mean). Cactus is a bit different as it's now a mature project, so let's focus on Cargo. Of course it could be that these project domains are narrow and thus do not interest lots of developers. This is probably true but I don't think this is the only issue. I have the feeling that some of the reasons could be:
On the other hand, I feel that not doing any one of these points will hamper Cargo's user adoption...
Or maybe I'm completely wrong on all points above and this is just me fantasizing!
I'm really interested to know what you think and if this is something other OSS committers/contributors have noticed too. I've given the example of Cargo but really this is a general discussion on how to best manage an OSS project.
]]>I'd like to quickly demonstrate how to use the new Maven 2 plugin on 2 use cases (more samples can be found here):
Create a Maven 2 project and put the following configuration in your pom.xml file:
[...]
<packaging>war</packaging>
[...]
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<container>
<containerId>tomcat5x</containerId>
<home>c:/apps/jakarta-tomcat-5.0.30</home>
</container>
<configuration>
<dir>${project.build.directory}/tomcat</dir>
</configuration>
</configuration>
</plugin>
</plugins>
</build>
To generate your WAR, start Tomcat and deploy the WAR in it, simply type: mvn package cargo:start. That's all! Do you want to do the same in, say, Orion 2.0.5? Simply change tomcat5x with orion2x and the home
element to point to where you have installed Orion 2.0.5. You don't have Orion on the machine running the build? No issue, simply replace <home> with:
<zipUrlInstaller>
<url>http://www.orionserver.com/distributions/orion2.0.5.zip</url>
</zipUrlInstaller>
Orion 2.0.5 will then be automatically downloaded and installed the first time you run your build.
Let's imagine you're using the same project as above but this time you'd like to start Jetty and make it point to your webapp directory (i.e. src/webapp) so that whenever you make a change to your webapp's sources Jetty
automatically picks it up and serves it. See Brett's nice blog post on this. Simply modify your pom.xml as follows:
[...]
<packaging>war</packaging>
[...]
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<!-- No container specified thus it'll default to Jetty -->
<configuration>
<dir>${project.build.directory}/jetty</dir>
<deployables>
<deployable>
<!-- Override location to point to the exploded webapp.
Otherwise it'll deploy the generated WAR. We want
to ensure that jetty reloads any change made to the
webapp source tree... -->
<location>${basedir}/src/main/webapp</location>
</deployable>
</deployables>
</configuration>
</configuration>
</plugin>
</plugins>
</build>
Then open a shell prompt and type mvn cargo:start. Jetty will start and monitor your webapp's dir for any change (Note that the same can be achieved using other containers too).
If you're interesting in learning more, check the documentation and join us on the Cargo mailing lists.
]]>The Google Summer of Code is now over. I've had the pleasure of being a mentor for Codehaus. More specifically I've mentored the following projects:
The SOC was good. It has boosted the open source community quite remarkably (even though it has also probably put some strain on it...). Out of all the students I've mentored I think 2 or 3 of them (out of 6 initially) will continue to work on the open source project they've participated to. That's a 30%-50% ratio and I'm very happy about it. Thanks Google for making this happen!
]]>I have presented From Maven 1 to Maven 2 which went well. There were about 60-70 people in the room, all Maven 1 users (to be expected for such a talk) and a few (about 5) Maven 2 users.
Update 2005-09-28: Kito has blogged about JavaZone 2005 and has uploaded some nice pictures.
]]>For example, imagine that you have some integration tests in your project's test directory and that you need, say, Tomcat 5.0.30 to run
them. You'll need to start the Tomcat container before the test:test goal kicks in. Do this by writing a preGoal in your maven.xml:
<preGoal name="test:test">
<ant:mkdir dir="${maven.build.dir}/tomcat"/>
<attainGoal name="cargo:start"/>
</preGoal>
You'll need to provide Cargo configuration data in your project.properties or build.properties file. For example a minimal configuration would be:
cargo.containers = tomcat
cargo.container.tomcat.containerKey = tomcat5x
cargo.container.tomcat.homeDir = C:/apps/tomcat-5.0.30
cargo.container.tomcat.config.hint = standalone
cargo.container.tomcat.config.dir = ${maven.build.dir}/tomcat
cargo.container.tomcat.config.standalone.servlet.port = 8180
Alternatively you can ask the plugin to automatically download and install Tomcat for you (it'll download it only once), by specifying:
cargo.containers = tomcat
cargo.container.tomcat.containerKey = tomcat5x
cargo.zipUrlInstaller.tomcatinstaller.installUrl = http://www.apache.org/dist/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.zip
cargo.zipUrlInstaller.tomcatinstaller.installDir = ${maven.build.dir}/installs
cargo.container.tomcat.zipUrlInstaller = tomcatinstaller
cargo.container.tomcat.config.hint = standalone
cargo.container.tomcat.config.dir = ${maven.build.dir}/tomcat
cargo.container.tomcat.config.standalone.servlet.port = 8180
As you may have noticed, in our example above we've reused the existing Maven Test plugin which looks for test sources in ${pom.build.unitTestSourceDirectory}. With this strategy
you'll need to create a separate subproject for running your integration/functional tests in order not to interfere with pure unit tests that you may already have in ${pom.build.unitTestSourceDirectory}.
If there's a strong demand, we may consider adding a cargo:test goal in the future that you look for tests in, say, src/test/cargo by default (leaving src/test/java for unit tests).
Please note that there's also an alternative which is to start the Container directly from your unit tests.
If you find Cargo interesting, please come and help us on the Cargo mailing lists. There are lots of different ways you can help: trying Cargo on containers, implementing new containers (for example, JBoss, JOnas, WebSphere, etc), discussing new ideas, letting us know what new features you'd love to see, etc.
]]>The major changes from Cargo 0.4 to 0.5 are:
Detailed release notes are available on the download page.
Here's an example of how to use Cargo from Java:
Container container = new Resin3xContainer();
container.setHomeDir("c:/apps/resin-3.0.8");
Deployable war = container.getDeployableFactory().createWAR("path/to/simple.war");
container.getConfiguration().addDeployable(war);
container.start();
// Here you are assured the container is started.
container.stop();
// Here you are assured the container is stopped.
Here's an example using the provided Ant tasks:
<cargo-orion2x homeDir="c:/apps/orion-2.0.3" output="target/output.log"
log="target/cargo.log" action="start">
<configuration>
<property name="cargo.servlet.port" value="8180"/>
<war warfile="path/to/my/simple.war"/>
<ear earfile="path/to/my/simple.ear"/>
</configuration>
</cargo-orion2x>
And here's an example using the Maven plugin:
// To run it:
maven cargo:start
// To configure it, add the following in a Maven properties file:
cargo.containers = myTomcat
cargo.container.myTomcat.containerKey = tomcat5x
cargo.container.myTomcat.homeDir = c:/apps/jakarta-tomcat-5.0.30
cargo.container.myTomcat.config.hint = standalone
cargo.container.myTomcat.config.dir = ${maven.build.dir}/myTomcat/config
cargo.container.myTomcat.config.standalone.servlet.port = 8180
Enjoy!
]]>
javasvn.jar from the TMate JavaSVN web site. You need version 0.8.0 or later (I've used 0.8.0). The reason is that there is a new property named javasvn.ssh2.key that has been added as a hack for getting the Subclipse plugin for Eclipse to work with svn+ssh... Drop the jar in [IDEAHOME]/plugins/svn4idea/lib, replacing the existing jar of the same name there.[IDEAHOME]/bin/idea.bat file to add the javasvn.ssh2.key system property: IF "%IDEA_JVM_ARGS%" == "" set IDEA_JVM_ARGS= [...] -Djavasvn.ssh2.key=/path/to/your/private/key.Enjoy! That should please all the Codehaus hausmates... :-)
]]>Note: There is also an article and a discussion thread on TheServerSide about this inititative
Here's a new idea for an open source project I'd like to start. It could be called CCI (Container Client Interface). It would aim at providing a simple Java API to start/stop/configure/deploy Java containers (In the first version the goal would be to support J2EE containers). This Java API could then be used by lots of other projects (Ant tasks, Maven plugins, IDE plugins, Cactus, etc).
The inspiration comes from the Cactus project, which already provides an extensive API to perform such tasks. The goal is to refactor the Cactus Ant API, remove anything related to Cactus and make it a standalone project called CCI
Here's an integraton test showing what the API could look like:
public void testStartWithOneWarDeployed()
{
Container container = new Resin3xContainer();
container.setHomeDir("/apps/resin-3.0.8");
container.setPort(8080);
container.setInstallDir(new File("target/resin3x"));
WAR war = new WAR("src/testinput/simple.war");
URL pingURL = new URL("http://localhost:" + PORT + "/simple/index.html");
war.setPingURL(pingURL);
container.addDeployable(war);
ContainerRunner runner = new DefaultContainerRunner(container);
runner.start();
assertTrue("Container not started yet!", new HttpUtils().ping(pingURL));
runner.stop();
assertFalse("Container not stopped yet!", new HttpUtils().ping(pingURL));
}
As you can see there are several main Objects/Interfaces:
started without a container runner, the container runner provides advanced
feature like starting the container in a different thread, verifying if the container is already started, waiting till the container is started,
waiting till the container is stopped, etc.Note that the ping URLs are the URLs that will be pinged by the ContainerRunner object to ensure the container has finished
starting. Thus, after container.start() has finished executing you can be sure the container is started
and the archives have been deployed and are ready for servicing requests. A better solution in the future will be to use
JMX to ensure the container has finished starting. However, all containers do not yet support this feature.
A shorthand code version to start Resin 3.0.8 could look like:
Container container = new Resin3xContainer("/apps/resin-3.0.8");
container.setInstallDir("target/resin3x");
container.addDeployable(new WAR("src/testinput/simple.war"));
container.start();
This is just a taste of what he CCI API could look like. Let me know what you think!
]]>You can download the Maven Abbot plugin here.
Please note that this plugin was written jointly with Christian Blavier whom I thank very much for his help!
]]>In addition to this, I plan to continue fixing Cactus v1 bugs (albeit slowly...) and continue fixing bugs and adding enhancements to the Maven plugins I have started (changes, clover, abbot, etc).
If you're working on the same topics or if you're interested in contributing, please let me know!
]]>This will make it easier for them to improve it and keep it in sync with StatCvs-XML. This is possible thanks to the plugin:download feature of Maven 1.0 rc1/rc2 which allows users to easily install some external plugins. It is also possible to reference a plugin in your own project.xml as a dependency of type plugin.