Ok ... take a deep breath.
This proposal was *not* just to work around windows. It was to offer
what I thought were constructive ideas and avoid exasperating a known
problem unnecessarily.
I understand your hesitation to bundle the builders and deployers
together (which is why I had a note there). What do you think about the
rest of the proposal?
- Type based groupings in addition to functional groupings.
- One level deep. While I love hierarchy, I think it's overkill here.
- Elimination of redundancy in names as much as possible. (BTW, I know
your post was a "crude stab" so I thought this was the type of input you
were requesting to refine it).
- "server" in place of "system"
- "features" in place of "plugins"
- Consistent naming of artifacts when the type is included in the name
(such as with builder and deployer).
Joe
Jason Dillon wrote:
On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote:
I'd like to propose that we keep things simple and eliminate
redundancy where possible. I'd also like to keep things as brief as
possible to prevent current or future issues with the windows
pathlength issue. I don't think the proposed changes will cause
immediate problems but I'd like to prevent/reduce the possibility of
problems.
<rant>
I really, really, really don't like to be restricted by the limitations
of a certain lame operating system... in fact it fills me with rage.
If windows still had 8.3 file name limitations... would we have to make
ever class conform to that naming system?! Windows is also case
insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting
files? Windows stuff crashed all of the time... do we add some hooks
to cause the server to crash just to fit in?!?
I am sorry your OS is retarded... but I see no reason to design the
build structure based on its limitations... especially if a different
layout make more sense to group logical modules together.
</rant>
Do I understand correctly that with this proposal what is currently
"modules/geronimo-j2ee-builder" would become
"system/geronimo-j2ee/geronimo-j2ee-builder"
.... and what is currently
"modules/geronimo-j2ee" would become
"system/geronimo-j2ee/geronimo-j2ee"?
If so, then I think we are introducing some unnecessary redundancy
once again.
No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I
mentioned this was a "crude stab" meaning that I did not take much time
to clean up, just put out the basic high level organization groups and
filled in the current modules.
BTW, do I understand correctly that you're proposing the removal of
"modules" or is this presumed to be prior to each of the new names?
Yes, modules is to be removed.
I wondering if it might be better to have more types and less
subtypes (perhaps deciding to have only a single collection of types
with no subtypes at all). Perhaps something like:
builders/ (not sure yet if I like this myself :-) )
geronimo-j2ee-builder
geronimo-service-builder
geronimo-axis-builder
geronimo-tomcat-builder
geronimo-jetty-builder
geronimo-security-builder
geronimo-service-builder
geronimo-connector-builder
geronimo-naming-builder
geronimo-client-builder
geronimo-j2ee-builder
geronimo-web-builder
I had thought about grouping the builders together... though I'm still
drawn about if these should be closer to their code modules or not.
Generally I'd like to have all of the tomcat integration code together,
all the jetty code together and so on...
--jason
** Note, the way we name builders and the way we name deployers is
inconsistent. I think we need to decide if we want the descriptive
type first or last in these names and use the pattern consistently.
deployers/
geronimo-deploy-core (was geronimo-deployment) ?
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-tool
geronimo-deploy-hot (was geronimo-hot-deploy ... just to be
consistent with other deployers but see note above) ?
framework/
geronimo-testsupport
geronimo-test-ddbean (not sure what this is either)
geronimo-common
geronimo-util
geronimo-interceptor
geronimo-activation
geronimo-kernel
server/
geronimo-management
geronimo-security
geronimo-core
geronimo-system
geronimo-transaction
geronimo-connector
geronimo-jmx-remoting
geronimo-naming
geronimo-client
geronimo-j2ee
geronimo-j2ee-schema
features/
geronimo-activemq-rar (rename)
geronimo-activemq-gbean
geronimo-activemq-gbean-management
geronimo-axis
geronimo-derby
geronimo-directory
geronimo-tomcat
geronimo-jetty
geronimo-mail
geronimo-timer
geronimo-webservices
tools/
geronimo-upgrade
geronimo-converter
Joe
Jason Dillon wrote:
So, I've mentioned a few times before that we should start thinking
about how to split up modules in trunk into a few smaller chunks.
I took a few minutes and took a crude stab at what that might look
like. This is just an example of how it might work... I did not do
any extensive research into dependencies...
Basically, I split things up into 5 main trees:
* framework - common stuff, not really the server, but supports
the server, modules here should have minimal deps
* system - the major components which make up the server's system
(should be the bits to start up a server shell)
* tools - bits that support the system
* plugins - components which plugin to the system
* testsuite - placeholder for modules which will be aded soon that
use the itest plugin to perform integration tests
I'm not sure if this is the best split, but it kinda comes closer
to what I hope we can get to. Below is how the modules that exists
fit into these sections.
----
framework/
geronimo-testsupport (may need to be in other tree? so can
include in all modules by default)
geronimo-common
geronimo-util
geronimo-interceptor
geronimo-activation
geronimo-kernel
system/
geronimo-management
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-core
geronimo-system
geronimo-transaction
geronimo-connector
geronimo-connector-builder
geronimo-jmx-remoting
geronimo-naming
geronimo-naming-builder
geronimo-test-ddbean (wtf is this for?)
geronimo-deployment/
geronimo-deployment (rename to -core) ?
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-tool
geronimo-hot-deploy
geronimo-client
geronimo-client-builder
geronimo-j2ee/
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-web-builder
plugins/
geronimo-activemq/
ge-activemq-rar (rename)
geronimo-activemq-gbean
geronimo-activemq-gbean-management
geronimo-axis
geronimo-axis-builder
geronimo-derby
geronimo-directory
geronimo-tomcat
geronimo-tomcat-builder
geronimo-jetty
geronimo-jetty-builder
geronimo-mail
geronimo-timer
geronimo-webservices
tools/
geronimo-upgrade
geronimo-converter
testsuite/
TODO, home for itest usage
----
Anyways, I wanted to post what I am thinking. I think that we are
really close to the point where we will want to implement this sort
of split up.
Comments?
--jason
