Continuum 1.0.3 is just around the corner, and I'm glad to mention a couple of really good improvements have cropped up recently.

Apart from the other long list of fixes so far, Emmanuel has been hard at work cleaning up the JDO code, resulting in massive speed improvements on the project page, as well as when queuing and executing builds.

Joel and Emmanuel also applied a new skin to the web interface, which you can see below. It's a lot more trim...

If you are interested in checking it out, the latest *development* build is available here.

This will be the stable release for a little while, as Continuum 1.1 rolls on with the conversion to WebWork2, a number of UI improvements to make it easier to use, integration of Geronimo's GBuild for distributed builds, and a number of other minor features.

I got back into doing a small feature enhancement for Continuum the other day. There was just one problem - after I built Continuum myself and ran it, my machine dropped to a blue screen of death and rebooted. (Yes, I'm back on Windows). This was pretty strange, as running Continuum that others built work just fine, and I really didn't have time to investigate it any further.

What to do? Pretty hard to develop if you can't run something you build. I don't really have a separate development server at my disposal right now.

Luckily, I'd gone VMWare image crazy just a few days before. I was testing out startup scripts, so I've used this information to create a stack of VM images - from my old versions of Windows I have lying around to Darwin and OpenSolaris. I also had the Ubuntu VM already downloaded from the VMWare site. Up until a couple of months ago I'd been using Ubuntu but I got tired of the network problems I was having, so it was good to have it around again.

That was the best solution I could come up with. I now have my home directory on the Ubuntu VM mounted over samba so I can edit like its local, run it in the VM, browse from my own browser, and debug using remote debugging like I'd have to anyway. The speed difference really isn't noticable - the only annoying thing is coordinating the capture of the pointer inside that window.

So, an odd setup, but actually quite a nice one if you like Linux from the command line and Windows for your apps (and drivers).

TestNG has been on my "must play with that some day" list for quite some time. Though I'm yet to write any significant tests with it, I was lucky to recently get some exposure to it to prod me along. This came in the form of support for Maven 2 contributed by Jesse Kuhnert, who not only did the initial patch but continually and patiently prodded me to look at it. I'd also listened to Cédric's JavaPosse podcast (or at least the first half, it seems to cut all the old ones off in the middle). I'd also started to get the IDEA plugin, assuming I got the right one
since the web page just said "get the plugin from the plugin list", and there are two, neither of which seem to be related to the project. The other was a generator and I now have the little TestNG logo in the configurations dialog, so I think I'm good to go.

The main reason I had put it off for so long was that I hadn't yet learned much about actually using TestNG and I knew I was going to have to make some changes to our test runner code called Surefire that has been around a long time and not evolved with the Maven 2 architecture. The patch for TestNG worked out of the box, but didn't (couldn't) integrate with other features.

There were some rough edges along the way. Since the patch was using a few internal APIs from TestNG that were public, upgrading through releases that had come since constantly broke the code. Might be time to introduce them to Clirr, another of my favourite new toys :)

However, the refactoring is now done and the TestNG code all revisited, and we've landed support that is comparable to JUnit (3) and the basic POJO test runner that is built in. It supports all of the fork modes (none, once for the whole suite, or fork for each test set), but more importantly integrates with anything else in the build lifecycle, such as Cobertura, without any additional configuration. This required very little TestNG specifics, so hopefully the basis is now there for other providers, as we start to see requests for JUnit 4 roll in. This is pretty satisfying, as we get to see the fulfilment of Maven's promised build knowledge reusability in action.

Once released, using TestNG tests is just a matter of including:

And from there you can run the usual mvn test, mvn cobertura:cobertura, mvn clover:clover, etc. Of course, you can customise them to enable things such as parallel test execution and using TestNG's XML suite definition files instead of the normal includes/excludes mechanism.

Another great thing is that you can try out TestNG immediately, even with your JUnit tests in place - the test runner finds each Java file and sets the JUnit flag for tests if appropriate so that they can be mixed in the directory with TestNG tests.

There are some instructions for those that might be game enough to test it before the release, but it is not quite there yet and there are still some minor bugs to be resolved. Hopefully, these won't hold it up for too long.

All in all, I think this is a great development and I certainly anticipate trying out TestNG on my current project. Just as soon as I get through all the mail I haven't read while I was playing around with it.

Technorati Tags: maven

Do yourself a favour - check out Jetty6.

It's been a while since I've done any form of webapp development, so I'm a bit rusty. The last place I worked at ran Tomcat servers (quite successfully), so development was naturally done against the same, with the occasional foray into Resin. But both suffered from the problem that fairly regularly, someone would get their dev environment misconfigured and spend some time troubleshooting where it had all gone wrong. It was inevitably something simple and completely unrelated to the NullPointerException or some other runtime exception that had popped up in the logs or in the browser.

With IDEA having Tomcat support built in, when I was starting to test the new webapp I naturally fell back to the old habit of firing that up. And then, no end of of problems:

• The Windows install of Tomcat omits all the startup scripts because you get a service, and you'd never want anything else, right? The IDEA support requires the scripts, so I grab the tarball instead.
• Errors on startup. SEVERE: Error filterStart. I know that means an exception in the filters I have configured. I'd like to know what it is. But the only way I'm extracting it is with a breakpoint and startup in debug mode (yes, this was my fault, but a little more helpful error message would be nice).
• Ok, everything working. Webapp redeploys most of the time, in about 15-20 seconds after making changes. Sometimes it needs a stop/start cycle to pick it up though.
• Somehow I manage to get a NullPointerException on startup when it was working before. Googling seems to indicate this is an invalid ROOT.xml, as I see a user getting reprimanded for not bothering to do validation on the XML. Sorry, but a NullPointerException is a bug, user error or not. I can't find the cause, the XML is valid and I've deleted IDEA's cache of the tomcat base to no avail.
  

• web resources read directly from the source tree, so you can edit, save, refresh without any deploying, etc.
• detects changes on a scheduled interval (I'm using 10 seconds), reloads the webapp if classes/descriptors/libs change. It reloads fast and I haven't seen it fall over on it yet.
• Very little setup required.

<plugin>

  <groupId>org.mortbay.jetty</groupId>

  <artifactId>maven-jetty6-plugin</artifactId>

  <configuration>

    <scanIntervalSeconds>10</scanIntervalSeconds>

    <contextPath>/</contextPath>

  </configuration>

</plugin>

mvn jetty6:run

Both Steve and Lars have been talking about how they think Maven repositories could be improved. Lots of good points, lots I agree with, lots I'd have already done if there were more hours in the day :)

I'm sure there are plenty of folks out there that have thoughts of their own on this topic. So, if that's you, how can you help?

There are a few different categories of people that can help in their own ways.

1. Open source library and framework developers and release managers - Even if you don't use Maven yourself, chances are your users do. Treat that support as importantly as any other feature request. You can submit your own Maven metadata, and even have your releases automatically published to the Maven repository system. Here are the instructions for both. It's also important to consider how your choice of dependencies affects your users. Putting all your functionality into one library is a distribution convenience, but can cause confusion for users about what the dependencies really are if they only use a part. Give them a choice. Produce libraries with discrete, independant functionality and clear dependencies (including clear version requirements), and produce the convenient bundled archive with the lot.
   
2. Developers interested in working on an application - participate in the Maven Repository Manager. We are building an application that does all the fun things like reporting on bad data, converting Maven 1.x repositories, and doing searches and browsing of the repository. You can comment on the brief feature and design notes. You can help us fix or implement issues in the repository manager, or in Maven itself. Vote for the ones important to you. Or discuss your ideas on dev@maven.apache.org with the other developers.
   
3. Users of the Maven repository - Help us fix metadata with usability problems. Even better, get the project you are using to buy into the problem and help fix it.
   

Seems it was the day of the 2.0's. Slightly overdue but worth the wait, Maven 2.0 is now out. See the release notes for a list of changes and new features. This is a significant improvement over 1.0.

Maven 2.0 Beta 3 is out.

There's plenty happening for Maven right now. This release is the second last beta as we approach the final release in the next couple of weeks. More of the original plugins are now available, and most boast improved functionality on top of the enhancements to the Maven engine itself. If you can't do it with this beta, you won't be able to do it with the final. It's bugfixes, better error reporting and doco from here on out.

The web site today sports a new look, much nicer than the boxish default look that has been around for the last couple of years.

We knew from Maven 1.0 that people didn't mind delving into the betas to find out what was going on, but given the bad experience many had with them last time around, I expected that it would be a bit quieter for Maven 2.0.

I was wrong.

We've had a huge amount of interest since the first beta was released - some using the ant tasks, some migrating from ant, some coming from maven 1.x. Hopefully we've given them a better experience this time around, with the releases being very consistent right through the betas.

Back in June, JavaOne was indicative of the current trend for Maven. Plenty of folks dropped by the Mergere booth to say hi and let us know how they were using Maven. Glassfish was announced and its use of Maven was a talking point, and the 2 BOF's we held were packed out. What I thought was a dud time turned out to have people sitting on the floor with about 90 people squeezing into the small presentation room on both occasions. And only once was that for the free beer.

Maven is popular. As the recent ONJava survey said - 19% of respondants use it. But its still the tool you'll love to hate - as one respondant to the same survey also said.

Maven 2.0 will probably be no different, but hopefully this time only due to the fear of change rather than any technical limitations. I hope to write more on that tomorrow.

Maven 2.0 Beta 2 is now out

Download: http://maven.apache.org/maven2/download.html

The main improvements in this release are:

* Bug fixes in the reporting API to allow the clover plugin to work in more scenarios
* Bug fixes in the artifact collector for version ranges
* Improvements to offline mode

This release is considered stable with a feature set comparable to Maven 1.0. Further betas and the final are expected to be backwards compatible, with a primary goal of bugfixes, usability improvements, and documentation.

The current roadmap is to make weekly beta releases to encourage faster turnaround for issues found by the
community.

This core release is independent of the plugins available. Further releases of plugins will be made separately.
See Maven Plugin Matrix for more information.

We hope you enjoy using Maven! If you have any questions, please consult:

* the web site
* the maven-user mailing list

For news and information, see:

* Maven Blogs

Now that we're into the end game for Maven 2.0, we'll be producing weekly betas for installation and testing to try and get more timely feedback on fixes, and to avoid people falling back to building from the latest Subversion which is a moving target.

Beta-2, out today, contains a number of bugfixes, especially to do with dependency resolution.

Beta-3 will focus on polishing up the exception handling and any remaining major issues.

Beta-4 is expected to be close to the final release, with all blocking issues fixed.

At this point, we're keen to get some stable releases out there - there are lots of people looking to put it into production now so it is time to start locking it down. We also expect to deliver regular releases over the following weeks to resolve any minor issues, while work commences on the 2.1 feature release.

Maven 2.0 Beta 1 and its sibling dependency management ant tasks are now out!

Download it from http://maven.apache.org/maven2/download.html

This release includes 206 bug fixes and enhancements since the previous release on 26 June.

The main new features in this release are:

* Further improved dependency management: full support for dependency ranges
* Reactor project aggregation support and summary
* File system discovery of POMs and artifacts to reduce build time and use of local and remote repositories
* Repository metadata support
* System scope dependency support
* Eclipse compiler support, ability to fork compiler
* Ability to automatically bundle sources and javadoc with deployments
* Maven 1.x repository support
* Allow use of setters in mojos for field population
* Ability to separate snapshot repository
* Ability to set minimum Maven version requirement for projects and plugins
* Build extension support
* Bugfixes and enhancements

This release is considered stable with a feature set comparable to Maven 1.0. Further betas and the final are expected to be backwards compatible, with a primary goal of bugfixes, usability improvements, and documentation.

A large number of plugins will be released in the coming week to match the primary Maven 1.0 plugin set.
See Maven Plugin Matrix for more information.

We hope you enjoy using Maven! If you have any questions, please consult:

* the web site
* the maven-user mailing list

For news and information, see:

* Maven Blogs

Just pushed out Maven 1.1 Beta 2 to the mirrors. Notable improvements:
- problems with deployment have been fixed
- support for forkmode="once" on tests
- validation of the POM before building
- latest plugin updates

-> Release Notes

-> Download

This knocks quite a few minutes off the Geronimo build in my environment, so give it a whirl and let us know if it works for you so we can push towards a final 1.1 release!

This is some of the best news I've had all year :)

It seems the next releases of JavaMail and Activation binaries will be available under CDDL, and I hear other spec jars are going down that same path.

If I understand the license correctly, this means they can be distributed from the Maven repository at Ibiblio, as long as they carry a notice that indicates where the source can be located.

I'll definitely be following this closely. It may even be worth building our own snapshot of these libraries from sources and pushing them up to ibiblio, though personally I'd prefer to wait for an official release rather than risk proliferating a temporary version.

Given that Glassfish builds with Maven, maybe we can add them to the list of repository sync partners and releases would be pushed out automatically in the same way as other open source organisations - who knows.

The Apache Maven team are proud to announce the third alpha release of Maven 2.0.

Download it from http://maven.apache.org/maven2/download.html

This release includes 83 bug fixes and enhancements since the previous release on 13 May.

Maven 2.0 is a rewrite of the popular Maven application to achieve a number of goals, and to provide a stable basis to take it into the future. While it can be considered quite stable, and future versions are now expected to retain a high amount of backwards compatibility, this is still a technology preview, and not yet complete or considered ready for a production environment.

The main new features in this release are:

• Improved dependency management


• Build profiles for environment specific settings and dependencies


• Finalised build lifecycle


• Proper handling of derived dependency type such as sources, javadocs and ejb clients


• Beanshell plugin support


• Improved reporting support, including internationalisation.


• Improvements to the Ant tasks


• Better plugin management, with the ability to select specific versions for use


• Various plugin improvements

This release is very near to being feature complete, and the next release will be a feature complete beta-1.

We hope you enjoy using Maven! If you have any questions, please consult:

* the web site: http://maven.apache.org/maven2/
* the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:

* Maven Blogs: http://www.mavenblogs.com/

After finishing up a couple of recent tasks, I came to the realisation that Maven2 has reached the "hump" that you have to live with when writing in revolution mode instead of evolution.

I think it is now possible to do everything you could do in Maven 1.0 in Maven 2, as far as the core is concerned (and of course, a whole lot more!)

The main change that triggered this for me was the finalisation of the build lifecycle. While we've been adding a lot of new features, this one was important to facilitate some use cases in Maven1 that were previously unavailable to Maven2 plugin writers.

This is a good milestone to hit, as the external API for plugin writers has now stabilised and some additional efforts can be put in there to rewrite the popular Maven1 plugins and reports to leverage the improvements of Maven2, so that users can see the same benefits.

The Maven 2.0 alpha-3 release is due out on Wednesday, including those changes and more.

In addition, the dependency management has started to undergo its usability improvements and will shortly have the version ranges and conflict resolution that has been on the todo list so long. And of course, this will also be available automatically in the Ant tasks (which have already undergone a number of other improvements for this release as well) and the standalone Java code you can use yourself.

This is a big release as we are very close to being feature complete for the 2.0 core, and entering beta testing with the July release (that is, bugfixes, cosmetic improvements and above all documentation - avoiding API, usage and metadata changes).

So if you've been thinking of trying Maven2 out, watch out for the release this week. We'd love to hear what you think about it and it is the best time to get your feedback in for the 2.0 release cycle.

The Maven 1.1 Beta is now out. Most will be interested in the reduced memory consumption and Ant 1.6 support, but there are a few other updates and bugfixes as well as all the latest stable plugin releases. It appears stable and should be usable today in most places using Maven 1.0.2.

From the release notes...

http://maven.apache.org/start/download.html

This release focuses on the following objectives:

• Integration of Maven 2 technologies such as Maven Wagon, Maven SCM and the new model code


• Ant 1.6.5 support


• Upgrade to later releases of dependencies, in particular Jelly


• Significant improvements in memory usage


• Improved POM layout


• Bugfixes

With just a few exceptions, Maven 1.1 is backwards compatible with Maven 1.0.

For a full list of changes, please see JIRA.

IMPORTANT: You must ensure that Maven 1.1 is first in your path if you want to have it installed side-by-side with Maven 1.0.2

We hope you enjoy using Maven! If you have any questions, please consult:

• the FAQ: http://maven.apache.org/faq.html


• the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:

• Maven Blogs: http://www.mavenblogs.com/

A year ago, I posed the question "Why do you Hate Maven?". A lot of those issues have since been addressed - if not in later Maven 1 releases, in Maven 2. This post inspired a mail on the users list listing some other issues, and whether they saw Maven 2 solving them.

It is always good to hear in-depth feedback, both positive experiences and negative ones, that are framed in a way that help shape a better future for Maven. So with that in mind, I thought I'd respond, and since it started in the blogosphere (and the author had originally intended to reply on the blog), I figured I'd respond here too.

It was definitely encouraging to note that even with the limitations discovered in Maven 1, those posing such questions still like it, and choose to use it - so its not so much a matter of hating Maven, but more of wishing it did what it does better.

Anyway, here goes...

ISSUE: Multiproject handling is a "tacked on option" whose interaction with other goals becomes problematic.

M2: Appears to have been addressed in M2.

This is correct here on both counts. Multiple project builds really was just a collection of separate builds. Improvements in Maven2 to cover this include
- building module lists into the POM as a first class entity
- the ability for a plugin to behave contextually if it is building a single project, or is an aggregating top level project
- knowledge of other builds being performed in the reactor so that they can be used instead of repository data, eventually allowing "m2 compile" to work across a series of projects, without the need to install each

ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion.

M2: Appears to have been addressed in M2.

Again, this is spot on. Maven2 lets each goal declare whether it needs the dependencies, and if so, which set (compile, runtime, or test).

ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals.

There is certainly no argument here, and was the topic of a recent blog entry on what might be wrong with Maven's documentation. Poor plugin documentation is a particular problem. I'm hopeful the documentation on the site is enough to get started and perform a reasonable percentage of the main tasks, but delving into advanced topics certainly requires a bit of digging and a post to the users list quite often. The artchitecture is also problematic to document as is: explaining the effects of a postGoal in a particular plugin in Maven1 is particularly challenging, as is comparing the differences between a goal, a jelly tag, or just a property.

M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation.

M2 is still in its alpha stages, so the documentation can be expected to be lean. We tend to write things as they become stable to avoid writing documentation that will change on experimental features. That stage is now coming to an end, and it is necessary to start fleshing out the main site, and set a good foundation for the reference documentation in the plugins, as well as common uses. In general, how Maven2 works is much more clearly defined and so easier to explain.

Definitely yet to be proven whether a good job will be done here, but I think the Maven team have an idea of what is necessary.

Ideology

Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets.

This is a tricky one. It would be silly to call them best practices if they weren't really best practices for the real world :)

There are two commons causes here. One is a misunderstanding of what Maven's best practices really are. (I'll emphasise this isn't a response to the poster in question, but a general observation). This, again, comes back to a failing in our documentation. But quite often a question on the users list starting out thinking Maven is incapable of working with their project ends with the light bulb appearing above the head as it clicks. The same approach needs to be taken to builds as for coding: you can't start with a solution and try and fit the problem to it, yet it happens all the time.

The other is probably integration with existing practices and tools. There are definitely some particular cases where limitations come up, and this is something that needs to be looked at case by case, and how we can better facilitate Maven and those tools working together. Maven does need to be inflexible in some ways to ensure everything works as designed, but this shouldn't really stop something from being done, as long as you are still looking at this from the POV of what you want done, not how to do it.

With feedback on what those issues are, hopefull Maven will be a better default fit to more and more real world practices, but still retain the benefits it provides in giving known build patterns.

ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment.

M2: I am not yet clear that this is resolved in M2.

The way we have looked to resolve this in m2 is to improve the definition. We have unit tests which are run before packaging as they always have been, and we have what we are calling integration tests that are run after packaging and might require some deployment into the server as is given here.

There were a few different reasons to complain about tests being intrinsically hooked into packaging in Maven1 - none of these reasons are valid, that I know of, in Maven2 as those issues have been resolved, without needing to actually prevent the tests being run.

ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool.

The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference.

M2: I have seen no sign that this is simpler in M2.

In this case, it really depends on what you are trying to achieve. In Maven, the project is a fundamental unit of work, and has a unique identifier that is used for dependencies as well as building and publishing the project. Now, in the case where you have a group of coupled artifacts, such that there is a "main one" and then a series of others that only exist because of the main one - Maven2 allows that. Examples are an ejb and its client library, a taglib JAR with its tld files, and so on.

However, when it comes to building code where they might be separated then Maven's identification relies on being able to tell them apart, so they must be separate projects. These separate projects have their own list of dependencies, which is hopefully smaller given that there is a clear functionality separation, and this makes the final dependency management easier as the closer of a libraries dependencies is more concise and more likely to be correct straight up.

To make maintaining these separate projects easier, Maven2 makes use of its multiple project support and better inheritence so that they can all still be worked with together, and keeps the project files quite small and simple to maintain.

ISSUE: The versioning of artifacts is VERY much a "one size fits rarely" UNLESS you are in total control of all of your codebase. If there is any place where a specific artifact name doesn't work or cannot contain a version at deployment time (.NET strongly named assemblies come to mind - painfully) then there are rarely workarounds that don't take many hours to implement and integrate into the process.

M2: I have seen no sign that this is simpler in M2.

This is one of the more common misconceptions - that the version in the repository has to match the version used when you build. This should not be the case. It is important anything going into Maven's repository has a version so it can tell the difference between two different versions of the same artifact, and to make builds reproducible in the future when that artifact changes. However, no matter how you reference it and it is stored in the repository, this should not affect what it is called when the artifact is actually deployed. Classic cases are DLLs and EARs which rely on specific, unversioned names.

ISSUE: Repositories assume WORA semantics for the artifacts. Building systems that require special dependencies for one platform but not for another is problematic.

M2: This appears to be handled at the repository side by the new M2 repos structure. I am not clear about the use of Maven to build multiple configurations.

This has been taken care of in recent code in Maven2 which allows defining several build profiles within your project. They are cumulative, and let you specify different dependencies, configuration, and possibly different build processes for different environments. Typical triggers for applying certain profiles are the JDK being used, the target operating system, and whether it is a dev, test, QA or production build.

ISSUE: Using multiple source paths in a single projecty is a headache. It has most often come up in the code generation arena but also when dealing with tools that require the source tree to be processed to be available AND cannot filter the source files to be processed by package name.

M2: I am not sure if this is addressed in M2.

This has been addressed in Maven2, again without comprimising the original encouragement to keep one source tree for one artifact.

There is a generate-sources phase in the build process, where you can register any goals that do so, and plug the new directories into the project for compilation automatically.
There is a process-sources phase before compilation, that takes the above source roots and can filter them or process them as needed.

So, all in all there were some great questions here that have probably been answered in pieces over time, but that I'm encouraged to say we are making positive movement in Maven2 without losing sight of the biggest advantages of using Maven in the first place to get understandable, consistent builds based on proven patterns.

If anyone has any further feedback on these, or other gripes you've never seen answered, or maybe even some positive encouragement, I'd be happy to take a stab at answering them.

The slides from my presentation to the Sydney JUG last week are now online. It's an overview of Maven's concepts, the new features of Maven 2.0, the dependency management tasks for Ant, and a short introduction to Continuum.

https://sydneyjug.dev.java.net/files/documents/922/15554/sjug20050601.pdf

I'm still reading recently on a couple of blogs that Maven's documentation is not very good. This is pretty hard to hear, because I rewrote a significant chunk of it at the end of last year :)

When I asked the question Why do you Hate Maven? last year, I got some good responses, it led to some changes, and I don't think most of those arguments hold any more.

I'm hoping the same can happen with the Maven documentation. Do you think it isn't very good? Is it a preconceived idea from before it was redone? Or is there something seriously wrong with it now? Hard to find information, incomplete, out of date? Is it the main site, or the plugins?

I'm the first to admit that we should have hit the ground running with Maven 2.0, but there has been a definite decision to focus on getting top quality docs together during the betas when all the features are stable. So if there are some lessons to be learned, now would be a great time to do it.

And if you're going to say you are sick of square, red and grey - I'm with you. It's time for a change :)

The Beanshell support for Maven 2.0 landed earlier this week. All in all quite simple to get going (just a few hours, with no prior beanshell expertise), which bodes well for adding other scripting languages later as all the scaffolding is already there.

The following script below is an example:

/**
 * Beanshell mojo integration test.
 * @goal it0020
 */

import org.apache.maven.plugin.Mojo;
import org.apache.maven.script.beanshell.BeanshellMojoAdapter;
import org.codehaus.plexus.util.FileUtils;

execute()
{
    logger.info( "Executing it0020..." );
    print( "info level?" );
    FileUtils.fileWrite( outDir.getAbsolutePath() + "/out.txt", 
        "This is a Beanshell test" );
}

/**
 * Output directory for files.
 *
 * @parameter expression="${project.build.directory}" type="java.io.File"
 * @required
 */
setOutDir( file )
{
    outDir = file;
}

return new BeanshellMojoAdapter( (Mojo) this, this.interpreter );

Each script file contains one "mojo" (a term originally coming from Maven POJO used to describe a single goal within a plugin). Several scripts can be included in a single plugin.

The bshdoc comments in here are used to generate a plugin descriptor for Maven, rather than editing the XML by hand. The opening comment gives the description and goal name.

The execute() method is what is called each time the goal is run Any valid beanshell can be used here, and as you can see there is a built in logger variable that can be used for output (as can print ). Note that the script is instantiated each time, so any state stored globally is not retained. This may be made configurable in the future.

Any setXXX methods declare the input variables which can be configured from the POM and are used to build the plugin descriptor. Note that at present the methods are not actually called, the variables are just inserted. The expression and type give the default value and what to coerce it to.

Finally, the return statement is required to make sure that Maven gets back the contents with the right interface so it can be executed.

Currently, this all needs to be bundled up in a JAR like other plugins. I think that there would be a strong demand to edit on the fly for scripted plugins, so there may need to be development-only support for editing these in place or even into a running instace.

It is quite similar to a Java plugin, so it may be that people still opt for those unless they are looking for a way to edit on the fly, have some existing code, or particularly want something loosely typed.

Of course, you can also mix and match (eg include Java code, and call that from your beanshell script or vice-versa).

Any thoughts? How would others like to see this work?

The Apache Maven team are proud to announce the second alpha release of Maven 2.0.

Download it from http://maven.apache.org/maven2/download.html.

Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

This release includes 76 bug fixes and enhancements since the first release on 8 April.

Maven 2.0 is a rewrite of the popular Maven application to achieve a number of goals, and to provide a stable basis to take it into the future. While it can be considered quite stable, and future versions are now expected to retain a high amount of backwards compatibility, this is still a technology preview, and not yet complete or considered ready for a production environment.

The main new features in this release are:

* Basic site generation
* Improved error handling
* Automatic plugin updates
* Published Mojo and Plugin API
* Inclusion of Ant tasks for Maven 2.0

This release is expected to be much more architecturally stable, making early adoption a possiblity. At this point, there are still only the core plugins available.

We hope you enjoy using Maven! If you have any questions, please consult:

* the web site: http://maven.apache.org/maven2/
* the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:

* Maven Blogs: http://www.mavenblogs.com/

Want to automatically update your Maven plugins to the latest versions available? Well, with the Maven 2.0 alpha 2 release coming this week, you can.

The introduction of separate release timeframes for plugins some time back was a good move - for example, there have been several individual plugin updates made available since the last Maven 1.0.2 release in December, that users could download as soon as they were ready.

But one of the common questions received is how to find out what the latest versions of all the plugins are. To solve this, if a version is not specified Maven will now check daily (by default) for a new version, and download it if it is newer. This uses the same mechanism as for snapshots, so you can also check for updates on demand, and set the update interval to always, daily, interval or never. We hope to allow greater configurability of these updates in the following June release.

What about build reproducibility? Obviously this is a concern, and for that reason any plugins related to the build is specified directly in the POM, and you have the ability to specify what version of a plugin you are using. Regardless of what releases are known of, that one will always be used to build your project.

This also assists when distributing your project to other people. No more telling them what new plugins they need to install to build! It all happens behind the scenes using the versions specified in the project.

Another feature that makes plugin use in Maven 2.0 really easy that you might not have noticed is the transparent discovery. Maven 2.0 actually doesn't come with any plugins installed - yet goals like "idea:idea" will discover and download the IDEA plugin automatically. This relies on a little magic specific to Maven plugins currently, but is also scheduled to be expanded to all plugins in the June release.

This really helps with usability in Maven 2.0... but if you've got any additional ideas about how you'd like to get plugin updates, feel free to drop us a line on the users list.

A common sticking point with people looking at Maven is the concept of using a remote web repository (even if they can mirror it in their local network) rather than storing the dependencies in CVS along with their source code.

Usually when the arguments here take place, the benefits of putting them into an SCM (such as versioning, access control and auditing) are touted as reasons to store them with the project and live with the downsides of duplication, slower checkouts and updates, and reliance on SCM versioning that can leave you stranded when the files are later deployed and have nothing attached to them to indicate where they came from.

It is only the latter problems that Maven attempts to solve by having a repository, so why not have the best of both worlds?

I came to think of this when I saw the argument yet again on the users list and thought back to
a discussion about using Subversion as a remote repository.

Given it was a Friday, I decided to spare a couple of hours and implemented it.

It's pretty rough, but is a working prototype that makes Maven 1.1/2.0 downloads a checkout/update, and deploy is an add/commit. I see this would be useful for snapshot repositories, where you could use one filename instead of transforming the version, so getting the latest would literally be an svn update.

I don't know if I'll come to use it myself, but if anyone is interested in testing and working on the functionality, please drop by the developer mailing lists.

Working with the new components of Maven makes things like this really easy - in the couple of hours I was able to reuse the existing upload/download mechanism, and wrap it around our SCM handlers, so CVS and SVN could both be plugged in. With a little testing so could clearcase, starteam or perforce which we have alpha providers for, or anything else someone cared to work on (we have had interest in developing a VSS provider, for example). All of this is reusable against all of the Maven plugins, and any related Ant tasks.

Snapshots were something that I believed to be widely misunderstood in Maven 1.0, and this was because they tended to have a dual purpose.

I believe it is now a lot closer to the original intention.

Snapshots as Dependencies

A big complaint was the frequency of download checks on SNAPSHOTs which can be quite slow - it would happen multiple times within a single Maven instance in some occasions. Maven 2.0 has improved on that - not only is it only checked once per Maven execution, the default is to only check once a day. Of course, the interval is configurable from the POM, and there is also a command line option to force it to check every Maven run as well. This can make it much like CVS updates: just update your dependencies when you are ready to integrate with everyone else.

Developing with Snapshots

How it all works

There is still more work to do to be able to make different versions interact together, but we're well on the way.

For those interested, the original design for SNAPSHOT handling in Maven 2.0 is available.

The first Maven 2.0 Technology Preview release is now out.

http://maven.apache.org/maven2/index.html

We're looking forward to hearing your feedback, ideas, and (to a lesser extent :) bug reports.

If you need help with the release, please consult the documentation frequently as we continue to update it, and subscribe to the users@maven.apache.org mailing list. For more information, please see http://maven.apache.org/maven2/about.html#get-help

We welcome contributors to the Maven project - if you are interested in helping out, please see http://maven.apache.org/maven2/about.html#get-involved

Thanks to everyone who has worked on this release!

-- The Apache Maven Team

I caught wind of a release of Ivy today, that lists among its new features a new repository for project metadata.

Given that they are already using the Maven-developed repository for artifacts at Ibiblio, this struck me as pretty strange. Constructing metadata for over 7000 artifacts by hand is not something I'd want to take on, especially when most of it already exists in the Maven repository. And especially when you are just taking that metadata from the same source.

Let's compare an example:
http://www.ibiblio.org/maven/commons-cli/poms/commons-cli-1.0.pom
and
http://www.jayasoft.fr/org/ivyrep/apache/commons-cli/ivy-1.0.xml
(the XSL is actually a nice touch to make it browsable).

Now, the Maven descriptor can describe everything the Ivy one does except for who wrote the ivy descriptor (which doesn't seem all that useful other than for some really basic auditing if it were to be automated). There is a limitation in the POM that some data exists (license) in a super POM not published - but that problem is going to be addressed in the next Maven release, and could certainly be worked around when the metadata is published.

We also have metadata for projects like Hibernate that are not built using Maven - it is a requirement of upload to ibiblio.

The main difference seems to be the listing of the location of repositories that house the artifact. This seems a bit short sighted... do you add a new repository entry to every descriptor in the repository every time you add a mirror?

As a Maven developer, I would have liked to see the Ivy developers approach the Maven project about this and offer to help beef up our metadata, and use it rather than creating a whole new repository.

As a user, I'd prefer to get access to new dependencies as soon as they are released or uploaded, rather than having to submit two different requests (one to ibiblio and one to ivyrep).

Update: Note that I'm not saying anything about Ivy or Maven's ability to do transitive dependencies - I'm aware that Ivy is doing this and the current release of Maven is not. However there is no reason - that I can see - that Ivy cannot use the existing metadata to implement that feature.

The new Maven web site has now gone live at http://maven.apache.org/.

After pointing users at the staging site for some time now, this was a long overdue overhaul that hopefully makes documentation easier to find, and more complete.

There is still more to come, but all feedback and contributions are welcome. Feel free to comment here, on the Maven Users List, or add patches to JIRA.

Sorry - same old colour scheme this time around, but hopefully there'll be something new real soon now.

Ever seen a really wacky bug that you just couldn't explain?

I had one of those panics earlier this week. After releasing Maven 1.0.2 with just a few small fixes discovered in the month since the last release, I was fairly confident that we could now close that branch. To the point that I deleted my branch checkout from my laptop, with CVS HEAD being the code I'd work on permanently.

Then after arriving at work the next day, I saw a number of complaints of a regression that caused Maven startup to be very slow. This being in an area of code that hadn't changed. What had gone wrong?

Luckily, it turned out that it just went away some hours later.

Why? Well, I built the distributions locally, then uploaded them from here. The code in question was checking timestamps - if an installed plugin was newer, unpack it locally and set the timestamp to "now". But I'm at +11 GMT, though apparently .zip and .exe don't record that - just the time. So the rest of the world hadn't caught up.

I found it funny in the end. Next time I'll have to build the releases 20 hours in advance :)

Ok, so the Maven 1.0.2 release is out, most importantly fixing the property inheritence regression that found its way into Maven 1.0.1 (when you roll up 4 months of bugfixes in one release, I guess you're asking for that to happen :)
There were a few fixes for dependency handling that were discovered after 1.0.1 that were also included, as well as updates to the java, ear, cruisecontrol and dashboard plugins.

A quiet release, but that is now the stable version that should persist for the next couple of months. Unless something goes horribly wrong, this will be the last Maven 1.0.x release.

Next up: Maven 1.1, which has some nice features coming while building on the current core so that projects will continue to build unmodified (with a few small, documented, exceptions). There will be a lot of changes under the hood too.

Here's something I wrote up a while back for work and have touched up recently that discusses the structure of Maven 1.x.

Download file

While you wouldn't need it as a general user (although troubleshooting is helpful), its aimed more at someone digging seriously into plugin writing.

Definitely rough around the edges, but I hope it helps!

The Apache Maven team is pleased to announce the release of Maven 1.0.

http://maven.apache.org/start/download.html
(please be patient as the release may not have propogated to all mirrors yet)

Maven is a project management and project comprehension tool. Maven is based on the concept of a project object model: builds, documentation creation, site publication, and distribution publication are all controlled from the project object model. Maven also provides tools to create source metrics, change logs based directly on source repository, and source cross-references.

New Features

* Bundle the Jelly XML tag library for build and for plugin's convenience
* Add different types of download progress meters.

Fixed bugs

* Fix property inheritence under some circumstances Issue: MAVEN-1296. Thanks to Eric Lapierre.
* now initialises the plugin if it has not already been loaded, removing the need for dependency handles
* Check last modified timestamp as well as conditional GET in case the server time is behind the local time Issue: MAVEN-1188.
* Bugfixes for new httpclient based downloading (incorrect timestamps) Issue: MAVEN-1343.
* Handle cross site redirects Issue: MAVEN-1353.
* Correct absolute paths with no drive designator on windows Issue: MAVEN-1290.
* Amend bootstrap to create directories that might not exist Issue: MAVEN-1341.
* If artifact is not a snapshot, don't continue checking for newer downloads once one is successful Issue: MAVEN-1344.

Plugin Highlights

The latest plugin releases are also included, with bug fixes and some new features.

We hope you enjoy using Maven! If you have any questions, please consult:

* the FAQ: http://maven.apache.org/faq.html
* the Wiki: http://wiki.codehaus.org/maven/
* the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:

* Maven Blogs: http://www.mavenblogs.com/

- The Apache Maven Team

Maven 1.0 RC4 has been released. Since its been a while since RC3, we snuck in a few useful features and bugfixes.

This really is the final release candidate - a couple of bugfixes will be done but 1.0 should follow shortly.

Here are the release notes...

Maven 1.0 RC4 Released

The Apache Maven team is pleased to announce the release of Maven 1.0 RC4.

http://maven.apache.org/start/download.html

Maven is a project management and project comprehension tool. Maven is based on the concept of a project object model: builds, documentation creation, site publication, and distribution publication are all controlled from the project
object model. Maven also provides tools to create source metrics, change logs
based directly on source repository, and source cross-references.

Maven 1.0 RC4 is the final release candidate for Maven 1.0 (and this time we
mean it!)

New Features

* Support NTLM authentication on a remote repository. Issue: MAVEN-1332.
Thanks to george wang.

Fixed bugs

* Sort all installed plugins. Issue: MAVEN-1320. Thanks to Miguel Griffa.
* Fix HTTP BASIC authentication for remote repos. Issue: MAVEN-1273. Thanks to Andreas Peschka.
* Repository element was broken for non-cvs connections Issue: MAVEN-1298.

Changes

* Set maven.plugin.user.dir to ${maven.home.local}/plugins by default, move maven.plugin.unpacked.dir to ${maven.home.local}/cache.
* Read local plugin jars from maven.plugin.user.dir instead of
maven.plugin.unpacked.dir.
* Use commons-httpclient for http downloads from the repository.

Plugin Highlights

* The deploy plugin has been merged into the artifact plugin. The artifact plugin is used for all artifact deployments now, and supports the old-style deployment transparently.
* Addition of the new RAR plugin.
* For individual plugin changes, see the Changes report for plugins at: http://maven.apache.org/reference/plugins/plugins.html

We hope you enjoy using Maven! If you have any questions, please consult:
* the FAQ: http://maven.apache.org/faq.html
* the Wiki: http://wiki.codehaus.org/maven/
* the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:
* Maven Blogs: http://www.mavenblogs.com/

- The Apache Maven Team

I was reading dion's response to Howard's Maven post, and saw a comment there that said:

Howard is also looking at using JAM, which provides a pre-built set of ant tasks, much like Maven except written so I don't have to learn a whole new tool and language. This seems to be what Maven should have been, if developed by people with sense.

Despite all the complaints about Jelly (most of which come from the Maven developers :), countless people have tried. I don't quite understand that - you shouldn't have to learn Jelly to use Maven. Maybe this is a problem with documentation and something I'm trying to fix right now.

I've said previously that JAM looks like a good idea - using what Maven is really about to generate Ant that everyone else understands until Maven can handle some of the things that get tricky (in particular multiple source directory handling is inconsistent in Maven 1.x).
A JAM developer posted this comment:

We actually see JAM as step towards Maven, not as a competing framework. But until Maven matures, Ant is still the reliable industry workhorse… and we hope JAM makes it a little easier to use.

This is good to see. I haven't tried JAM out, but if it does what you need it to do, then I'd say go for it.

It's a shame that Maven has come out being perceived as a glue for a bunch of Ant tasks. It's a fair perception, because as I said in my last post, when you give users the option of producing reusable build fragments, it tends to happen real fast, so Maven has a lot of plugins out there.

I certainly look forward to a stronger adoption of Maven's concepts of project information structure, and hope that Maven can continue to mature down its current path where it becomes the best tool to manage this information and build with it.

Howard says he is moving away from Maven, and gives some fair reasons for it, and I thought it was appropriate to respond.

Howard starts out by stating what he likes about Maven:
# Automated donwload of dependencies (from http://www.ibiblio.org/maven)
# Integrated pretty documentation (with navigation)

For dependencies, a good solution in Ant is later given. I think Howard would agree with me here - if you are using Maven just so you can grab dependencies easily and intend to script the build yourself, then you are wasting your time and should stick with Ant :)

For the site - Howard doesn't propose an alternative. I assume he will continue to us Maven to generate that.

There is a claim that the documentation has a "large" number of bugs, of which Howard points out just two. The reality of this is that many of these are problems with Jelly itself. As a result, for a long time we have been planning a rewrite of the xdoc plugin that will not use Jelly. This will land shortly after Maven 1.0 is released.

While discussing bugs, I'll admit Maven has a huge QA issue. We rely a lot on users to report bugs and submit patches across the areas that we can't cover.
Maven is a project that facilitates rapid reuse and we accepted a lot of plugins that were later abandoned and we did not have the resources to maintain. As a result, some time ago plugins were moved to an independant release cycle, and Maven simply bundles the latest releases. It is up to the plugin maintainers to release quality plugins. The next task here is to evict immature plugins and make sure all have an owner, which is under way. It would have been nice to remove some of the low quality stuff already and make people download it - but you don't want to inconvenience users in that way during an RC cycle.

I think the approach that has been taken here is sensible. No project is ever going to be bug free, so we focus on fixing the things that can be done
- quickly and easily
- by applying a patch
- affect the most users
If a bug gets filed as minor, with no suggestion of a fix, no votes from other users, and sometimes not even a reproducible test case - there aren't many projects in the open source world that can fix all of those.

This is all just a result of growing too fast, and something that the team are endeavouring to get under control, by getting back to a more simplistic model of what Maven is, and start emphasising that the plugins are somewhat separate to that.

Moving on, Howards points on simplicity and consistency are well taken. Funnily enough all the issues he lists here look something like the documentation naviagation that has just been proposed as it is going under a rewrite.

Effeciency: Maven has made huge strides in this area, but we have accepted that as long as Jelly is in the core there is going to be a problem here, especially when generating the site.
However, Maven is as fast as Ant to do your day to day development, and faster if you run it in console mode, and really - how often do you regenerate the project site or a distribution? You can afford the time there, which is why the efforts have gone into the big wins.

Feedback: I hate NPE's too. I hate it when you get it in Maven deep inside one of the other libraries it is using like velocity. And it's worse for a user. But Maven then explains to the user how to file a bug report, and these issues usually get addressed immediately. We still have work to do here, but I'm not sure what more can be done immediately to help.

Howard's Ant example that follows shows just how Ant should be used. I have a couple of issues with the perception here that it is much briefer than Maven:
1. it doesn't do the site generation at all, while part of the Maven build documents given are dedicted to this (specifying reports and their properties)
2. those are not standard components. That is basically a reimplementation of what maven-javacc-plugin and maven-jar-plugin would be doing for you, and I suspect they are quite large and not immediately reusable beyond your own projects.
3. maven.xml is just there to fix a bug in a plugin, so that really shouldn't be necessary.
4. This doesn't address a lot of other issues that Howard has with Maven, such as building multiprojects, and probably isn't too scalable.

JAM sounds like a better way to do (2) above as it is reusable, but I think if it were as popular as Maven, it would probably suffer the same problems.

Anyway, I hope this brings some clarity. Essentially I agree with what Howard has said to some extent, and as far as the issues with Maven go, they have long been recognised and I am happy to say the current Maven roadmap addresses it all. I look forward to seeing it come to fruition.

The Maven team is pleased to announce the Maven 1.0-rc3 release!

http://maven.apache.org/start/download.html

Maven 1.0 RC3 is the final release candidate for Maven 1.0.

Maven is a project management and project comprehension tool. Maven is based
on the concept of a project object model: builds, documentation creation, site
publication, and distribution publication are all controlled from the project
object model. Maven also provides tools to create source metrics, change logs
based directly on source repository, and source cross-references.

Changes in this version include:

New Features:

o Introduce a backwards compatibility option maven.property.inheritance,
which disables the functionality when set to false. Issue: MAVEN-1255.
o Show help on how to submit a bug report if Maven dies with an unexpected
exception
o Add maven.remote.group to defaults.properties
o Add sort attribute to reactor tag.
o Add collectOnly and collectionVar attributes to reactor tag. Thanks to John
Casey.
o Improve maven -g output, and add -u and -P switches for additional usage
help.
o maven:get/maven:set tags replace maven:pluginVar
o Install and uninstall plugin jelly tags for managing plugins on the fly. Issue:
MAVEN-1219.
o Ships with the latest maven standard plugin releases.
o All plugin releases were polished up.

Fixed bugs:

o Parent project properties are now correctly loaded from