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
