I'm not sure I agree that this is easiest or best. I think I would be
interested in getting others' input on this as well.
I believe that while we move to m2 that simpler is better and thus
easier to complete the migration.
So, one version is simperer than many versions. If all modules in
the same tree have the same version, then ${pom.version} can be used
to resolve the correct version of dependencies. w/o that you are
forced to setup top-level properties for versions and manage those
versions... which is more work, more configuration and more error prone.
My recommendation is that all modules in a build tree use the same
version. If they should logically have different versions, then they
belong in a different build tree. And there are cases that look like
this now... no question, but lets fix this after the conversion is
completed and functional.
One of the problems we have now is the chicken/egg issue with the
plugin being in
the build itself. I think this would be alleviated by moving the
plugin
to its own project and push it out as a reliable dependency for the
geronimo project. I have tried the internal plugin thing on a few
projects, and it always ended up making life easier having the
plugin as
its own project.
There are a few ways to resolve this, which I have listed before in
previous emails. Looks like short-term to get the conversion
finished that we may need to introduce a bootstrap. Longer-term we
will want to reorganize the modules that are needed by the plugins
and then put them, in a separate tree and then put the plugins in
their own tree. Or... remove the need for those plugins to need
access to the G codebase. There are quite a few different ways to
fix this problem. But none of the long term fixes are likely to
happen now as we implement the migration.
--jason