geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [RTC] - Fix top pom to reference right plugin
Date Fri, 30 Jun 2006 18:28:41 GMT
Ok...I acquiesce ;-)  I be quiet until after the conversion is complete ;-)

Jason Dillon wrote:
>> 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

View raw message