geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: What is a plugin? geronimo or maven?
Date Mon, 19 Mar 2007 19:15:17 GMT
On Mar 19, 2007, at 6:52 AM, Gianny Damour wrote:
>> And perhaps change the 'applications' groupId to simply 'apps'...  
>> anyways, we'd end up with ids like:
>>     testsupport/* 		org.apache.geronimo.server
>>     modules/* 			org.apache.geronimo.server
> To some extent, I would prefer to keep the "modules" part in the  
> groupId as it provides a better namespacing. For instance, from the  
> org/apache/geronimo directory of a m2 repo, it is easy to see the  
> grouping as configs, applications etc are not lost within a list of  
> other directories.

As we reorganize the tree the "modules/" directory will be going  
away.  This is an artifact of the layout setup to facilitate the m1  
build, this is not needed nor recommended in an m2 build.

So... I don't see why we would want to keep  
"org.apache.geronimo.server.modules" around... and IMO "modules" is  
even more confusing here, as in mvn tearms everything is a module,  
and in G terms the stuff from "configs/*" are what we call modules.

I think this groupId should just go away.

> Also, I believe that losing the "geronimo-" prefixes contributes to  
> the potential confusion.

How exactly?

>>     configs/* 			org.apache.geronimo.server.configs
>>     applications/* 		org.apache.geronimo.server.apps
>>     maven-plugins/*	org.apache.geronimo.server.mavenplugins
>>     assemblies/* 		org.apache.geronimo.server.assemblies
>>     testsuite/*			org.apache.geronimo.server.testsuite
>> If we want to use "org.apache.geronimo.server.maven" for our  
>> plugins, then I suggest we rename "maven-plugins/*" to "maven/*"  
>> to keep things consistent. And actually I would do the same for  
>> "applications/*", rename it to "apps/*".
> If modules/* have the groupId org.apache.geronimo.server, then I  
> assume that you also would like to drop the modules/ directory for  
> the same reason than above. It seems that this would be confusing  
> to new developers.

Yes, the point is to eventually drop the "modules/*".  I sent mail  
about this months ago, we are in line for a significant restructuring  
of the project tree to group related mvn modules to simplify the  
build as well as organize modules into smaller workable chunks.

>> I also think that we should still re-organize modules/* configs/*  
>> into groups based on the features they provide (like all activemq,  
>> jetty, tomcat, etc) and I would put the configuration modules in  
>> the same group dirs.  For an example of that peep at the structure  
>> of the g1.1-activemq4  stuff I just added:
>> This is how I would recommend we eventually get our modules  
>> organized... into directories which contain all of the modules  
>> (and config modules) for a particular integration.  This makes it  
>> much easier to work on a specific feature... can simply `cd  
>> <feature>; mvn` to build those modules.
> One of my main pain point is that a full build takes ~25 minutes on  
> my box, allegedly fast. Moving to this directory structure does  
> help. On top of that, it would be awesome to be able to patch a  
> geronimo installation assumed to be at a given location (may be  
> configured as a property in setting.xml)  after having build a  
> feature. For instance, this is a hack I use from configs/ to build  
> and install cars in the geronimo installation I am working against:

Ya, that is one of the main reasons to reorganize.  Now that our  
build tool supports this sort of grouping and can handle resolving  
dependencies on a set of modules in an arbitrary tree.  This would  
have been very difficult to setup/main w/m1... which is why  
everything was dumped into a relatively flat structure.   This  
structure is more of a burden to us now that anything else.  And it  
should be changed so simplify the build and to help speed up partial  

> I believe it would be simpler and quicker to implement the proposed  
> grouping approach via external build helpers targeted to day-to-day  
> Geronimo developers.
> What do you think?

I think if folks want to use a script to build specifics that is up  
to them.  I don't recommend nor want to see a ton of build scripts  
checked into svn though.  IMO most of these problems can be fixed by  
simply reorganizing the tree and issuing a mvn cmd.  But, right now  
you have to issue a ton of very specific mvn commands to build  
related components/configs/assemblies.

In my mind... the plan (for m2 conversion) has always been to get the  
build up and running with the current structure, then work on  
restructuring to make effective use of m2 to help organize related  
components.  This is still what I recommend, and still what I hope to  
accomplish, though I am hoping to be able to accomplish this w/o  
having any negative impact on work being done to support 2.0.


View raw message