geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Making framework more obviously self-sufficient
Date Thu, 25 Sep 2008 01:38:27 GMT

On Sep 24, 2008, at 3:06 AM, 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 https://issues.apache.org/jira/browse/GERONIMO-4258
>>>
>>> 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.

Well, you asked for thoughts and comments... ;-)

IMHO this *build-time* structure is "ridiculous" only if the above  
framework server functionality cannot be achieved at *run-time*. I'd  
say that what we have and what we can demonstrate is much more than  
"theoretical hand waving marketing statement". And "actually reflected  
in the code" would be more accurately described as "actually reflected  
in our source directory structure".  Assuming the runtime aspects are  
close to right, then becomes a question of some balance of the  
following aspects:

build experience -- where do we normally run builds from? how many  
build commands are required? how long does a build take?
maven artifact structure -- what's the organization of our released  
artifacts in maven?
release process -- how many separately released artifacts will go into  
a server release? how many versioned artifacts do we need to keep  
track of?
etc...

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

Personally, it's not a big goal of mine. I think it introduces  
complexity to the community, without adding much benefit to the  
community. I do want the basic structure to be there -- allowing  
additional plugins / assemblies to be built and separately released,  
if we so desire. However, doesn't mean that I'm eager to break our  
server release into a number of parts, holding separate release votes,  
and tracking some number of separately versioned artifacts.

--kevan
Mime
View raw message