You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/03/18 16:52:54 UTC
What is a plugin? geronimo or maven?
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
Re: What is a plugin? geronimo or maven?
Posted by Donald Woods <dr...@yahoo.com>.
Sounds good to me and 2.0 is a great time for it.
-Donald
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
>
>
>
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 6:00 AM, David Jencks 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 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
Folks, don't get a head of yourselves... there are a few different
issues here.
One of them is the groupId for that we have now with the structure we
have now. I believe that we should change the base groupId to
org.apache.geroniom.server to match to svn module. This can be done
now, or soon, and should probably be done at the same time when the
plugins groupId is changed.
Everything else is related to large scale restructuring of the
project, the above has nothing to do with restructuring. I have sent
email about this before, though we've never come to any conclusions
about how to resolve it. And... right now I don't think we need to
come to any conclusions, as I don't think we are ready to start on
this work yet.
> 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.
Sure, we need to solve this problem. I'm not sure what the best
solution is, though for the g1.1-amq4 stuff I simply suffixed the car
modules with "-config":
https://svn.apache.org/repos/asf/geronimo/sandbox/g1.1-activemq4/
I hope we can eventually get the server/trunk tree organized so that
features, like amq, can be organized into directories like this one,
where all (or most) of the modules are all peers like this.
--jason
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 2:57 PM, Jason Dillon wrote:
> On Mar 20, 2007, at 7:39 AM, Prasad Kashyap wrote:
>> On 3/20/07, David Jencks <da...@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.
>
> WAIT! We most certainly are not going to be dumping all artifacts
> into one groupId... so lets just stop that talk here... that does
> not make sence, will not happen.
In retrospect I should have rephrased this. I just got a bit
frustrated... and I apologize.
We certainly need to deal with the huge number of modules we have and
how they represented in the src tree and into the repo. I don't
think we can fix that just yet, as the change to make that happen is
larger than simply changing the groupIds.
--jason
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 7:39 AM, Prasad Kashyap wrote:
> On 3/20/07, David Jencks <da...@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.
WAIT! We most certainly are not going to be dumping all artifacts
into one groupId... so lets just stop that talk here... that does not
make sence, will not happen.
> Removing the geronimo- qualifier in front of the modules makes it
> even more confusing.
This is what I just don't get... how is this confusing? We all know
these are artifacts from org.apache.geronimo.* based on the
groupId... why then do we need to prefix the artifact with more? For
the most part these artifacts all live in a repo, so the groupId is
clear. A few live in lib/* though there aren't any name conflicts
there... and even if there were its easy enough to get the assembly
plugin to make them use specific names if needed.
> Now, if you want to restructure everything based on features, that is
> a different gameplan all together. We can discuss that.
Yes, that is ultimately the point... but somehow this thread has
gotten way off track. This thread was about the groupId of the maven
plugins... and about the base groupId of the server and if/how it
should be changed soon. Restructuring is not anything that will
happen soon, though folks should start to think about it more...
cause it is on the horizon.
--jason
Re: What is a plugin? geronimo or maven?
Posted by Prasad Kashyap <go...@gmail.com>.
On 3/20/07, David Jencks <da...@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
> >>
> >>
> >>
> >>
> >
>
>
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 6:53 AM, Anita Kulshreshtha wrote:
>> I'm sure we don't want all 100K artifacts we produce all under o.a.g
>>
>> or o.a.g.server
>
> I do not see why testsupport/* should clutter the directory that
> will contain modules and configs. We could have testsupport/* as:
> o.a.g.testsupport or o.a.g.server.testsupport.
Sure, we could use separate groupIds for every set of modules... just
a matter of making that choice and being consistent with it. I'm
just worried about the stupid long pathname, as we add new groupIds.
I personally like the groupIds to be different for groups of modules
(at least for the first level grouping). This gives them their own
namespace, and allows the repo structure to closer resemble the src
tree's structure.
>> the artifact ends up in modules or configs, and whether it starts
>> with "geronimo-" or ends with .car.
>
> The "geronimo-" part is helpful. Since .car is part of artifact
> name and not the artifactId, it is not helpful (see below) in
> identifying a car in the directory containing modules and configs.
>
> Thanks
> Anita
>
> current o/a/g/configs directory:
> activemq
> activemq-broker
> axis
> axis-deployer
> axis2
> axis2-deployer
> ca-helper-jetty
I would rather suffix the car's with something, rather than prefix
all non-cars with "geronimo-".
--jason
Re: What is a plugin? geronimo or maven?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- David Jencks <da...@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 do not see why testsupport/* should clutter the directory that
will contain modules and configs. We could have testsupport/* as:
o.a.g.testsupport or o.a.g.server.testsupport.
>
> 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.
The "geronimo-" part is helpful. Since .car is part of artifact
name and not the artifactId, it is not helpful (see below) in
identifying a car in the directory containing modules and configs.
Thanks
Anita
current o/a/g/configs directory:
activemq
activemq-broker
axis
axis-deployer
axis2
axis2-deployer
ca-helper-jetty
................
>
> 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:
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
Re: What is a plugin? geronimo or maven?
Posted by David Jencks <da...@yahoo.com>.
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 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
>>
>>
>>
>>
>
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 20, 2007, at 5:39 AM, Gianny Damour wrote:
>>> 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.
I don't believe that folks who are used to m2 repos are going to get
confused... this is how m2 works. I would rather have each set of
related modules use their own groupId, like for AMQ
org.apache.geronimo.activemq, but I fear if we start doing that then
we are going to run our selves into the ground with long path name
problems :-( Or maybe we should rebel and go back to using geronimo
as the root groupId... hrm... that would ruffle some feathers :-P
>> 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 don't follow how organizing modules into related groups is going to
make it hard for folks to follow. "Where are all the activemq
modules? they are in the activemq/* directory.". IMO its more
cumbersome/difficult now for new folks to understand, since part of
things for a feature are in modules/* and part are in configs/* with
a whole lot of other stuff in between to confuse the heck out of
you. Not that it confused me... but if you are talking about getting
new folks up to speed, then having smaller groups of modules which
are *all* related makes *much* more sense than what we have now.
>> 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>?
M2 handles this via the <modules>... definitions in poms. You can
setup an arbitrary tree by configuring the poms list of its child
modules.
>> 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.
<sarcasm>
Magic mvn command? Are you serious? Has Disney taken over the Maven
project? Is Mickey Mouse going to hold my hand while I run the
magically mvn command?
</sarcasm>
But seriously, there is no _magic_ mvn command... and IMO trying to
create one will *only* complicate things more.
> 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.
Do you remember everyone bitching about the bootstrap command? And
the mess about getting it to work on win32 and unix... and how folks
still wanted to use mvn...
* * *
modules/*, configs/*, applications/* and probably even assemblies/*
to some degree... are relics of the m1 build. m2 is a different
beast which has more features for organization of a multi-module
build. To best suite our build needs and to support our growing
project (which the codebase seems to keep getting larger) we really
need to reorganize the structure.
--jason
Re: What is a plugin? geronimo or maven?
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
>
>
>
>
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
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:
>>
>> 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.
> 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.
--jason
Re: What is a plugin? geronimo or maven?
Posted by Gianny Damour <gi...@optusnet.com.au>.
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 <ja...@planet57.com> 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
>
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
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
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
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/*".
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.
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 <ja...@planet57.com> 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
Re: What is a plugin? geronimo or maven?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to change. either one is ok.
-- dims
On 3/18/07, Jason Dillon <ja...@planet57.com> 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
Re: What is a plugin? geronimo or maven?
Posted by Jason Dillon <ja...@planet57.com>.
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
>
Re: What is a plugin? geronimo or maven?
Posted by Joe Bohn <jo...@earthlink.net>.
I agree.
Joe
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
>
>
Re: What is a plugin? geronimo or maven?
Posted by Gianny Damour <gi...@optusnet.com.au>.
+1
Thanks,
Gianny
On 19/03/2007, at 2: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
>
Re: What is a plugin? geronimo or maven?
Posted by Paul McMahan <pa...@gmail.com>.
This has always been confusing to me too. I like your suggestion. +1
Best wishes,
Paul
On 3/18/07, David Jencks <da...@yahoo.com> 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
>
>
Re: What is a plugin? geronimo or maven?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- David Jencks <da...@yahoo.com> 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?
I like o.a.g.mavenplugins suggested by Jason D.
Aside from massive backwards
> compatibility problems :-)
The sooner we fix the, the better.
Thanks
Anita
this seems to me as if it might be the
> most appropriate naming change.
>
> thanks
> david jencks
>
>
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265