On 19/03/2007, at 9:11 AM, Jason Dillon wrote:
We may want to take this time to fix a few other groupId thingys
too...
We should change the base server/trunk groupId to:
org.apache.geronimo.server
+1
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. Also, I believe that losing the "geronimo-"
prefixes contributes to the potential confusion.
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.
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:
https://svn.apache.org/repos/asf/geronimo/sandbox/g1.1-activemq4/
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:
#!/bin/sh
for path
do
pushd $path
mvn -o clean install
cp target/*.car ../../assemblies/geronimo-jetty6-jee5/target/
geronimo-jetty6-jee5-2.0-SNAPSHOT/repository/org/apache/geronimo/
configs/$path/*/*/
pushd ../../assemblies/geronimo-jetty6-jee5/target/geronimo-jetty6-
jee5-2.0-SNAPSHOT/repository/org/apache/geronimo/configs/$path/*/*/
jar -xf *.car
rm *.car
popd
popd
done
and I do something like:
./buildConfigs.sh jsr88-ear-configurer/ jsr88-rar-configurer/ jsr88-
war-configurer/ jsr88-jar-configurer/
I have a similar script in modules.
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?
Thanks,
Gianny
And, well.. if we keep along the same idea of structure reform, I
think we should probably start to think about dropping those
"geronimo-" prefixes that we have everywhere. I don't believe they
are useful, and only eat up space in the filename length. The
groupId should be sufficient to indicate these are Geronimo
artifacts, we don't need to remind people by adding that to the
artifact name too.
Some of this might be more disruptive than we can handle for right
now, especially while trying to get 2.0 out ASAP. I was hoping to
delay most of the major reorganization surgery until 2.1. But I
think a few of the groupId-based changes can be done for 2.0
soonish if we want.
For the larger moving stuff around... I am going to use svk2 to
setup a branch in the sandbox, pulling in new changes from trunk to
keep it up to date. From what I've been told svk2 handles merges
from source into target branches when the target branch has stuff
moved around... and I want to make sure that works. If it does...
well, then the whole restructuring will be trivial, we can keep
working on trunk asis then once the new structure is happy, we can
just switch over with very little merge overhead.
--jason
On Mar 18, 2007, at 1:23 PM, Davanum Srinivas wrote:
+1 to change. either one is ok.
-- dims
On 3/18/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
The maven plugins should be changed to
org.apache.geronimo.mavenplugins IMO, been on my list... just never
happened.
--jason
On Mar 18, 2007, at 8:52 AM, David Jencks wrote:
> It looks to me as if we are well on our way to use the groupId of
> org.apache.geronimo.plugins for both maven plugins and geronimo
> plugins. This might not be the wisest thing we ever did.
>
> What if we changed the maven plugins to use
> org.apache.geronimo.maven? Aside from massive backwards
> compatibility problems :-) this seems to me as if it might be the
> most appropriate naming change.
>
> thanks
> david jencks
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
Developers