geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: M2 Issues and Actions
Date Fri, 30 Jun 2006 18:33:07 GMT

On Jun 30, 2006, at 11:00 AM, Jason Dillon wrote:

>>> While this may work most of the time, it is not ideal as when making
>>> changes to plugins, users will be mystified when those changes are
>>> not used on the first build.
>>    This is not true. The plugin is *not* used before it is built. The
>> problem is that maven does not even start the build until it has
>> downloaded all the plugins. Even a dummy plugin would work.
> Um... it is completely true.  I am aware that the plugin is not  
> used before it is built.
> BUT the point that I was making was that Maven must resolve the  
> plugin before the build commences... that means that the plugin  
> must exist in a repository (or cache) already, and that is the  
> version that will be used for the current build cycle... NOT the  
> plugin that will be compiled and installed as part of the current  
> build.

The point I've been trying to make is that this feature of maven is a  
showstopper for use of maven in any framework type project.  We can  
work around it, but it's a ridiculous limitation in maven.  Yes, I  
should take it up with the maven team, but that takes time and  
energy, both of which are in short supply for me right now.

> Therefor the current build will always use the version of the  
> plugin that was built BEFORE the build started, NOT the version  
> that is actually getting built.
> This is why I suggested that the plugin either be part of another  
> project (detached from the main build) or as part of a bootstrap  
> phase that is executed before the main build cycle.

Since the packaging plugin is a way of running some g. core code from  
maven, not having it use the just built core code in a build makes me  
extremely uneasy.  I would prefer to split the build up into segments  
that must be run separately.  Since I am the only person who want to  
have a complete build of all the stuff that depends on geronimo and  
goes into the assemblies (I'm referring to building openejb as part  
of the g build), this really shouldn't annoy anyone.

So, my proposed build procedure:

build modules + plugins
go somewhere else and build openejb
build apps + configs + assemblies

The proposal of using snapshots of openejb from a repo prevents you  
from doing a clean build and finding out that in fact you created a  
problem in either openejb or configs/assembly.

This 3 step process will prevent us from interspersing the modules  
and configs builds which might be highly desirable to make our  
dependency tracking the same as the maven dependency tracking.  Cant  
get everything :-(

david jencks

> --jason

View raw message