And here you go again... or do you need this in triplicate?
:-P
* * *
Matt, I have already explained why... at least twice :-P
If we want to remove the geronimo- prefix, then lets rename the
artifacts... which I think should be done anyways when the modules
are split up into smaller groups.
For example, if we have a components/ tree, which groups optional
components (stuff that is non-core), as in:
components/
activemq-component (makes activemq-component-*.jar)
axis-component (makes axis-component-*.jar)
This is basically what I do for GShell ( http://svn.apache.org/viewvc/
geronimo/sandbox/gshell/trunk/ ) though I do have the prefix on
children... but in this case gshell- is smaller than geronimo-
When I made that initial stab at a rough layout, I copied all of the
names as they were... so they al have geronimo- on them, but I hope
that as we move things about to organize them better that we can
change the artifact names removing the geronimo-* prefix, but
including the group in the artifactId someway.
I agree its redundant to to say these artifacts are geronimo-*, but
we need to add some other classifier...
I firmly believe that it is best to keep the directory and
artifactId's the same.
Maybe I should write up another crude tree example, with better
names... since many folks (like.. um... you :-P) seem to be hung up
the "naming" and missing the point about the "structure".
--jason
On Sep 5, 2006, at 11:00 PM, Matt Hogstrom wrote:
Is this a must have or a nice to have? Everything in the tree is
already geronimo and nicely fits in a geronimo dir in the maven
repo. Can someone from Maven enlighten me as to why the redundancy
is necessary and how redundancy is a good thing to be redundant.
Not to repeat myself, but I guess I'm not getting why redundancy is
good.
You might need to send me two e-mails of the same information so I
remember that I was asking about redundancy :)
What was I talking about? Oh yeah, redundancy.
Seems odd that the server structure has to match the build system.
Isn't that a bit of bleed through? Oh gosh, there I go again being
redundant. Sorry, I'm repeating myself, oh, there I go again.
Sorry...oops, one last time. ;-P
Dain Sundstrom wrote:
BTW I do think we should rename the dirs to match the maven
standard geronimo-foo standard.
-dain
On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote:
Fine with me.
The tree is still in need of reorganization even after those
modules are gone.
--jason
On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote:
Please don't get mad at me, but I'd like to move a bit slower on
more classification inside of the server module. I'd like to
pull transaction and connector out to independently versioned
modules and then see if the tree still feels crowded.
-dain
On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote:
I am sure that some of these names will change...
But the directory name should be the same as the artifactId...
so that its easy to see where the source for artifacts come
from, and because some maven plugins that work on sets of
modules make that assumption (like site plugin for example)
when running.
This is a best practice with Maven... and I don't recommend
moving away from that.
Before we already had things like console-jetty making a jar
named webconsole-jetty-* and others too which only make it more
difficult to tell where these things come from.
--jason
On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote:
I'm assuming everything is not geronimo- ... that might be
from the department of redundancy department.
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
