You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/08/06 10:48:15 UTC
Splitting up the server into a few more chunks
Hiya, I've mentioned this before... and now that we have a 2.0 branch
and trunk has moved on to 2.1 work, I think its time we really make a
decision on this and implement it.
Before, I had been thinking of keeping all of the modules in the
server/trunk tree just in better locations organized by functionality
and feature not by artifact type. But, now I'm thinking we should
really do one step more than that, and split up the server/trunk
project into several smaller and more manageable chunks of modules.
I still think that the basic grouping that we kinda talked about
before should work fine, but instead of having them share a project
namespace we give them their own.
So, for example...
server-support/trunk
testsupport
buildsupport
server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder
And then we can group some of the related components up into shared
projects, or just go out and give each component its own project, and/
or think about maybe using the same style that the maven/plugins/
trunk tree uses, a shared project, but each component is related
individually... still not sure I like that, kinda messy.
I don't want to end up with a ton of projects either, and I certainly
don't want to get up using SNAPSHOT versions of these puppies if we
can help it. So, maybe to start out we could do these:
server-support
server-framework
server-components
server-assembly
BTW, I'm using "dash" here so that the names don't collide with what
is there now, but really we could user server/support/trunk, server/
framework/trunk, etc (which is better IMO for the longer run).
And in the process of making this split up, we can re-arrange modules
by feature and function instead of by type... and actually we have to
do that to make the components bits work.
* * *
I really believe this will help improve the support and
maintainability of the server's code-base and it will help the
project scale better as new components are added too. For developers
that are only interested in working on a specific component, it
reduces the amount of other sources they need to check out and
reduces the time to build too, so that they can build a clean server
assembly faster and developer their features sooner and hopefully
have less hair-pulling and more relaxed beer drinking as they pat
themselves on the back for doing such a speedy job.
I really, really... really, really, really ( :-P ) think that we
*must* move along these lines for the longer term health of the
project...
Comments? Suggestions?
--jason
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
> On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
>
>> we should consider the more drastic changes, like moving the base
>> Admin Console support (via Pluto 1.2) out to /plugins
>
> I really like that idea for a couple of reasons -
> - it allows us to keep the admin console that's currently at
> server/trunk/applications/console in place until the new extensible
> admin console is ready and can scale up from minimal to full JEE5
> functionality plus debug views, etc.
> - I like the idea of streamlining server/trunk for JEE5 stuff and
> moving the optional stuff elsewhere
>
> My only reservation (and its no biggie) is that using the location /
> plugins for optional stuff is misleading since there will be stuff
> in server/trunk that's required for JEE5 (i.e. not optional) but
> implemented as plugins like tomcat, jetty, amq, openejb, etc.
> Calling something a plugin is a statement about its packaging and
> deployment mechanism, and not whether it is required or optional.
>
> So maybe "/opt" or some such would be a better place to put the
> extensible admin console, tuscany (eventually), directory server,
> samples, roller, etc...
Personally, I don't consider the bits in /plugins as _optional_...
simply a home for the plug-able components and features that can be
dropped into the base server to make Geronimo do something useful.
After thinking about this more, I think that probably _most_ of the
stuff under server/trunk can get converted into a plugin and moved to
its own plugins/<component>/trunk, released and managed independently
of the core server framework. If we need to update the plugin bits
to make this work for more stuff, then we should do that, though I'm
not sure that is needed atm.
Then we'd end up with relatively smaller projects per feature/
component, a medium-sized project for the core server, and then a
project for the assemblies which we deliver (ie, the javaee bits,
which aggregate the javaee components, the server framework and the
configuration required to make it all work out of the box).
The only thing we have to be careful of is to not end up with a
massive set of versions to manage, so perhaps components need to have
some detail that indicates which version of the server they are
compatible with or something like that. I dunno... anyways, its
going to take some more discussion and planning before we can get to
making this a reality, but I really trully do believe that we *must*
do this to scale the management and development of Geronimo.
>> and start moving the Portlets into the actual modules/configs that
>> they administer....
>
> I like this idea from a conceptual point of view since it keeps
> things neat and well organized. But I am not sure how to implement
> it since the main geronimo components are typically packaged in
> JARs, and the admin portlets for a component have to be packaged in
> a WAR (that's just the way that pluto works). i.e. a JAR can't
> contain a WAR.
>
> Some options I can think of:
> - use EAR as the packaging format for all geronimo components and
> package the admin WARs inside them
> - maintain geronimo components and their admin WARs separately.
> bind them at deployment time via the plugin installer's dependency
> resolution or by some enhancement to the maven car plugin
> - package the geronimo components as WARs so the admin portlets
> can be merged with them. (seems like the tail wagging the dog)
> - follow some organizational structure like in your previous email
> where each geronimo component has a module, config, and (now) WAR
> subdirectory
>
> Just brainstorming here...
Um, I dunno... maybe some of the new magical console stuff that is
going on can help. But my guess is we might have to implement a
dynamic portlet, which can be given an artifact from the repository,
and then load the real impl from that artifact and display it. Then
the portlet bits per component can be bundled into a jar and tossed
into the repo, and then the console can be configured with a list of
artifacts to load into portlets. Seems like that might work out
well, if the dynamic portlet impl simply handles the bridge to the
portlet impl in the artifact and once loaded, basically proxies
everything over to it.
'm just brainstorming too... and having *never* written a portlet in
my life... maybe it will work, maybe it won't...
Though, this is one area where I think a full portal impl like
jetspeed2 might be of help since its already got all the juice to do
this kinda dynamic portlet muck... or at least I'm hoping it does.
I'm just generalizing my experience with php portals like phpnuke and
postnuke which have this kinda plugabiliity built in.
I really do think though that this is really positive direction... as
right now the console is a horrible coupling point with all of the
bits inside of the server... and if we are going to start pulling
things apart into smaller more manageable chunks, this is certainly
one key component that will need to be re-factored to allow it to
happen.
Cheers,
--jason
Re: Splitting up the server into a few more chunks
Posted by David Jencks <da...@yahoo.com>.
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
> On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
>
>> we should consider the more drastic changes, like moving the base
>> Admin Console support (via Pluto 1.2) out to /plugins
>
> I really like that idea for a couple of reasons -
> - it allows us to keep the admin console that's currently at
> server/trunk/applications/console in place until the new extensible
> admin console is ready and can scale up from minimal to full JEE5
> functionality plus debug views, etc.
> - I like the idea of streamlining server/trunk for JEE5 stuff and
> moving the optional stuff elsewhere
>
> My only reservation (and its no biggie) is that using the location /
> plugins for optional stuff is misleading since there will be stuff
> in server/trunk that's required for JEE5 (i.e. not optional) but
> implemented as plugins like tomcat, jetty, amq, openejb, etc.
> Calling something a plugin is a statement about its packaging and
> deployment mechanism, and not whether it is required or optional.
>
> So maybe "/opt" or some such would be a better place to put the
> extensible admin console, tuscany (eventually), directory server,
> samples, roller, etc...
>
>> and start moving the Portlets into the actual modules/configs that
>> they administer....
>
> I like this idea from a conceptual point of view since it keeps
> things neat and well organized. But I am not sure how to implement
> it since the main geronimo components are typically packaged in
> JARs, and the admin portlets for a component have to be packaged in
> a WAR (that's just the way that pluto works). i.e. a JAR can't
> contain a WAR.
>
> Some options I can think of:
> - use EAR as the packaging format for all geronimo components and
> package the admin WARs inside them
> - maintain geronimo components and their admin WARs separately.
> bind them at deployment time via the plugin installer's dependency
> resolution or by some enhancement to the maven car plugin
> - package the geronimo components as WARs so the admin portlets
> can be merged with them. (seems like the tail wagging the dog)
> - follow some organizational structure like in your previous email
> where each geronimo component has a module, config, and (now) WAR
> subdirectory
>
> Just brainstorming here...
I think we want to use "plugin groups" which IIRC is already
implemented in some way. So I see a typical feature (say jetty
support) as having 3 plugins:
- runtime jetty (geronimo-jetty6 module + jetty car)
- deploy time jetty (geronimo-jetty6-builder + jetty-deployer car)
- admin jetty (war with jetty admin portlets)
To keep it simple I'm purposefully forgetting about wadi clustering
support.
I think you should be able to install (1), (1 and 3) (1 and 2) or (1
2 and 3).
thanks
david jencks
>
>
> Best wishes,
> Paul
Re: Splitting up the server into a few more chunks
Posted by Paul McMahan <pa...@gmail.com>.
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
> we should consider the more drastic changes, like moving the base
> Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to keep the admin console that's currently at server/
trunk/applications/console in place until the new extensible admin
console is ready and can scale up from minimal to full JEE5
functionality plus debug views, etc.
- I like the idea of streamlining server/trunk for JEE5 stuff and
moving the optional stuff elsewhere
My only reservation (and its no biggie) is that using the location /
plugins for optional stuff is misleading since there will be stuff in
server/trunk that's required for JEE5 (i.e. not optional) but
implemented as plugins like tomcat, jetty, amq, openejb, etc.
Calling something a plugin is a statement about its packaging and
deployment mechanism, and not whether it is required or optional.
So maybe "/opt" or some such would be a better place to put the
extensible admin console, tuscany (eventually), directory server,
samples, roller, etc...
> and start moving the Portlets into the actual modules/configs that
> they administer....
I like this idea from a conceptual point of view since it keeps
things neat and well organized. But I am not sure how to implement
it since the main geronimo components are typically packaged in JARs,
and the admin portlets for a component have to be packaged in a WAR
(that's just the way that pluto works). i.e. a JAR can't contain a WAR.
Some options I can think of:
- use EAR as the packaging format for all geronimo components and
package the admin WARs inside them
- maintain geronimo components and their admin WARs separately. bind
them at deployment time via the plugin installer's dependency
resolution or by some enhancement to the maven car plugin
- package the geronimo components as WARs so the admin portlets can
be merged with them. (seems like the tail wagging the dog)
- follow some organizational structure like in your previous email
where each geronimo component has a module, config, and (now) WAR
subdirectory
Just brainstorming here...
Best wishes,
Paul
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote:
> Anything more than 6 to 8 groupings could cause chaos (just like at
> our current release process which takes weeks to get everything
> voted and released...)
> After cleanup of server to move the samples to /samples and
> ApacheDS to /plugins, we should consider the more drastic changes,
> like moving the base Admin Console support (via Pluto 1.2) out to /
> plugins and start moving the Portlets into the actual modules/
> configs that they administer....
>
> Some other "grouping" that may make sense are -
> - core - renamed /server/modules directory promoted to a top-level
> grouping and only contains server modules
> - configs - current configs, which can be installed as plugins
I'd really like to see the grouping of just configuration modules go
away. I firmly believe that configuration modules should live right
next to the code modules for which they are configuration for.
> - assemblies - current assemblies, which require the configs as input
I'd like to see the main assembly configuration split off from the
server/core/whatever stuff. Actually, I'd like to see the core/
framework as a sub-project, then have the server sub-project server
only to configure the plugins to be pulled in and the assembly
configurations for the javaee server distributions.
--jason
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote:
> Another thought (now that I had some lunch....)
>
> What if we create a "builders/deployers" grouping, which contained
> the modules and configs needed for each builder, like -
> deployers
> myfaces
> modules
> geronimo-myfaces
> geronimo-myfaces-builder
> configs
> myfaces
> myfaces-deployers
> tomcat
> . . .
> jetty
> . . .
>
> Anything that didn't fit into a deployer/builder category, could go
> into a system grouping or the existing components group.
I forget what I said about this before... but just in case I didn't
say it... I'm really *not* fond of grouping things under a "deployer
(s)" name. I think we have a core/framework, a set of reusable
components (non-plugins, ie. tx manager, jndi provider or whatever),
a set of plugins which provide additional functionality (could be
deployment, could be daemon processes, whatever), a set of standard
applications (like the web console), and a set of assemblies (which
glue it all together).
So, based on that I think that:
framework|core/trunk
components/<component>/trunk
plugins/<plugin>/trunk
apps/<app>/trunk
server/<server>/trunk (where server is javaee/minimal/crackpipe/
etc)
uberserver/trunk (uses svn:externals to make a workspace with
all the bits to compile for those who like to watch paint dry as the
beast builds)
For now I'd like to see the components, plugins and apps trees
contain separate sub-projects for each chunk of functionality,
versioned and released independently. I'm guessing that these
projects might contain anywhere from 2-10 modules or so, probably
averaging at 4, maybe 3. Ya, I know its more moving parts to manage,
but IMO, I think this will simplify many aspects of delivering a rock
solid application server (and framework) to the world. And if we do
it right we should be able to quickly adapt and fix bugs for faster
turn around. And well, it will also make some of our lives a lot
simpler since with *most* of the server being in separate smaller sub-
projects which are released, there is a heck of a lot less code to
build.
Well, anyways... no matter how we slice it... we need to do
something. And we should really get some yays and nays in the next
week or so about the _general_ plan... and then start to stage the
move... because it will affect developers, there will be oh-so-fun
merges to be done, and someone is not going to be happy I'm sure...
but we need to do it.
And, well with my code slinging cowbow hat on I'd say lets just go
balls out and do it. Once we have a general plan, implementing will
take a week maybe (to get it all sorted and back to happy happy
again), assuming there are no super-evil coupling points.
/me will shutup now
--jason
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
I'd rather not have another level to simply separate code jars from
config jars... I think they should all live together, and if needed
we suffix the config bits with "-config", so you'd have:
activemq-broker
activemq-broker-config
activemq-ra
activemq-ra-config
IMO, no need for another level of nested directories.
But regaurdless, my drive here is to help make it easier for folks to
develop G and develop G plugins w/o having to build the entire
server, which as well all know can be problematic from time to time.
--jason
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote:
> Another thought (now that I had some lunch....)
>
> What if we create a "builders/deployers" grouping, which contained
> the modules and configs needed for each builder, like -
> deployers
> myfaces
> modules
> geronimo-myfaces
> geronimo-myfaces-builder
> configs
> myfaces
> myfaces-deployers
> tomcat
> . . .
> jetty
> . . .
>
> Anything that didn't fit into a deployer/builder category, could go
> into a system grouping or the existing components group.
>
>
> Then again, maybe we need to step back from the current source code
> structure and think more along the lines of Lego blocks or OSGi
> bundles in a server, agree to what that "framework" would look like
> and then slice and dice our current .m2 structure into those new
> buckets.....
>
>
> -Donald
>
> Donald Woods wrote:
>> Anything more than 6 to 8 groupings could cause chaos (just like
>> at our current release process which takes weeks to get everything
>> voted and released...)
>> We already have 5 groupings created -
>> - devtools (Eclipse, Netbeans, J2G)
>> - plugins (non-JEE5 required server add-ons)
>> - samples (should contain all samples from current server and the
>> wiki)
>> - components (shared/used by other projects)
>> - server (current catch-all)
>> After cleanup of server to move the samples to /samples and
>> ApacheDS to /plugins, we should consider the more drastic changes,
>> like moving the base Admin Console support (via Pluto 1.2) out to /
>> plugins and start moving the Portlets into the actual modules/
>> configs that they administer....
>> Some other "grouping" that may make sense are -
>> - core - renamed /server/modules directory promoted to a top-level
>> grouping and only contains server modules
>> - configs - current configs, which can be installed as plugins
>> - assemblies - current assemblies, which require the configs as input
>> -Donald
>> Jason Dillon wrote:
>>> Um, I just took a blind stab in the dark...
>>>
>>> But, what I was thinking was that we have the core modules which
>>> are the bare minimum to boot up a functional Geronimo server w/o
>>> any JavaEE muck, then slice up the other components into plugins,
>>> though they don't really need to be G plugins, they just need to
>>> hold groups of modules to provide a components functionality and
>>> configuration.
>>>
>>> I also split up the support bits, as those should be common
>>> across the core framework bits and components/plugins...
>>>
>>> I'm certainly open to ideas and discussion on this. I think we
>>> really need to move in this direction.
>>>
>>> --jason
>>>
>>>
>>> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>>>
>>>> I certainly agree with your goal but am less sure about your
>>>> proposed naming and organization. Also from looking at your
>>>> list it took me a couple minutes to figure out what is removed
>>>> from "server"
>>>>
>>>> I've been thinking that we could proceed by turning bits of the
>>>> server into plugins. For instance I was planning to turn the
>>>> directory bits I commented out recently into a plugin this
>>>> week. I think we could fairly easiiy turn jetty, tomcat, and
>>>> openejb into plugins. I wonder if, after turning the "easy
>>>> stuff" into plugins what we will think about reorganizing the
>>>> remaining stuff.
>>>>
>>>> So then the question might be how to organize the plugins?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>>>>
>>>>> Hiya, I've mentioned this before... and now that we have a 2.0
>>>>> branch and trunk has moved on to 2.1 work, I think its time we
>>>>> really make a decision on this and implement it.
>>>>>
>>>>> Before, I had been thinking of keeping all of the modules in
>>>>> the server/trunk tree just in better locations organized by
>>>>> functionality and feature not by artifact type. But, now I'm
>>>>> thinking we should really do one step more than that, and split
>>>>> up the server/trunk project into several smaller and more
>>>>> manageable chunks of modules. I still think that the basic
>>>>> grouping that we kinda talked about before should work fine,
>>>>> but instead of having them share a project namespace we give
>>>>> them their own.
>>>>>
>>>>> So, for example...
>>>>>
>>>>> server-support/trunk
>>>>> testsupport
>>>>> buildsupport
>>>>>
>>>>> server-framework/trunk
>>>>> geronimo-activation
>>>>> geronimo-client
>>>>> geronimo-client-builder
>>>>> geronimo-clustering
>>>>> geronimo-common
>>>>> geronimo-connector
>>>>> geronimo-connector-builder
>>>>> geronimo-core
>>>>> geronimo-deploy-config
>>>>> geronimo-deploy-jsr88
>>>>> geronimo-deploy-jsr88-bootstrapper
>>>>> geronimo-deploy-tool
>>>>> geronimo-deployment
>>>>> geronimo-gbean-deployer
>>>>> geronimo-interceptor
>>>>> geronimo-j2ee
>>>>> geronimo-j2ee-builder
>>>>> geronimo-j2ee-schema
>>>>> geronimo-jmx-remoting
>>>>> geronimo-kernel
>>>>> geronimo-management
>>>>> geronimo-naming
>>>>> geronimo-naming-builder
>>>>> geronimo-security
>>>>> geronimo-security-builder
>>>>> geronimo-service-builder
>>>>> geronimo-system
>>>>> geronimo-test-ddbean
>>>>> geronimo-timer
>>>>> geronimo-transaction
>>>>> geronimo-transaction-jta11
>>>>> geronimo-transformer
>>>>> geronimo-util
>>>>> geronimo-web-2.5-builder
>>>>>
>>>>> And then we can group some of the related components up into
>>>>> shared projects, or just go out and give each component its own
>>>>> project, and/or think about maybe using the same style that the
>>>>> maven/plugins/trunk tree uses, a shared project, but each
>>>>> component is related individually... still not sure I like
>>>>> that, kinda messy.
>>>>>
>>>>> I don't want to end up with a ton of projects either, and I
>>>>> certainly don't want to get up using SNAPSHOT versions of these
>>>>> puppies if we can help it. So, maybe to start out we could do
>>>>> these:
>>>>>
>>>>> server-support
>>>>> server-framework
>>>>> server-components
>>>>> server-assembly
>>>>>
>>>>> BTW, I'm using "dash" here so that the names don't collide with
>>>>> what is there now, but really we could user server/support/
>>>>> trunk, server/framework/trunk, etc (which is better IMO for the
>>>>> longer run).
>>>>>
>>>>> And in the process of making this split up, we can re-arrange
>>>>> modules by feature and function instead of by type... and
>>>>> actually we have to do that to make the components bits work.
>>>>>
>>>>> * * *
>>>>>
>>>>> I really believe this will help improve the support and
>>>>> maintainability of the server's code-base and it will help the
>>>>> project scale better as new components are added too. For
>>>>> developers that are only interested in working on a specific
>>>>> component, it reduces the amount of other sources they need to
>>>>> check out and reduces the time to build too, so that they can
>>>>> build a clean server assembly faster and developer their
>>>>> features sooner and hopefully have less hair-pulling and more
>>>>> relaxed beer drinking as they pat themselves on the back for
>>>>> doing such a speedy job.
>>>>>
>>>>> I really, really... really, really, really ( :-P ) think that
>>>>> we *must* move along these lines for the longer term health of
>>>>> the project...
>>>>>
>>>>> Comments? Suggestions?
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
Re: Splitting up the server into a few more chunks
Posted by Donald Woods <dw...@apache.org>.
Another thought (now that I had some lunch....)
What if we create a "builders/deployers" grouping, which contained the modules
and configs needed for each builder, like -
deployers
myfaces
modules
geronimo-myfaces
geronimo-myfaces-builder
configs
myfaces
myfaces-deployers
tomcat
. . .
jetty
. . .
Anything that didn't fit into a deployer/builder category, could go into a
system grouping or the existing components group.
Then again, maybe we need to step back from the current source code structure
and think more along the lines of Lego blocks or OSGi bundles in a server,
agree to what that "framework" would look like and then slice and dice our
current .m2 structure into those new buckets.....
-Donald
Donald Woods wrote:
> Anything more than 6 to 8 groupings could cause chaos (just like at our
> current release process which takes weeks to get everything voted and
> released...)
>
> We already have 5 groupings created -
> - devtools (Eclipse, Netbeans, J2G)
> - plugins (non-JEE5 required server add-ons)
> - samples (should contain all samples from current server and the wiki)
> - components (shared/used by other projects)
> - server (current catch-all)
>
> After cleanup of server to move the samples to /samples and ApacheDS to
> /plugins, we should consider the more drastic changes, like moving the
> base Admin Console support (via Pluto 1.2) out to /plugins and start
> moving the Portlets into the actual modules/configs that they
> administer....
>
> Some other "grouping" that may make sense are -
> - core - renamed /server/modules directory promoted to a top-level
> grouping and only contains server modules
> - configs - current configs, which can be installed as plugins
> - assemblies - current assemblies, which require the configs as input
>
>
> -Donald
>
> Jason Dillon wrote:
>> Um, I just took a blind stab in the dark...
>>
>> But, what I was thinking was that we have the core modules which are
>> the bare minimum to boot up a functional Geronimo server w/o any
>> JavaEE muck, then slice up the other components into plugins, though
>> they don't really need to be G plugins, they just need to hold groups
>> of modules to provide a components functionality and configuration.
>>
>> I also split up the support bits, as those should be common across the
>> core framework bits and components/plugins...
>>
>> I'm certainly open to ideas and discussion on this. I think we really
>> need to move in this direction.
>>
>> --jason
>>
>>
>> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>>
>>> I certainly agree with your goal but am less sure about your proposed
>>> naming and organization. Also from looking at your list it took me a
>>> couple minutes to figure out what is removed from "server"
>>>
>>> I've been thinking that we could proceed by turning bits of the
>>> server into plugins. For instance I was planning to turn the
>>> directory bits I commented out recently into a plugin this week. I
>>> think we could fairly easiiy turn jetty, tomcat, and openejb into
>>> plugins. I wonder if, after turning the "easy stuff" into plugins
>>> what we will think about reorganizing the remaining stuff.
>>>
>>> So then the question might be how to organize the plugins?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>>>
>>>> Hiya, I've mentioned this before... and now that we have a 2.0
>>>> branch and trunk has moved on to 2.1 work, I think its time we
>>>> really make a decision on this and implement it.
>>>>
>>>> Before, I had been thinking of keeping all of the modules in the
>>>> server/trunk tree just in better locations organized by
>>>> functionality and feature not by artifact type. But, now I'm
>>>> thinking we should really do one step more than that, and split up
>>>> the server/trunk project into several smaller and more manageable
>>>> chunks of modules. I still think that the basic grouping that we
>>>> kinda talked about before should work fine, but instead of having
>>>> them share a project namespace we give them their own.
>>>>
>>>> So, for example...
>>>>
>>>> server-support/trunk
>>>> testsupport
>>>> buildsupport
>>>>
>>>> server-framework/trunk
>>>> geronimo-activation
>>>> geronimo-client
>>>> geronimo-client-builder
>>>> geronimo-clustering
>>>> geronimo-common
>>>> geronimo-connector
>>>> geronimo-connector-builder
>>>> geronimo-core
>>>> geronimo-deploy-config
>>>> geronimo-deploy-jsr88
>>>> geronimo-deploy-jsr88-bootstrapper
>>>> geronimo-deploy-tool
>>>> geronimo-deployment
>>>> geronimo-gbean-deployer
>>>> geronimo-interceptor
>>>> geronimo-j2ee
>>>> geronimo-j2ee-builder
>>>> geronimo-j2ee-schema
>>>> geronimo-jmx-remoting
>>>> geronimo-kernel
>>>> geronimo-management
>>>> geronimo-naming
>>>> geronimo-naming-builder
>>>> geronimo-security
>>>> geronimo-security-builder
>>>> geronimo-service-builder
>>>> geronimo-system
>>>> geronimo-test-ddbean
>>>> geronimo-timer
>>>> geronimo-transaction
>>>> geronimo-transaction-jta11
>>>> geronimo-transformer
>>>> geronimo-util
>>>> geronimo-web-2.5-builder
>>>>
>>>> And then we can group some of the related components up into shared
>>>> projects, or just go out and give each component its own project,
>>>> and/or think about maybe using the same style that the
>>>> maven/plugins/trunk tree uses, a shared project, but each component
>>>> is related individually... still not sure I like that, kinda messy.
>>>>
>>>> I don't want to end up with a ton of projects either, and I
>>>> certainly don't want to get up using SNAPSHOT versions of these
>>>> puppies if we can help it. So, maybe to start out we could do these:
>>>>
>>>> server-support
>>>> server-framework
>>>> server-components
>>>> server-assembly
>>>>
>>>> BTW, I'm using "dash" here so that the names don't collide with what
>>>> is there now, but really we could user server/support/trunk,
>>>> server/framework/trunk, etc (which is better IMO for the longer run).
>>>>
>>>> And in the process of making this split up, we can re-arrange
>>>> modules by feature and function instead of by type... and actually
>>>> we have to do that to make the components bits work.
>>>>
>>>> * * *
>>>>
>>>> I really believe this will help improve the support and
>>>> maintainability of the server's code-base and it will help the
>>>> project scale better as new components are added too. For
>>>> developers that are only interested in working on a specific
>>>> component, it reduces the amount of other sources they need to check
>>>> out and reduces the time to build too, so that they can build a
>>>> clean server assembly faster and developer their features sooner and
>>>> hopefully have less hair-pulling and more relaxed beer drinking as
>>>> they pat themselves on the back for doing such a speedy job.
>>>>
>>>> I really, really... really, really, really ( :-P ) think that we
>>>> *must* move along these lines for the longer term health of the
>>>> project...
>>>>
>>>> Comments? Suggestions?
>>>>
>>>> --jason
>>>>
>>>>
>>>
>>
>>
>>
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote:
> Anything more than 6 to 8 groupings could cause chaos (just like at
> our current release process which takes weeks to get everything
> voted and released...)
Yes, it has to be done very carefully, though if you look a Maven,
Plexus and the related bits, they tend to release smaller groups of
modules together and for the most part it does work.
> We already have 5 groupings created -
> - devtools (Eclipse, Netbeans, J2G)
> - plugins (non-JEE5 required server add-ons)
> - samples (should contain all samples from current server and the
> wiki)
> - components (shared/used by other projects)
> - server (current catch-all)
>
> After cleanup of server to move the samples to /samples and
> ApacheDS to /plugins, we should consider the more drastic changes,
> like moving the base Admin Console support (via Pluto 1.2) out to /
> plugins and start moving the Portlets into the actual modules/
> configs that they administer....
>
> Some other "grouping" that may make sense are -
> - core - renamed /server/modules directory promoted to a top-level
> grouping and only contains server modules
> - configs - current configs, which can be installed as plugins
One key thing that *must* change IMO, is we need to group code jars
with config jars (cars), the current split of modules/* configs/* is
very artificial and doesn't really help make things easy for
developers to update a specific component with out a lot of cd; mvn;
junk or custom scripts.
--jason
Re: Splitting up the server into a few more chunks
Posted by Donald Woods <dw...@apache.org>.
Anything more than 6 to 8 groupings could cause chaos (just like at our
current release process which takes weeks to get everything voted and released...)
We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the wiki)
- components (shared/used by other projects)
- server (current catch-all)
After cleanup of server to move the samples to /samples and ApacheDS to
/plugins, we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins and start moving the
Portlets into the actual modules/configs that they administer....
Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level grouping
and only contains server modules
- configs - current configs, which can be installed as plugins
- assemblies - current assemblies, which require the configs as input
-Donald
Jason Dillon wrote:
> Um, I just took a blind stab in the dark...
>
> But, what I was thinking was that we have the core modules which are
> the bare minimum to boot up a functional Geronimo server w/o any JavaEE
> muck, then slice up the other components into plugins, though they don't
> really need to be G plugins, they just need to hold groups of modules to
> provide a components functionality and configuration.
>
> I also split up the support bits, as those should be common across the
> core framework bits and components/plugins...
>
> I'm certainly open to ideas and discussion on this. I think we really
> need to move in this direction.
>
> --jason
>
>
> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>
>> I certainly agree with your goal but am less sure about your proposed
>> naming and organization. Also from looking at your list it took me a
>> couple minutes to figure out what is removed from "server"
>>
>> I've been thinking that we could proceed by turning bits of the server
>> into plugins. For instance I was planning to turn the directory bits
>> I commented out recently into a plugin this week. I think we could
>> fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder
>> if, after turning the "easy stuff" into plugins what we will think
>> about reorganizing the remaining stuff.
>>
>> So then the question might be how to organize the plugins?
>>
>> thanks
>> david jencks
>>
>> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>>
>>> Hiya, I've mentioned this before... and now that we have a 2.0 branch
>>> and trunk has moved on to 2.1 work, I think its time we really make a
>>> decision on this and implement it.
>>>
>>> Before, I had been thinking of keeping all of the modules in the
>>> server/trunk tree just in better locations organized by functionality
>>> and feature not by artifact type. But, now I'm thinking we should
>>> really do one step more than that, and split up the server/trunk
>>> project into several smaller and more manageable chunks of modules.
>>> I still think that the basic grouping that we kinda talked about
>>> before should work fine, but instead of having them share a project
>>> namespace we give them their own.
>>>
>>> So, for example...
>>>
>>> server-support/trunk
>>> testsupport
>>> buildsupport
>>>
>>> server-framework/trunk
>>> geronimo-activation
>>> geronimo-client
>>> geronimo-client-builder
>>> geronimo-clustering
>>> geronimo-common
>>> geronimo-connector
>>> geronimo-connector-builder
>>> geronimo-core
>>> geronimo-deploy-config
>>> geronimo-deploy-jsr88
>>> geronimo-deploy-jsr88-bootstrapper
>>> geronimo-deploy-tool
>>> geronimo-deployment
>>> geronimo-gbean-deployer
>>> geronimo-interceptor
>>> geronimo-j2ee
>>> geronimo-j2ee-builder
>>> geronimo-j2ee-schema
>>> geronimo-jmx-remoting
>>> geronimo-kernel
>>> geronimo-management
>>> geronimo-naming
>>> geronimo-naming-builder
>>> geronimo-security
>>> geronimo-security-builder
>>> geronimo-service-builder
>>> geronimo-system
>>> geronimo-test-ddbean
>>> geronimo-timer
>>> geronimo-transaction
>>> geronimo-transaction-jta11
>>> geronimo-transformer
>>> geronimo-util
>>> geronimo-web-2.5-builder
>>>
>>> And then we can group some of the related components up into shared
>>> projects, or just go out and give each component its own project,
>>> and/or think about maybe using the same style that the
>>> maven/plugins/trunk tree uses, a shared project, but each component
>>> is related individually... still not sure I like that, kinda messy.
>>>
>>> I don't want to end up with a ton of projects either, and I certainly
>>> don't want to get up using SNAPSHOT versions of these puppies if we
>>> can help it. So, maybe to start out we could do these:
>>>
>>> server-support
>>> server-framework
>>> server-components
>>> server-assembly
>>>
>>> BTW, I'm using "dash" here so that the names don't collide with what
>>> is there now, but really we could user server/support/trunk,
>>> server/framework/trunk, etc (which is better IMO for the longer run).
>>>
>>> And in the process of making this split up, we can re-arrange modules
>>> by feature and function instead of by type... and actually we have to
>>> do that to make the components bits work.
>>>
>>> * * *
>>>
>>> I really believe this will help improve the support and
>>> maintainability of the server's code-base and it will help the
>>> project scale better as new components are added too. For developers
>>> that are only interested in working on a specific component, it
>>> reduces the amount of other sources they need to check out and
>>> reduces the time to build too, so that they can build a clean server
>>> assembly faster and developer their features sooner and hopefully
>>> have less hair-pulling and more relaxed beer drinking as they pat
>>> themselves on the back for doing such a speedy job.
>>>
>>> I really, really... really, really, really ( :-P ) think that we
>>> *must* move along these lines for the longer term health of the
>>> project...
>>>
>>> Comments? Suggestions?
>>>
>>> --jason
>>>
>>>
>>
>
>
>
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
Um, I just took a blind stab in the dark...
But, what I was thinking was that we have the core modules which are
the bare minimum to boot up a functional Geronimo server w/o any
JavaEE muck, then slice up the other components into plugins, though
they don't really need to be G plugins, they just need to hold groups
of modules to provide a components functionality and configuration.
I also split up the support bits, as those should be common across
the core framework bits and components/plugins...
I'm certainly open to ideas and discussion on this. I think we
really need to move in this direction.
--jason
On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
> I certainly agree with your goal but am less sure about your
> proposed naming and organization. Also from looking at your list
> it took me a couple minutes to figure out what is removed from
> "server"
>
> I've been thinking that we could proceed by turning bits of the
> server into plugins. For instance I was planning to turn the
> directory bits I commented out recently into a plugin this week. I
> think we could fairly easiiy turn jetty, tomcat, and openejb into
> plugins. I wonder if, after turning the "easy stuff" into plugins
> what we will think about reorganizing the remaining stuff.
>
> So then the question might be how to organize the plugins?
>
> thanks
> david jencks
>
> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>
>> Hiya, I've mentioned this before... and now that we have a 2.0
>> branch and trunk has moved on to 2.1 work, I think its time we
>> really make a decision on this and implement it.
>>
>> Before, I had been thinking of keeping all of the modules in the
>> server/trunk tree just in better locations organized by
>> functionality and feature not by artifact type. But, now I'm
>> thinking we should really do one step more than that, and split up
>> the server/trunk project into several smaller and more manageable
>> chunks of modules. I still think that the basic grouping that we
>> kinda talked about before should work fine, but instead of having
>> them share a project namespace we give them their own.
>>
>> So, for example...
>>
>> server-support/trunk
>> testsupport
>> buildsupport
>>
>> server-framework/trunk
>> geronimo-activation
>> geronimo-client
>> geronimo-client-builder
>> geronimo-clustering
>> geronimo-common
>> geronimo-connector
>> geronimo-connector-builder
>> geronimo-core
>> geronimo-deploy-config
>> geronimo-deploy-jsr88
>> geronimo-deploy-jsr88-bootstrapper
>> geronimo-deploy-tool
>> geronimo-deployment
>> geronimo-gbean-deployer
>> geronimo-interceptor
>> geronimo-j2ee
>> geronimo-j2ee-builder
>> geronimo-j2ee-schema
>> geronimo-jmx-remoting
>> geronimo-kernel
>> geronimo-management
>> geronimo-naming
>> geronimo-naming-builder
>> geronimo-security
>> geronimo-security-builder
>> geronimo-service-builder
>> geronimo-system
>> geronimo-test-ddbean
>> geronimo-timer
>> geronimo-transaction
>> geronimo-transaction-jta11
>> geronimo-transformer
>> geronimo-util
>> geronimo-web-2.5-builder
>>
>> And then we can group some of the related components up into
>> shared projects, or just go out and give each component its own
>> project, and/or think about maybe using the same style that the
>> maven/plugins/trunk tree uses, a shared project, but each
>> component is related individually... still not sure I like that,
>> kinda messy.
>>
>> I don't want to end up with a ton of projects either, and I
>> certainly don't want to get up using SNAPSHOT versions of these
>> puppies if we can help it. So, maybe to start out we could do these:
>>
>> server-support
>> server-framework
>> server-components
>> server-assembly
>>
>> BTW, I'm using "dash" here so that the names don't collide with
>> what is there now, but really we could user server/support/trunk,
>> server/framework/trunk, etc (which is better IMO for the longer run).
>>
>> And in the process of making this split up, we can re-arrange
>> modules by feature and function instead of by type... and actually
>> we have to do that to make the components bits work.
>>
>> * * *
>>
>> I really believe this will help improve the support and
>> maintainability of the server's code-base and it will help the
>> project scale better as new components are added too. For
>> developers that are only interested in working on a specific
>> component, it reduces the amount of other sources they need to
>> check out and reduces the time to build too, so that they can
>> build a clean server assembly faster and developer their features
>> sooner and hopefully have less hair-pulling and more relaxed beer
>> drinking as they pat themselves on the back for doing such a
>> speedy job.
>>
>> I really, really... really, really, really ( :-P ) think that we
>> *must* move along these lines for the longer term health of the
>> project...
>>
>> Comments? Suggestions?
>>
>> --jason
>>
>>
>
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>
>> I certainly agree with your goal but am less sure about your
>> proposed naming and organization. Also from looking at your list
>> it took me a couple minutes to figure out what is removed from
>> "server"
>>
>> I've been thinking that we could proceed by turning bits of the
>> server into plugins. For instance I was planning to turn the
>> directory bits I commented out recently into a plugin this week.
>> I think we could fairly easiiy turn jetty, tomcat, and openejb
>> into plugins. I wonder if, after turning the "easy stuff" into
>> plugins what we will think about reorganizing the remaining stuff.
>>
>> So then the question might be how to organize the plugins?
>
> Haven't read the rest of the thread yet, but I'd like to backup the
> idea of pulling things out one at a time, like we did with
> connector and transaction, making them plugins if possible. It
> would be really great if people do things like upgrade OpenEJB when
> a new release came out -- which we're hoping is often.
Do you know of any other bits which we can pull out nowish (or with a
wee bit of work)?
I'd really like to get the kernel and muck sucked out, but I've got a
feeling that is a hugeish taskotron.
--jason
Re: Splitting up the server into a few more chunks
Posted by Paul McMahan <pa...@gmail.com>.
On Aug 29, 2007, at 1:12 PM, Prasad Kashyap wrote:
> 2. We have to split the current build tree into support, framework,
> and plugins sub-trees. Other than support and framework, everything
> else should be plugins. This includes jee5, non-jee5, samples etc.
> which could go in their own subtrees or be together.
I like your ideas. Taking a step back are we in agreement on the
"everything else as plugins" approach? We have been hinting at this
for some time and doing various interesting things with plugins but I
don't see enough of the big picture yet to provide much useful
feedback on your proposal. Maybe the time is right to start a big
picture discussion about plugins. I'll cook something up and maybe
that thread will help us answer some of your questions.
Best wishes,
Paul
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
I think we don't really need svn, lets just mail around patches we
make to the list and get rid of this scm crapo... too much work for
too little benifit.... lol
:-P
--jason
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote:
> I'm trying to understand what we have discussed/decided so far. Please
> let me know if my summary is on track and help me correct course.
>
> We haven't discussed the actual maven groupIds/artifactIds/directory
> names yet. So all names used in this summary are just as examples.
>
> Summary:
> ---------------
> 1. Our basic objective is to deliver a framework and a large set of
> components with which our users can build their own Geronimo server.
> The primary goal of our build restructuring exercise should be to help
> us meet this objective. The next goal should be to help us build
> smoothly and release efficiently.
>
> 2. We have to split the current build tree into support, framework,
> and plugins sub-trees. Other than support and framework, everything
> else should be plugins. This includes jee5, non-jee5, samples etc.
> which could go in their own subtrees or be together.
>
> Scenario 1:
> server/support/trunk
> server/framework/trunk
> server/plugins/trunk/ <--- jee5, non-jee5, samples etc are
> all here together.
>
> Scenario 2:
> server/support/trunk
> server/framework/trunk
> server/plugins/trunk/
> jee5/
> opt/
> samples/
>
> Scenario 3:
> server/support/trunk
> server/framework/trunk
> server/plugins/trunk <-- jee5 plugins
> server/opt/trunk <-- opt plugins
> server/samples/trunk <-- samples plugins
>
> Can we please pick a scenario here and move on ?
>
> 3. We have to restructure the build tree to make it feature-oriented
> rather than type-oriented like present. To take Jencks example, jetty
> runtime, jetty deployer and jetty admin should be kept together (as a
> plugin group) instead of keeping module jars and config cars separate.
>
> server/plugins/trunk/
> geronimo-jetty/
> jetty-runtime (1)
> jetty-deployer (2)
> jetty-admin (3)
>
> "I think you should be able to install (1), (1 and 3) (1 and 2) or
> (1, 2 and 3)." - Jencks.
>
>
> Further discussion:
> ----------------------------
> Currently the plugins tree is structured as plugins/<component>/trunk.
> IMO, this is not feasible in the long run, esp. when we want to
> convert most of everything we have into plugins, b'coz -
>
> 1. svn checkout of a complete Geronimo server (framework + all
> plugins) for a given version now becomes a nightmare.
> 2. building all plugins for a given version becomes difficult.
> 3. inheritance from a common parent becomes difficult. Many things
> will be duplicated across all the poms for all the plugins. Longer
> poms causes larger maintenance issues.
> 4. Even maven plugins whom we want to emulate for their independent
> release cycles are not structured this way. Trunk, branches, tags form
> the top tier. http://svn.apache.org/viewvc/maven/plugins/
>
> Cheers
> Prasad
>
>
> On 8/8/07, Jason Dillon <ja...@planet57.com> wrote:
>> On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
>>> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>>>
>>>> I certainly agree with your goal but am less sure about your
>>>> proposed naming and organization. Also from looking at your list
>>>> it took me a couple minutes to figure out what is removed from
>>>> "server"
>>>>
>>>> I've been thinking that we could proceed by turning bits of the
>>>> server into plugins. For instance I was planning to turn the
>>>> directory bits I commented out recently into a plugin this week.
>>>> I think we could fairly easiiy turn jetty, tomcat, and openejb
>>>> into plugins. I wonder if, after turning the "easy stuff" into
>>>> plugins what we will think about reorganizing the remaining stuff.
>>>>
>>>> So then the question might be how to organize the plugins?
>>>
>>> Haven't read the rest of the thread yet, but I'd like to backup the
>>> idea of pulling things out one at a time, like we did with
>>> connector and transaction, making them plugins if possible. It
>>> would be really great if people do things like upgrade OpenEJB when
>>> a new release came out -- which we're hoping is often.
>>
>> I'd still like to see the plugin mangement in the console work
>> something like the Confluence Plugin Repository Client ( http://
>> confluence.atlassian.com/display/CONFEXT/Confluence+Repository
>> +Client )
>>
>> Which has a sex UI to show whats installed (version, urls, notes,
>> etc), whats not (with simple buttons to install) and when stuff is
>> out of date (with simple buttons to upgrade). This would be *hugely*
>> powerful for administrators managing a Geronimo instance.
>>
>> :-)
>>
>>
>>
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote:
> Scenario 1:
> server/support/trunk
> server/framework/trunk
> server/plugins/trunk/ <--- jee5, non-jee5, samples etc are
> all here together.
I'm not really convinced we need to have this intermediate "server"
tree right now. IMO this is a bit over structured for a structure we
haven't really gotten a good idea for what it looks like.
I'd defer organizing the chunks we split off into smaller groups as
an exercise for once we've actually gotten then chunks pulled off.
Its easy enough to change later...
--jason
Re: Splitting up the server into a few more chunks
Posted by Prasad Kashyap <go...@gmail.com>.
I'm trying to understand what we have discussed/decided so far. Please
let me know if my summary is on track and help me correct course.
We haven't discussed the actual maven groupIds/artifactIds/directory
names yet. So all names used in this summary are just as examples.
Summary:
---------------
1. Our basic objective is to deliver a framework and a large set of
components with which our users can build their own Geronimo server.
The primary goal of our build restructuring exercise should be to help
us meet this objective. The next goal should be to help us build
smoothly and release efficiently.
2. We have to split the current build tree into support, framework,
and plugins sub-trees. Other than support and framework, everything
else should be plugins. This includes jee5, non-jee5, samples etc.
which could go in their own subtrees or be together.
Scenario 1:
server/support/trunk
server/framework/trunk
server/plugins/trunk/ <--- jee5, non-jee5, samples etc are
all here together.
Scenario 2:
server/support/trunk
server/framework/trunk
server/plugins/trunk/
jee5/
opt/
samples/
Scenario 3:
server/support/trunk
server/framework/trunk
server/plugins/trunk <-- jee5 plugins
server/opt/trunk <-- opt plugins
server/samples/trunk <-- samples plugins
Can we please pick a scenario here and move on ?
3. We have to restructure the build tree to make it feature-oriented
rather than type-oriented like present. To take Jencks example, jetty
runtime, jetty deployer and jetty admin should be kept together (as a
plugin group) instead of keeping module jars and config cars separate.
server/plugins/trunk/
geronimo-jetty/
jetty-runtime (1)
jetty-deployer (2)
jetty-admin (3)
"I think you should be able to install (1), (1 and 3) (1 and 2) or
(1, 2 and 3)." - Jencks.
Further discussion:
----------------------------
Currently the plugins tree is structured as plugins/<component>/trunk.
IMO, this is not feasible in the long run, esp. when we want to
convert most of everything we have into plugins, b'coz -
1. svn checkout of a complete Geronimo server (framework + all
plugins) for a given version now becomes a nightmare.
2. building all plugins for a given version becomes difficult.
3. inheritance from a common parent becomes difficult. Many things
will be duplicated across all the poms for all the plugins. Longer
poms causes larger maintenance issues.
4. Even maven plugins whom we want to emulate for their independent
release cycles are not structured this way. Trunk, branches, tags form
the top tier. http://svn.apache.org/viewvc/maven/plugins/
Cheers
Prasad
On 8/8/07, Jason Dillon <ja...@planet57.com> wrote:
> On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
> > On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
> >
> >> I certainly agree with your goal but am less sure about your
> >> proposed naming and organization. Also from looking at your list
> >> it took me a couple minutes to figure out what is removed from
> >> "server"
> >>
> >> I've been thinking that we could proceed by turning bits of the
> >> server into plugins. For instance I was planning to turn the
> >> directory bits I commented out recently into a plugin this week.
> >> I think we could fairly easiiy turn jetty, tomcat, and openejb
> >> into plugins. I wonder if, after turning the "easy stuff" into
> >> plugins what we will think about reorganizing the remaining stuff.
> >>
> >> So then the question might be how to organize the plugins?
> >
> > Haven't read the rest of the thread yet, but I'd like to backup the
> > idea of pulling things out one at a time, like we did with
> > connector and transaction, making them plugins if possible. It
> > would be really great if people do things like upgrade OpenEJB when
> > a new release came out -- which we're hoping is often.
>
> I'd still like to see the plugin mangement in the console work
> something like the Confluence Plugin Repository Client ( http://
> confluence.atlassian.com/display/CONFEXT/Confluence+Repository+Client )
>
> Which has a sex UI to show whats installed (version, urls, notes,
> etc), whats not (with simple buttons to install) and when stuff is
> out of date (with simple buttons to upgrade). This would be *hugely*
> powerful for administrators managing a Geronimo instance.
>
> :-)
>
>
>
Re: Splitting up the server into a few more chunks
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>
>> I certainly agree with your goal but am less sure about your
>> proposed naming and organization. Also from looking at your list
>> it took me a couple minutes to figure out what is removed from
>> "server"
>>
>> I've been thinking that we could proceed by turning bits of the
>> server into plugins. For instance I was planning to turn the
>> directory bits I commented out recently into a plugin this week.
>> I think we could fairly easiiy turn jetty, tomcat, and openejb
>> into plugins. I wonder if, after turning the "easy stuff" into
>> plugins what we will think about reorganizing the remaining stuff.
>>
>> So then the question might be how to organize the plugins?
>
> Haven't read the rest of the thread yet, but I'd like to backup the
> idea of pulling things out one at a time, like we did with
> connector and transaction, making them plugins if possible. It
> would be really great if people do things like upgrade OpenEJB when
> a new release came out -- which we're hoping is often.
I'd still like to see the plugin mangement in the console work
something like the Confluence Plugin Repository Client ( http://
confluence.atlassian.com/display/CONFEXT/Confluence+Repository+Client )
Which has a sex UI to show whats installed (version, urls, notes,
etc), whats not (with simple buttons to install) and when stuff is
out of date (with simple buttons to upgrade). This would be *hugely*
powerful for administrators managing a Geronimo instance.
:-)
Re: Splitting up the server into a few more chunks
Posted by David Blevins <da...@visi.com>.
On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
> I certainly agree with your goal but am less sure about your
> proposed naming and organization. Also from looking at your list
> it took me a couple minutes to figure out what is removed from
> "server"
>
> I've been thinking that we could proceed by turning bits of the
> server into plugins. For instance I was planning to turn the
> directory bits I commented out recently into a plugin this week. I
> think we could fairly easiiy turn jetty, tomcat, and openejb into
> plugins. I wonder if, after turning the "easy stuff" into plugins
> what we will think about reorganizing the remaining stuff.
>
> So then the question might be how to organize the plugins?
Haven't read the rest of the thread yet, but I'd like to backup the
idea of pulling things out one at a time, like we did with connector
and transaction, making them plugins if possible. It would be really
great if people do things like upgrade OpenEJB when a new release
came out -- which we're hoping is often.
-David
>
> thanks
> david jencks
>
> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>
>> Hiya, I've mentioned this before... and now that we have a 2.0
>> branch and trunk has moved on to 2.1 work, I think its time we
>> really make a decision on this and implement it.
>>
>> Before, I had been thinking of keeping all of the modules in the
>> server/trunk tree just in better locations organized by
>> functionality and feature not by artifact type. But, now I'm
>> thinking we should really do one step more than that, and split up
>> the server/trunk project into several smaller and more manageable
>> chunks of modules. I still think that the basic grouping that we
>> kinda talked about before should work fine, but instead of having
>> them share a project namespace we give them their own.
>>
>> So, for example...
>>
>> server-support/trunk
>> testsupport
>> buildsupport
>>
>> server-framework/trunk
>> geronimo-activation
>> geronimo-client
>> geronimo-client-builder
>> geronimo-clustering
>> geronimo-common
>> geronimo-connector
>> geronimo-connector-builder
>> geronimo-core
>> geronimo-deploy-config
>> geronimo-deploy-jsr88
>> geronimo-deploy-jsr88-bootstrapper
>> geronimo-deploy-tool
>> geronimo-deployment
>> geronimo-gbean-deployer
>> geronimo-interceptor
>> geronimo-j2ee
>> geronimo-j2ee-builder
>> geronimo-j2ee-schema
>> geronimo-jmx-remoting
>> geronimo-kernel
>> geronimo-management
>> geronimo-naming
>> geronimo-naming-builder
>> geronimo-security
>> geronimo-security-builder
>> geronimo-service-builder
>> geronimo-system
>> geronimo-test-ddbean
>> geronimo-timer
>> geronimo-transaction
>> geronimo-transaction-jta11
>> geronimo-transformer
>> geronimo-util
>> geronimo-web-2.5-builder
>>
>> And then we can group some of the related components up into
>> shared projects, or just go out and give each component its own
>> project, and/or think about maybe using the same style that the
>> maven/plugins/trunk tree uses, a shared project, but each
>> component is related individually... still not sure I like that,
>> kinda messy.
>>
>> I don't want to end up with a ton of projects either, and I
>> certainly don't want to get up using SNAPSHOT versions of these
>> puppies if we can help it. So, maybe to start out we could do these:
>>
>> server-support
>> server-framework
>> server-components
>> server-assembly
>>
>> BTW, I'm using "dash" here so that the names don't collide with
>> what is there now, but really we could user server/support/trunk,
>> server/framework/trunk, etc (which is better IMO for the longer run).
>>
>> And in the process of making this split up, we can re-arrange
>> modules by feature and function instead of by type... and actually
>> we have to do that to make the components bits work.
>>
>> * * *
>>
>> I really believe this will help improve the support and
>> maintainability of the server's code-base and it will help the
>> project scale better as new components are added too. For
>> developers that are only interested in working on a specific
>> component, it reduces the amount of other sources they need to
>> check out and reduces the time to build too, so that they can
>> build a clean server assembly faster and developer their features
>> sooner and hopefully have less hair-pulling and more relaxed beer
>> drinking as they pat themselves on the back for doing such a
>> speedy job.
>>
>> I really, really... really, really, really ( :-P ) think that we
>> *must* move along these lines for the longer term health of the
>> project...
>>
>> Comments? Suggestions?
>>
>> --jason
>>
>>
>
>
Re: Splitting up the server into a few more chunks
Posted by David Jencks <da...@yahoo.com>.
I certainly agree with your goal but am less sure about your proposed
naming and organization. Also from looking at your list it took me a
couple minutes to figure out what is removed from "server"
I've been thinking that we could proceed by turning bits of the
server into plugins. For instance I was planning to turn the
directory bits I commented out recently into a plugin this week. I
think we could fairly easiiy turn jetty, tomcat, and openejb into
plugins. I wonder if, after turning the "easy stuff" into plugins
what we will think about reorganizing the remaining stuff.
So then the question might be how to organize the plugins?
thanks
david jencks
On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
> Hiya, I've mentioned this before... and now that we have a 2.0
> branch and trunk has moved on to 2.1 work, I think its time we
> really make a decision on this and implement it.
>
> Before, I had been thinking of keeping all of the modules in the
> server/trunk tree just in better locations organized by
> functionality and feature not by artifact type. But, now I'm
> thinking we should really do one step more than that, and split up
> the server/trunk project into several smaller and more manageable
> chunks of modules. I still think that the basic grouping that we
> kinda talked about before should work fine, but instead of having
> them share a project namespace we give them their own.
>
> So, for example...
>
> server-support/trunk
> testsupport
> buildsupport
>
> server-framework/trunk
> geronimo-activation
> geronimo-client
> geronimo-client-builder
> geronimo-clustering
> geronimo-common
> geronimo-connector
> geronimo-connector-builder
> geronimo-core
> geronimo-deploy-config
> geronimo-deploy-jsr88
> geronimo-deploy-jsr88-bootstrapper
> geronimo-deploy-tool
> geronimo-deployment
> geronimo-gbean-deployer
> geronimo-interceptor
> geronimo-j2ee
> geronimo-j2ee-builder
> geronimo-j2ee-schema
> geronimo-jmx-remoting
> geronimo-kernel
> geronimo-management
> geronimo-naming
> geronimo-naming-builder
> geronimo-security
> geronimo-security-builder
> geronimo-service-builder
> geronimo-system
> geronimo-test-ddbean
> geronimo-timer
> geronimo-transaction
> geronimo-transaction-jta11
> geronimo-transformer
> geronimo-util
> geronimo-web-2.5-builder
>
> And then we can group some of the related components up into shared
> projects, or just go out and give each component its own project,
> and/or think about maybe using the same style that the maven/
> plugins/trunk tree uses, a shared project, but each component is
> related individually... still not sure I like that, kinda messy.
>
> I don't want to end up with a ton of projects either, and I
> certainly don't want to get up using SNAPSHOT versions of these
> puppies if we can help it. So, maybe to start out we could do these:
>
> server-support
> server-framework
> server-components
> server-assembly
>
> BTW, I'm using "dash" here so that the names don't collide with
> what is there now, but really we could user server/support/trunk,
> server/framework/trunk, etc (which is better IMO for the longer run).
>
> And in the process of making this split up, we can re-arrange
> modules by feature and function instead of by type... and actually
> we have to do that to make the components bits work.
>
> * * *
>
> I really believe this will help improve the support and
> maintainability of the server's code-base and it will help the
> project scale better as new components are added too. For
> developers that are only interested in working on a specific
> component, it reduces the amount of other sources they need to
> check out and reduces the time to build too, so that they can build
> a clean server assembly faster and developer their features sooner
> and hopefully have less hair-pulling and more relaxed beer drinking
> as they pat themselves on the back for doing such a speedy job.
>
> I really, really... really, really, really ( :-P ) think that we
> *must* move along these lines for the longer term health of the
> project...
>
> Comments? Suggestions?
>
> --jason
>
>