Jason van Zyl

Road Map

Many people often ask "Where is Maven going?" and this documents tries to answer that question. This document will be of interest to anyone who uses Maven but is primarily directed at those developers who want to get more involved in Maven's development. There is a branch that has been checked in and for the sake of brevity will be referred to from here on as the Road Map Branch or RMB.

Creating a coherent model for Maven

The MavenSession class has moved back to the name Maven. I have tried to move any and all code that would be of use when running Maven in any environment from the App class into the Maven class. The App class is now a very thin class whose only real purpose is to allow access to the Maven model via the command line.

Currently in the RMB any information that is required by the model is passed in with a simple Map. This map contains options like the online mode, debugging mode and things of that nature. The initial POM is also passed into the model in a neutral form. Currently passing in a file is supported but we should be able to pass in the initial POM as a Reader, InputStream, File, URL or String.

The use-cases currently driving the model are: the use of Maven itself from the CLI, the use of Maven as a component in Continuum and the use of Maven inside an IDE. More work needs to be done with ClassWorlds so that the initial ClassWorld can be booted into existence without the use the the Launcher class. I'm working on an Embeddor class which should allow the booting of the initial ClassWorld for the three above mentioned use-cases. The primary use case to satisfy at the moment is the CLI so I simply altered the constructor of the App class to accept a ClassWorld as a parameter. ClassWorlds will look for this special constructor as a conduit for passing the booted ClassWorld to the running application.

To help with some refactoring of Maven's model I have created an interface for the model so hopefully this can be the place where we can agree on Maven's contract and work from there to flesh out the refactoring.

In the RMB I've tried to move all the brains into the Maven class which lead us into the next subsection.

Maven as an Avalon application

The main idea behind trying to isolate the Model of Maven into the single class is part of an attempt to make Maven an Avalon component. Eventually I would like all the distinct portions of Maven to be Avalon components that can be run under Plexus. Turning the code in the RMB into Avalon components will definitely allow developers to easily experiment with new implementations safely.

Separate dependency resolution code

It's seems that Maven has spawned a raft of efforts to produce small libraries to deal with the downloading of dependencies. I feel that Maven still leads the way in this effort by dealing not only with JAR dependencies but any project artifact that can be a dependency. This code should be separated into a simple set of beans. From there we can wrap it in component logic for use inside Maven and others can use the code as they wish. One of our mandates now is to encourage other projects to be involved in Maven and this is probably the biggest way we can encourage collaboration. Much work has gone into our dependency resolution package. That coupled with the work in Werkz and the commons-graph pacakge I think we can make a tool that will satisfy any common requirements.

Plugin ClassLoader Separation

In the RMB ClassWorlds has replaced the use of Forehead to provide better control over classloading. Each plugin now has a separate ClassRealm which inherits from the core ClassRealm. So each goal is in a plugin so what happens now internally is that when each goal is run the classloader flips over to the plugin classloader that corresponds to the goal being executed.

Plugin dependencies

The way plugin dependencies are stated needs to become an explicit. Currently if a plugin needs another plugin then a weird lookup occurs where the dynatag namespace is used to find the plugin which is just messy and causing problems. All of the plugin dependencies need to change to something like the following:

This will eliminate a great deal of nonsense from the plugin manager. With the explicit information we can actually make decent graph instead of the jumble of lookups currently used.

Fully pluggable artifacts and artifact factory configuration

Right now the use of different artifacts is possible but is very limited. I believe what Michal has started is probably the best way I've seen to handle this stuff and will allow any sort of flexibility which will actually be required before we can do the explicit plugin dependency declarations outlined in the section above.

Removing Ant as a core dependency

I would like to remove Ant as a core dependency as it's become more a pain in the ass than anything. The coupling of Tasks to the AntClassLoader and Project have become a real nuisance. Having Tasks loaded into separate ClassLoaders just doesn't seem to work and Ant was not designed for long-lived processes.

The plugins can definitely specify Ant as a dependency and remove the implicit use of Ant. But there are many maven.xml files that use Ant semantics and we can't cut off people at the knees. We need separate mechanisms for dealing with Plugins and arbitrary Jelly scripts. Currently they are dealt with in the same fashion which is a problem.

In the RBM I have replaced several Ant classes and they are loaded before their actual Ant counterparts. The primary problem was with the AntClassLoader. I stripped the AntClassLoader down to a shell and it delegates entirely to the Maven model to resolve classes. The Model uses ClassWorlds now.

Pure Java API

I would like to create a pure Java API for plugins. I have nothing against Jelly but I am not entirely sure I want it as the primary path of extension. I don't want to change anything about the way Jelly plugins work. They should just continue to work they always have but I would like to add a pure Java API so I can write plugins purely in Java with no Jelly interaction. So people could easily create their own plugin mechanisms for their own scripting languages or BSF for example. I'm not overly fond of BSF but I think something like BSF would make for a better plugin mechanism than Jelly.

Maven TLP site

I'm working with Brian Behlendorf to setup the infrastructure for maven.apache.org. None of the infrastructure team seems to be active in processing any requests as Brian is the only one who seems to do anything w.r.t to setting up new projects so we'll wait for him to have some time and he's a _very_ busy fellow. I can take care of the CVS repositories, but the DNS and groups on the Apache machines can only be dealt with by Brian.