geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Making framework more obviously self-sufficient
Date Thu, 25 Sep 2008 15:36:35 GMT
Yes, the groupId's should be changed IMO.


On Sep 25, 2008, at 10:30 PM, Donald Woods wrote:

> 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 anything....
> -Donald
> 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