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 :-(
thanks
david jencks
--jason
