Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: domain of goyathlay.geronimo@gmail.com
 designates 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Fl/3+nS5sUv4F4uYtiKH/2shGThY1PJFKL5Mv+JT4Z123KkGu87tuHh6HX3km+trjK5KuJEfltL9+sMKO9WDtU+rl1ZegjAsvf6ZvhnNM974Xg6zekVCNRlTd0AMLsFB7XtVXFTBwFMWTHUR4vrwOaOn7wpouiJ6DIO/ryrTmGk=
Message-ID: <c278ac970703200739o6c1f81e9pe07b7be8d5322020@mail.gmail.com>
Date: Tue, 20 Mar 2007 10:39:28 -0400
From: "Prasad Kashyap" <goyathlay.geronimo@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: What is a plugin? geronimo or maven?
In-Reply-To: <5B81CAB2-120B-4D73-A4AB-C289C35EA726@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46184582-02C8-4FCC-A592-DE82D405A678@yahoo.com>
	 <F04C7738-95A1-4B6E-B29E-3EC4F3E46AFD@planet57.com>
	 <19e0530f0703181323v68694cdfl1594e483315a1c82@mail.gmail.com>
	 <2121F5B5-7C84-40AA-AFE1-5F48986DC9E6@planet57.com>
	 <8348A210-3A04-431B-A346-4F73B60831A2@optusnet.com.au>
	 <E9A77F04-F9B2-4B70-9011-7D9382722DBE@planet57.com>
	 <40E3D6FF-4FAF-49B5-8E40-0832B12DC4A9@optusnet.com.au>
	 <5B81CAB2-120B-4D73-A4AB-C289C35EA726@yahoo.com>

On 3/20/07, David Jencks <david_jencks@yahoo.com> 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
> >>
> >>
> >>
> >>
> >
>
>