Yes, the groupId's should be changed IMO.
--jason
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 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
