geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Making framework more obviously self-sufficient
Date Thu, 25 Sep 2008 15:30:39 GMT
I can see your logic for grouping everything under /framework.  I don't 
have a strong for/against stance for it.

BUT, if everything is moved to /framework, we'd also fix all of the 
groupIds to be org.apache.geronimo.framework, right?  If we're spending 
time changing the svn layout to match the logical grouping, then we also 
need to fix the artifact names, otherwise I'm against the moves.

I can see the argument for moving /framework out to its own subproject, 
but really don't know if we're ready for that or if it really buys us 


David Jencks wrote:
> On Sep 23, 2008, at 8:28 PM, Kevan Miller wrote:
>> On Sep 23, 2008, at 1:17 PM, David Jencks wrote:
>>> I'd like framework to build the entire working framework server, thus 
>>> demonstrating that it really is a complete server.  I think it would 
>>> work with the following changes:
>>> - move at least the car-maven-plugin into framework, perhaps all of 
>>> buildsupport
>>> - move the jsr88 classloader into framework
>>> - move the framework plugingroup into framework
>>> - move the assemblies geronimo-boilderplate and geronimo-framework 
>>> into framework
>>> This is somewhat related to 
>>> Thoughts? Objections? Comments?
>> Personally, seems a bit forced... I'm not sure I understand your 
>> motivations, and if I do understand, not sure that I really agree with 
>> them. Why exactly is "demonstrating that it really is a complete 
>> server" necessary? Or good?
>> Can you be a bit more precise about what you mean by 'jsr88 classloader'?
>> Personally, I kind of like that a 'plugingroup' can be found in 
>> 'trunk/plugingroups'. Similar feelings for assemblies and buildsupport.
>> My sense is that you want 'framework' to be a standalone entity, as if 
>> it were separately releasable -- which we could do (although I don't 
>> see much advantage in that, at the moment...). Until we're ready to 
>> truly split it apart, I'm not sure there's much gain by going half-way.
> My idea about the geronimo servers is that we have a base, the framework 
> server, that can't do anything except be extended, and then we have 
> bunches of functionality, such as the jetty web container, that can be 
> added to it.    I want this to be not just a theoretical hand waving 
> marketing statement but actually reflected in the code.  To me this 
> means that there should be a clearly delineated way to build the 
> framework server with essentially nothing else.  Currently this is 
> impractical.  You'd have to build a few framework modules, go build the 
> car-maven-plugin, build a few framework configs, build a 
> plugins/classloader plugin, build the rest of the framework modules, 
> build the rest of the framework configs, build the framework 
> plugingroup, build the assembly boilerplate, and finally the framework 
> assembly.  IMNSHO this is ridiculous and implies that geronimo is not 
> very agile or easy to deal with, and certainly not easily extensible for 
> other purposes.  Someone who wants to  build some  kind of special 
> purpose server - such as the plugin-farm-node - has to build all of 
> geronimo to get to the few parts they actually want.
> The jsr88 classloader 
> is plugins/classloaders/geronimo-javaee-deployment_1.1MR3_spec.  It now 
> has one of our extension classes in it as well as the jsr88 spec.
> I have no problem having framework/plugingroups for the framework plugin 
> group, framework/buildsupport for the maven plugin(s) and 
> framework/assembly for the geronimo-framework assembly.
> I think this also moves us closer to what I thought was an agreed goal 
> of releasing the plugins separately from the framework and assembled 
> servers.
> thanks
> david jencks
>> --kevan

View raw message