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