Matt, think of the maven directory layout like ruby on rails.
Following the convention makes your life easy.
-dain
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
>>>>