On 3/20/07, David Jencks <[EMAIL PROTECTED]> wrote:
I don't think we've been specific enough about what goes where for
jason's proposal to make sense yet, as gianni points out.
I'm sure we don't want all 100K artifacts we produce all under o.a.g
or o.a.g.server
I mostly definitely agree. In the maven repo, dumping all the
artifacts in the o.a.g.server directory would be very confusing.
Removing the geronimo- qualifier in front of the modules makes it even
more confusing.
Now, if you want to restructure everything based on features, that is
a different gameplan all together. We can discuss that.
Cheers
Prasad
I was assuming that o.a.g.server would basically have the kernel and
system stuff in it and little else -- maybe some basic naming support.
then e.g. o.a.g.connector would have connector, transaction, jpa,
connector-builder, persistence builder in it with the appropriate
configs as well
etc.
That way no group would be too large to understand at once. However
I think it might still be good to have some easy way to distinguish
the code subprojects from the car/module subprojects and I'm not sure
how to do that well yet. Right now there are 2 indications: whether
the artifact ends up in modules or configs, and whether it starts
with "geronimo-" or ends with .car.
thanks
david jencks
On Mar 20, 2007, at 8:39 AM, Gianny Damour wrote:
> On 20/03/2007, at 6:15 AM, Jason Dillon wrote:
>
>> 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?
> Let's illustrate:
>
> When we loose the modules part and keep the geronimo- prefix in the
> artifactId, a maven repo looks like this from the dir org/apache/
> geronimo/server:
> geronimo-activation
> geronimo-activemq-gbean
> geronimo-activemq-gbean-management
> <more geronimo- stuff>
> apps
> <more geronimo- stuff>
> assemblies
> <more geronimo- stuff>
> configs
> <more geronimo- stuff and you get the idea>
>
> Intuitively, I classify the folders starting with geronimo- into
> the same category and apps, assemblies et cetera stand out.
>
>
> Now, we also loose the geronimo- prefix and we have:
> activation
> activemq-gbean
> activemq-gbean-management
> <more stuff>
> apps
> <more stuff>
> assemblies
> <more stuff>
> configs
> <more stuff and you get the idea>
>
> This is confusing as apps, assemblies et cetera are lost within a
> list of other directories.
>
>
>>
>>
>>>> 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 know as I read it :). The point I am trying to make is: if
> modules/ is dropped, then new developers will have a hard time to
> understand the folder organization for reasons very similar to the
> above maven repo example.
>
>>
>>
>>>> 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:
>>
>> 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 builds.
> How does m2 handle the resolution of dependencies on an arbitrary
> tree? Is it as simple as: mvn <build these modules:please also
> build afferent dependencies>?
>
>>
>>
>>> 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.
> I think the same result can be delivered w/o any reorganizing with
> the magic mvn <build these modules:please also build afferent
> dependencies> command.
>
> E.g., I am in the server/trunk folder and do:
> mvn <magic command like partial-build> modules/jetty6
>
> mvn does a first pass to load the dependency graph for the overall
> tree; identify the afferent artifacts of modules/jetty6; and build
> modules/jetty6 and all of its afferent artifacts.
>
> It seems to me that a single script can do all the above w/o too
> much maven magic required. Obviously, everything happens outside of
> maven; yet it is simple to implement and more people can maintain
> and contribute.
>
> Thanks,
> Gianny
>
>>
>> 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.
>>
>> --jason
>>
>>
>>
>>
>
