geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: M2 Issues and Actions
Date Fri, 30 Jun 2006 18:48:57 GMT
>> BUT the point that I was making was that Maven must resolve the  
>> plugin before the build commences... that means that the plugin  
>> must exist in a repository (or cache) already, and that is the  
>> version that will be used for the current build cycle... NOT the  
>> plugin that will be compiled and installed as part of the current  
>> build.
>
> The point I've been trying to make is that this feature of maven is  
> a showstopper for use of maven in any framework type project.  We  
> can work around it, but it's a ridiculous limitation in maven.   
> Yes, I should take it up with the maven team, but that takes time  
> and energy, both of which are in short supply for me right now.

But you know that w/m1 that building the plugin and then using it in  
the same build is also a massive hack.


> Since the packaging plugin is a way of running some g. core code  
> from maven, not having it use the just built core code in a build  
> makes me extremely uneasy.  I would prefer to split the build up  
> into segments that must be run separately.

We maybe able to write a plugin to help facilitate these segments if  
nothing already exists... allowing one command to build, and under  
the covers it runs a set of m2 builds.


> Since I am the only person who want to have a complete build of all  
> the stuff that depends on geronimo and goes into the assemblies  
> (I'm referring to building openejb as part of the g build), this  
> really shouldn't annoy anyone.
>
> So, my proposed build procedure:
>
> build modules + plugins
> go somewhere else and build openejb
> build apps + configs + assemblies

I like this sans the openejb bits... though if you want to build  
openejb like this I don't see that it is a problem as long as it is  
optional.


> The proposal of using snapshots of openejb from a repo prevents you  
> from doing a clean build and finding out that in fact you created a  
> problem in either openejb or configs/assembly.

Not sure what you mean... :-(

--jason

Mime
View raw message