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

Reply via email to