On Jun 27, 2006, at 1:59 PM, Jason Dillon wrote:
It's clear to me that we need to break out our plugins build and
get the plugins published ASAP. I asked this in another thread,
what will it take to get this published? I don't think that it's
too much trouble, just an RTC to break the plugin out and then we
just start publishing the snapshots. We can shoot for a plugin
release around the time of G v1.2.0>
This is totally not clear to me. All our plugins are going to
depend heavily on geronimo code, why would we try to publish them
separately or before the artifacts they depend on are published?
This is classic chicken and egg... having G depend on G plugins
that also depend on G for the plugin to be built.
This might have worked before in m1, but so far I have not been
able to get a plugin built and then used in the same build cycle
with m2.
this was allegedly one of the advantages of m2, it was nearly
impossible in m1.
What parts of the build need these plugins?
packaging plugin >> configs
assembly plugin >> assembly
deployment plugin (any chance any one else will vote or should I give
up?) >> integration tests.
Is it just the config modules? If so then we may need to split the
build into two chunks, one that builds the modules and plugins, and
then another than builds the configs and assemblies.
Doesn't the listing of subprojects in top level pom.xml do this? We
are much better off now than we were with m1 where the dependency
plugin required some g. classes and was used to build g. modules.
There is another fly lurking ready to get into the ointment, it's
possible that we may eventually want to intersperse jar and car
(currently confusingly named modules and configs) builds in order to
completely align our dependency tracking with maven's dependency
tracking. Then we could use the poms instead of our own files.
thanks
david jencks
--jason
