Colin Sampaleanu (Spring Framework, Interface21) brought again the topic about how to handle optional dependencies in Maven, what’s the best way, how to apply it,… You can read the thread How are people getting around the lack of custom scopes?. If you are too lazy and don’t want to reason you can skip to the end where you can find the solution for that problem under Maven 2.

The example he provides is Spring Webflow, currently packaged completely in an only jar, with some core dependencies always needed, some only needed when used with Spring MVC, some only with JSF, and some only with Struts.

While the idea of packaging a bunch of classes in one jar can be handy when you copy it manually I see more cons than pros:

• Almost everybody uses a tool that will deal with several jars with no problems
• Build time checking. If you include more classes than expected nothing prevents their use. This is a huge source of problems. My experience tells me that policies that can’t be enforced don’t succeed.
• Component Oriented design, if you find yourself including many dependencies in your pom is like importing a lot of stuff in a java class, not a great idea.
• With a transitive dependency tool like Maven you won’t need to add more than a few dependencies, eg depending on spring-hibernate3 automatically adds for you spring-core, spring-beans, spring-aop,…
• In fact the Spring guys gave a step in this direction in 2.0, splitting spring-hibernate (depending on hibernate 2 and 3) into spring-hibernate2 and spring-hibernate3, or spring-orm in different jars for each ORM implementation (JDO, Toplink,…)

Here you can see as example some of the problems that I found thanks to
Maven in the Spring Framework build, that can be found in the chapter Converting existing Ant builds in the book Better Buils With Maven, that I filed in the Spring Framework issue tracker.

• SPR-1704
• SPR-1642
• SPR-1640
• SPR-1575
• SPR-1174

It’s also worth to say that Acegi Security System for Spring has been building happily with Maven 1 for far more than a year and now is switching to Maven 2. Spring Rich Client is also building now with Maven 2.

If you still are not convinced about splitting your jars in small components based on your use cases (bad for you), here is the work around in Maven:

• Create a pom for your whole jar (spring-webflow), with all but core dependencies tagged as optional. You can build the jar with this pom.
• Create a pom for each of the configurations, setting packaging as pom, eg spring-webflow-spring-webmvc, spring-webflow-struts, spring-webflow-jsf
• To that poms add a dependency in spring-webflow and the required deps for that configuration
• spring-webflow-spring-webmvc -> spring-webflow, spring-webmvc
• spring-webflow-struts -> spring-webflow, struts
• spring-webflow-jsf -> spring-webflow, jsf
• In your application now you can depend on any of the projects in point #2 setting type to pom inside the dependency tag.

Hope you choose the right way and don’t go into the dark side 😉

No es broma, si eres estudiante Google te puede pagar 4500 d�lares, seleccionando una de las propuestas de un projecto open source y apunt�ndote a Google Summer of Code, y si superas el proceso de selecci�n durante el verano Google te paga.

He a�adido unas propuestas a la p�gina de la fundaci�n Apache, que me interesan especialmente, relacionadas con Maven, aunque tambi�n se aceptan las propuestas de estudiantes. Lee las preguntas frecuentes en la p�gina de Google y date prisa que se acaba pronto!

Adem�s tras esta experiencia est� la muy probable posibilidad de trabajar para compa��as relacionadas proyecto open source, al menos es el primer lugar donde yo voy a mirar por nueva gente. No es una mala forma de hacer el proyecto de fin de carrera, o la tesis, y conseguir una experiencia que te ayudar� a conseguir un mejor trabajo y reconocido a nivel mundial.

Are you student? interestend in getting paid 4500$ for a summer job?

Join Google Summer of Code, choose one of the proposals (or propose yourself) from any open source project, and apply. I’ve added some proposals about Maven I’m interested in to the Apache Software Foundation list of projects. Be sure to read the FAQ and hurry, it ends soon!

We’ve reached already the 5000 dowloads since the book was released officially, which was less than two days ago!

It finally went out! As I mentioned some weeks ago, there is a book about Maven 2 made by core developers, John Casey, Vincent Massol, Brett Porter, Jason Van Zyl, and myself. I think this is what the Maven community was waiting for, and I’d like to thank Mergere for the opportunity of working on it and the guts to make it available for FREE, like in free beer ;).

You can download Better Builds With Maven, and the chapters code (link is at top left corner).

I’d prefer a cover like this, but it didn’t pass the vote, nobody understands my sense of humor 😉

I have seen some projects that use their own Maven repository where they copy stuff from iBiblio and change it based in their needs, like changing pom dependencies. You should know that this is a really bad practice, let’s see

• if you happen to get that pom from ibiblio first for any of your other projects, Maven won’t get the one from that custom repo, as it’s already cached, and there’s no reason to redownload again
• if you happen to run first against that custom repo, that custom pom will get downloaded to your cache, thus preventing all the other projects to use the right pom from iBiblio

To sum up, if you need to use your own repo you have to create your own groupId (com.acme) and deploy there all your stuff as other people’s stuff that you customize

I know I don’t blog too much lately, I try to keep my social life away from the computer, but maybe too much ;).

Maven 2.0.4 was released, not too long after some regressions were found in 2.0.3. A lot of bugfixes were already included in 2.0.3. All the bugs I found most annoying are already fixed.

Fresh news for today are the inclusion of  in the sandbox of two libraries that will allow you to use remote repositories based in webdav and a several Source Control management systems, both to get your dependencies, deploy them or deploy your site.

Let’s make some samples,

• do you want to deploy your jars to a repository in a webdav server instead of ssh based? you can
• do you want to deploy your site using webdav, for instance to a running tomcat server? you can
• do you want to store your private remote repository in Subversion, CVS, Perforce, and more? you can
• do you want to deploy your site to http://dev.java.net (which involves checking into a CVS folder)? you can

This is accomplished using two implementations of Wagon, wagon-webdav, which uses Jakarta slide under the covers, and wagon-scm, which uses Maven-SCM. Wagon is the layer that Maven uses to access remote serves, both artifact repositories and site deployment. It can be used outside of Maven and it’s a good alternative to commons-vfs, the one I talked about some time ago.

Of course this is still in the sandbox for a reason, and as it matures we’ll move it out from there, just a matter of user testing and improving documentation.

And last but not least important I’m gonna announce in a few days something that the Maven users where waiting for a long time. If you were at The Server Side Symposium in Vegas and stopped by the Mergere booth you already know, for the rest, you’ll have to wait a bit, or maybe just be good using search engines 😉

I discovered this cool utility, jaranalyzer. It analyzes a bunch of jars and gives you either an xml or a dot file, that you can process with Graphviz.

Below is the graph generated for spring 2.0-m2 after removing transitive edges

And this is for hibernate 3.1.2 + annotations 3.1beta8 without the transitive edges too

I think this makes more clear why the need of dependency management (aka avoid the jarmageddon 😉 ) I hope people check this tool before making upload bundles.

Some interesting facts:

• circular dependencies, like ehcache and hibernate2, a good chicken and egg problem. Also jaxen-dom4j and jaxen-jdom
• spring modules for database management (jdo, jpa, hibernate2, hibernate3) depend on spring portlet module (curious, isn’t it?).
• spring support depend on different, unrelated, stuff like quartz, BEA’s commonj_twm, ehcache,… I’d say chances are almost 0% that you use two of them at the same time
• several jars, like commons-logging, depend on clover. This is clearly an error caused because clover bundles classes from log4j and other projects, beware of the evil bundling!!! follow the DRY principle also in your jars.

I wasn’t able to find a good alternative to Graphviz implemented in pure Java, so you need to have it installed to generate the graphs from the dot files.