Please help me try to understand this - Will our jars will be taken/seen/used outside the Geronimo context ? If they are, then I agree that geronimo-activation-1.2.jar is more meaningful than a simple activation-1.2.jar. The latter also gives scope for name conflicts.
But if our jars are always seen in the Geronimo context, we already have the o.a.g groupId to fully qualify it as a Geronimo jar. The jars will always be in a maven repo under o.a.g groupID. Why then should we need to prepend the "geronimo-" to our artifacts. NOTE: I completely agree that our directory structure should match the artifactId. I am not suggesting that we deviate from the maven convention. I am just wondering why we can't can't drop the "geronimo-" qualifier in both the directory name and artifactID. Maybe I'm missing something and hope you'll help me see it. Jason, here's a big +1 to your proposal to restructuring the modules. I am not against that. But this would be a good time to do some renaming if we can while we can. Hence this thread apparently seems to have veered off the topic. But actually it hasn't. I hope. Cheers Prasad On 9/5/06, Guillaume Nodet <[EMAIL PROTECTED]> 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
