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.