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.
But you know that w/m1 that building the plugin and then using it in
the same build is also a massive hack.
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.
We maybe able to write a plugin to help facilitate these segments if
nothing already exists... allowing one command to build, and under
the covers it runs a set of m2 builds.
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
I like this sans the openejb bits... though if you want to build
openejb like this I don't see that it is a problem as long as it is
optional.
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.
Not sure what you mean... :-(
--jason
