Tag Archives: eclipse

Updated Multi-module Support for Maven Release Plugin

Last week Dennis started things moving to have another release of the Maven Release Plugin. The release process should start very soon, so please join us on dev@maven.apache.org to help test it!

This is certainly a nice one to have out the door, not only because of the length of time since the last release but because it fixes some important bugs (Subversion 1.6 support for starters), and improves multi-module support.

Having been bitten by the latter category myself very recently I took the opportunity to get a couple of changes in.

Support for flat directory multi-module projects

This highly requested support was actually added by Deng way back in May last year, but it was only recently that I started using the new version of the plugin and discovered a small corner case I jumped in and made a couple of improvements and fixes.

While I would always recommend using a typical hierarchical Maven multi-module project, there are a number of existing projects using the flat structure, particularly in non-Java environments. It’s good that the release plugin can now support anything with a common trunk.

This means that projects like the following will now release correctly (run from the parent directory):

.
|-- release-parent
|   `-- pom.xml
|-- release-module2
|   `-- pom.xml
`-- release-module1
    `-- pom.xml

Not requiring artifacts to be in the local repository before releasing

This controversial issue has popped up a number of times and proven to be a real nuisance in releases, where a multi-module project needed to be built locally before it can be released (including the preparation test, that makes 3 full builds!), or at best spouted a large number of warnings about missing dependencies on the artifacts it was yet to build.

In the end here we decided to revert to the original behaviour and accept the limitations that came with, while making the typical release faster and easier. The release:prepare-with-pom goal has been added to cater to the use case for which the dependency resolution was put in place originally. With this intended to be the 2.0 release of the plugin, we can stick to this behaviour going forward.

In the future, Maven 3.0 has added additional capabilities for plugins to operate with their modules without building them first, which will allow a unified and enhanced release:prepare goal once more, but in the mean time we’ve opted to put in place the best solution for the majority of Maven users today.

Advertisements

Eclipse and Maven: IAM and m2e complete creation review

 It’s a good day for Eclipse and Maven users, with two integration projects passing creation review to enter the incubator at Eclipse:

With both projects growing in maturity every day and each with their own unique features and focus, Maven users should look forward to two good choices and (hopefully healthy!) competition for some time to come.

I now use IAM’s seed project, q4e, every day without any issues – in fact, better Maven support is one of the reasons I switched to Eclipse from IDEA as my primary IDE. I find that the way I work at this point in time, switching regularly between a number of open source projects, that this became one of the most important features for me. Apart from seamlessly handling the changes to the POM in the background, the WTP support has been a great win for me.

WTP support added to Q for Eclipse

A nice surprise this morning was waking up to a message from Abel that he has implemented basic WTP support (for dynamic web applications only) in Q for Eclipse’s development version. I fired it up, imported my Archiva pom.xml files and it worked first go deploying to Tomcat.

Check out the screencast (mirror) he put together for a demo.

Eclipse Callisto: Success or Failure?

There has been a lot of positive press about Eclipse’s Callisto effort, heralding it as an “Agile Success Story”.

I’m surprised by the entusiasm of Eclipse users, considering it appeared to cause a delay to the release of Eclipse 3.2 itself, and didn’t deliver any new features.

It certainly seems to have been a success by their own measure – let’s face it, releasing and managing that much code and that many committers is no small task. It yet again proves that open source development can prove to be very effective.

However, I must admit that my original reaction was to ask why it was needed. This, surely, was a failure of modularity. I’m not particularly familiar with Eclipse platform development, but today I read that Peter Kriens, an OSGi evangelist (which is the component technology upon which Eclipse’s architecture is based), shares a similar sentiment.

Building componentised software is a funny thing. It’s conceptually very simple, but in practice it is usually quite difficult. It requires forethought, discipline and consistency. This is certainly something that is more difficult to achieve in large systems.

It is disappointing that Eclipse, the most popular IDE for Java developers right now, went down the path of the big bang release rather than working towards a goal of better modularity and offer those experiences and tools to other Java developers.

Like it or hate it, one of the reasons for Maven’s existence is to promote best practices, and we like to particularly focus on making component-based development easier. While I freely admit it’s not a problem we have come close to solving, I certainly think we’re moving in the right direction. Particularly in the area of transitive dependencies we’ve only seen these used widely in Maven for the last year and a lot has been learned in that time for the next installment.

Peter offers some possible reasons that Eclipse development has failed on this count. While the initial reasons make sense (at least to me as someone unfamiliar with PDE development), he then moves on to the OSGi purist’s favourite sport of beating on Maven’s dependency model.

“I hate to bring it up because I feel like a zealot, but obviously the
require bundle is a clear symptom of this world view. Require bundle is
the transitive dragnet of software. It is easy to use and you are
likely to catch the code you need. However, just like a real dragnets
you catch lots of fish you do not need. Worse, due to its
transitive nature that stuff in your net is connected to lots more
stuff you do not need, ad nausea. Look at Maven, it uses a similar
concept and has to download about 30 Mb of software before it can build
your “hello world” that has no dependencies except that is build with
Maven.”

So, first to correct some facts: Maven downloads just 2.7Mb of software to create, compile, test and package it’s “Hello World”, all of which is Maven plugins and dependencies. This is simply because Maven chooses not to distribute everything with the original download like Eclipse does, and has nothing to do with how the application itself chooses to select it’s dependencies.

For those unfamiliar, OSGi and Maven aren’t really similar technologies, nor are they in any way mutually exclusive. Maven is not an application execution framework (the closer analogy to this aspect is Maven’s container, Plexus), and it is certainly possible to build OSGi software using Maven. The area that they do overlap on is their dependency management capabilities (Maven at build time, and OSGi at runtime).

I’m not an OSGi expert, but here is my understanding of the differences between what is recommended in the blog and “require bundle”.

OSGi has two concepts in this regard for declaring a dependency: Import-Package and Require-Bundle (a recent addition to the OSGi spec, introduced in R4 last year). These reflect two units of use – a Java package, and an OSGi bundle (which can be though of as a total Java JAR). In Maven, the latter unit of dependency is the one used, though I believe that Maven (and others that are similar like Ivy) contain a number of features that can’t be used in OSGi’s bundle resolution.

In some ways, OSGi’s original approach certainly makes more sense – it ensures that the development model is not confused with the deployment model. You could put a package into 10 different combinations of JARs and the dependency model, I presume, behaves the same. However, this comes at great cost to the OSGi container implementor, with class loading gymnastics aplenty required, and it isn’t without impact on the developer.

There are a number of reasons I prefer Maven’s approach in general for dependency management and think it can help with modularity in Java development, but that’s a topic for another day 🙂

Back to Callisto, I’ll be interested to see what the near and long-term future holds. Has it helped plugin developers overcome version management issues? Will users expecting new features or additional stability from all the hype be disappointed? Will it improve delivery and stability, or will it become viewed as a painful roadblock?

Technorati Tags: