dIon Gillard

The main area of excellence of magic is when it comes to component based development - using maven there is only the reactor and multiporject plugin, and you have to make every subproject a full maven project. Here limiting the POM is simplifying it! Even dependency handling has been simplified. I would call it a stripped down maven approach specialized for multiproject builds like they are common in avalon-based projects (Merlin components etc).

/peter

The Magic Project Object Model is actually rather interesting. Its certainly much smaller that the Maven equivalent and has an interesting edge with respect to it's support for fully transitive dependencies combined with separation of plugin, build, test, and runtime concerns.

This feature together with centralized version management and a complete integration with ant is the main factor influencing the reduction is POM complexity.

For example - transitive dependencies eliminate duplicate dependency declarations across projects. Centralized versioning ensure complete integrity with respect to version maintenance (a major overhead when you're dealing with projects involving hundreds of different versions artifacts).

The separation of build, test and runtime dependencies mean that you can do much more with respect to the generation of runtime meta-data with a very high degree of confidence. An example of this is the Magic's continuous integration via Gump. A Gump task uses Magic's project model to automatically generate the full suite of Gump project definitions for Avalon (currently 134 interrelated projects) which in turn triggers Gump to build each project using Magic. Other examples include the generation of classloader definitions for composite components, or the definition of runtime loadable plugins.

Combine the above with a repository model compatible with maven and you have one rather interesting scenario.

/Steve.

Yes, Magic is very early, in fact a matter of a man-month or two of total development, but considering how much it can do with such little development time, makes me convinced that we are heading down the right track.

As Peter points out, Magic is all about effectively dealing with complex projects and inter-project dependencies. Whether Magic is suitable for all types of projects or not, is very much a matter of time and trial/error. It is definately a better choice than Maven for Avalon and similar projects.

If we could throw in a couple of man years of development, like Maven have, I am sure it would pose a serious challenger to Maven, instead of being a purpose built buildsystem for Avalon.