geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Unable to build using m2
Date Tue, 27 Jun 2006 21:09:28 GMT

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.

david jencks

> --jason

View raw message