| The directory should match because:
* it makes it easier to find out which module produces which artifact * plugins that operate on hierarchies of modules make use of the parent directory name when generating output. if they don't match, then you end up needing to configure each module, which is added elements in the pom to maintain
If you really want this, this convince the maven team that they need to add additional support for a modules directory name in addition to its artifactId and then get them to update all plugins that traverse trees to use this information.
Or just keep them the same.
--jason
On Sep 5, 2006, at 12:57 PM, Sachin Patel wrote: Right, the pom can and should contain the geronimo-prefix but why is it necessary for the directory structure to match? With all the file length problems, I also this this is unnecessary and redundant.On Sep 5, 2006, at 3:36 PM, Guillaume Nodet wrote: The problem with not keeping the geronimo- prefix is that all jars will end up as
activemq-1.2.jar
activation-1.2.jar
It will be highly confusing.
The other solution is to break the directory name = artifactId rule, which is imho
a bad idea.
On 9/5/06, Matt Hogstrom <[EMAIL PROTECTED]> 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
>
>
>
--
Cheers,
Guillaume Nodet |
