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
