You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason Dillon <ja...@planet57.com> on 2007/07/28 14:56:43 UTC
Importing poms, as well as extending them
Folks, I think this may have come up before, though I've not gone
digging in the jira or mailing list trenches for it...
I would be *really, really useful* if a pom could include other poms
into its effective pom *in addition to* the parent pom. The parent
pom and tree structure is very useful for defining projects and
scoped configuration muck for a single project, but when wanting to
share more pom elements with many projects, the inheritance model
breaks down significantly and ends up causing projects to duplicate
elements to control common build scenarios, which then causes more
maintenance... and in the end ultimately ends up in a rather big
mess :-(
I would really like to define a simple pom module, that defines some
common pom elements, maybe in a profile, maybe not. And then
configure my projects root pom (er the top-level pom that is) to
*include* the pom modules to get that poms elements overlaid into the
current effective pom. In the same way that works for the parent
really. Maybe first apply includes/imports (whatever you call them)
then parent, and then local overrides take precedence or something
like that.
Of course reference the poms to be included in the same way that the
parent is defined, yada, yada, yada.
IMO, this would be a *HUGE* benefit to the entire Maven community, as
then at this point folks can start to develop and share common build
configurations and let projects consume them easily.
It doesn't seem like rocket science... though I've not dug into the
depths of the plexus, modelo and other bits that made the pom
inheritance bits work.
Just for clarification, I'm not for tossing out the parent/child
bits, those are also important, but I think we need a kinda mixin for
pom configuration too.
Any thoughts?
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by ja...@gmail.com.
Okay... So let's write a spec :-p
--jason
-----Original Message-----
From: Jason van Zyl <ja...@maven.org>
Date: Sat, 28 Jul 2007 18:28:31
To:"Maven Developers List" <de...@maven.apache.org>
Subject: Re: Importing poms, as well as extending them
On 28 Jul 07, at 5:41 PM 28 Jul 07, Jason Dillon wrote:
>
> Heh, ya, no kidding. At this point I'm just trying to start a
> dialog with the community to get feedback.... on the concept,
> potential impacts, potential roadbumps, as well as maybe a hint or
> two of like "if you wanted to try, maybe you could look at X.class
> and see how parent merging goes, blah, blah, blah" ;-)
>
The key that's missing is no spec on inheritance/aggregation of each
element given the influence of profiles, settings and interpolation.
Once that was sorted out then importing a chunk of into a given POM
should not change the spec'd behaviour. But implementing that
mechanism without this spec would only cause more grief IMO.
> Cheers,
>
> --jason
>
>
>
>>> I would really like to define a simple pom module, that defines
>>> some common pom elements, maybe in a profile, maybe not. And
>>> then configure my projects root pom (er the top-level pom that
>>> is) to *include* the pom modules to get that poms elements
>>> overlaid into the current effective pom. In the same way that
>>> works for the parent really. Maybe first apply includes/imports
>>> (whatever you call them) then parent, and then local overrides
>>> take precedence or something like that.
>>>
>>> Of course reference the poms to be included in the same way that
>>> the parent is defined, yada, yada, yada.
>>>
>>> IMO, this would be a *HUGE* benefit to the entire Maven
>>> community, as then at this point folks can start to develop and
>>> share common build configurations and let projects consume them
>>> easily.
>>>
>>> It doesn't seem like rocket science... though I've not dug into
>>> the depths of the plexus, modelo and other bits that made the pom
>>> inheritance bits work.
>>>
>>> Just for clarification, I'm not for tossing out the parent/child
>>> bits, those are also important, but I think we need a kinda mixin
>>> for pom configuration too.
>>>
>>> Any thoughts?
>>>
>>> --jason
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Jul 07, at 5:41 PM 28 Jul 07, Jason Dillon wrote:
>
> Heh, ya, no kidding. At this point I'm just trying to start a
> dialog with the community to get feedback.... on the concept,
> potential impacts, potential roadbumps, as well as maybe a hint or
> two of like "if you wanted to try, maybe you could look at X.class
> and see how parent merging goes, blah, blah, blah" ;-)
>
The key that's missing is no spec on inheritance/aggregation of each
element given the influence of profiles, settings and interpolation.
Once that was sorted out then importing a chunk of into a given POM
should not change the spec'd behaviour. But implementing that
mechanism without this spec would only cause more grief IMO.
> Cheers,
>
> --jason
>
>
>
>>> I would really like to define a simple pom module, that defines
>>> some common pom elements, maybe in a profile, maybe not. And
>>> then configure my projects root pom (er the top-level pom that
>>> is) to *include* the pom modules to get that poms elements
>>> overlaid into the current effective pom. In the same way that
>>> works for the parent really. Maybe first apply includes/imports
>>> (whatever you call them) then parent, and then local overrides
>>> take precedence or something like that.
>>>
>>> Of course reference the poms to be included in the same way that
>>> the parent is defined, yada, yada, yada.
>>>
>>> IMO, this would be a *HUGE* benefit to the entire Maven
>>> community, as then at this point folks can start to develop and
>>> share common build configurations and let projects consume them
>>> easily.
>>>
>>> It doesn't seem like rocket science... though I've not dug into
>>> the depths of the plexus, modelo and other bits that made the pom
>>> inheritance bits work.
>>>
>>> Just for clarification, I'm not for tossing out the parent/child
>>> bits, those are also important, but I think we need a kinda mixin
>>> for pom configuration too.
>>>
>>> Any thoughts?
>>>
>>> --jason
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jochen Kuhnle <jo...@kuhnle.net>.
On 2007-08-02 12:28:04 +0200, Jason Dillon <ja...@planet57.com> said:
> On Aug 2, 2007, at 2:57 AM, Jochen Kuhnle wrote:
>>
>> Couldn't it just be multiple parents, like
>>
>> <parents>
>> <parent>
>> ...
>> </parent>
>> <parent>
>> ...
>> </parent>
>> </parents>
>> This would only be a small extension to the POM format and POM
>> assembly code, and would not introduce new concepts.
>
> Not really, since you need to know which is your "real" parent when
> rendering site details, and some common bits of pom.xml might not
> really be suitable for calling your parent either.
The "real" parent would be the last one mentioned in the pom. Parents
could be used in order of their appearance. Currently, if a pom M has a
parent P1, the effective POM is built by combining P1 and M, with M
taking precedence over P1. If M had multiple parents (P1, P2, P3) the
effective pom should be created by combining P1, P2, P3 and M (in this
order). This way, any value of the effective POM comes from M, P3, P2
or P1 (in this order), whichever first specifies it. I think that
assinging an order to the parents is ok, because with imports, you also
have to.
>
>
>>> I know that the precedence thing may be problematic... so I suggest a
>>> simple solution of exposing an additional element in the <import>
>>> bits, which are optional to control how that pom is merged in. Of
>>> course we come up with some reasonable default, say, always overlay
>>> that stuff last after parent is merged in. But maybe the user might
>>> want the imported pom to take precedence, or for the import to take
>>> precedence over the parent, but not other profiles, etc.
>>
>> How about a general mechanism working for all kinds of "combination"
>> (parents, profiles, *management sections). Right now, you can use the
>> "combine.*" attributes, which could be extended to allow more
>> fine-grained combination control (e.g. removal of parts of a list).
>> Precedence then can stay as it is now, and the user can explicitly
>> specify what parts of the pom should be combined in which way.
>
> Um, you kinda lost me with the "right now" in with "combine.*"...
My mistake, I thought Maven used Xpp3Dom.mergeIntoXpp3Dom from
plexus-utils not only for plugin configurations, but for the pom
itself, too. I found ModelInheritanceAssembler now... With
Xpp3Dom.mergeIntoXpp3Dom, you can use attributes to control the
combination of two elements. E.g. combine.self="override" combines by
using the element with higher precedence, combine.self="merge" combines
by merging both elements' attributes and children.
With this at pom level, it would be possible to specify if e.g. a list
of repositories inherited from the parents should be appended to or
completely overwritten. In addition, it might be useful to have the
ability to remove a single element from a list of inherited elements,
e.g. removing a repository, a plugin execution or a dependency
inherited from a parent.
Regards,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 2, 2007, at 2:57 AM, Jochen Kuhnle wrote:
>> ----8<----
>> <project>
>> <modelVersion>...
>> <parent>
>> ...
>> </parent>
>> <imports>
>> <import>
>> <groupId>foo.bar</groupId>
>> <artifactId>some-shared-pom-muck</artifactId>
>> <version>1.0</version>
>> </import>
>> </imports>
>> </project>
>> ---->8----
>
> Couldn't it just be multiple parents, like
>
> <parents>
> <parent>
> ...
> </parent>
> <parent>
> ...
> </parent>
> </parents>
> This would only be a small extension to the POM format and POM
> assembly code, and would not introduce new concepts.
Not really, since you need to know which is your "real" parent when
rendering site details, and some common bits of pom.xml might not
really be suitable for calling your parent either.
>> I know that the precedence thing may be problematic... so I
>> suggest a simple solution of exposing an additional element in
>> the <import> bits, which are optional to control how that pom is
>> merged in. Of course we come up with some reasonable default,
>> say, always overlay that stuff last after parent is merged in.
>> But maybe the user might want the imported pom to take
>> precedence, or for the import to take precedence over the parent,
>> but not other profiles, etc.
>
> How about a general mechanism working for all kinds of
> "combination" (parents, profiles, *management sections). Right now,
> you can use the "combine.*" attributes, which could be extended to
> allow more fine-grained combination control (e.g. removal of parts
> of a list). Precedence then can stay as it is now, and the user can
> explicitly specify what parts of the pom should be combined in
> which way.
Um, you kinda lost me with the "right now" in with "combine.*"...
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jochen Kuhnle <jo...@kuhnle.net>.
On 2007-07-28 23:41:18 +0200, Jason Dillon <ja...@planet57.com> said:
> On Jul 28, 2007, at 8:52 AM, Jason van Zyl wrote:
>> On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
>>> Folks, I think this may have come up before, though I've not gone
>>> digging in the jira or mailing list trenches for it...
>>>
>>> I would be *really, really useful* if a pom could include other poms
>>> into its effective pom *in addition to* the parent pom. The parent
>>> pom and tree structure is very useful for defining projects and scoped
>>> configuration muck for a single project, but when wanting to share
>>> more pom elements with many projects, the inheritance model breaks
>>> down significantly and ends up causing projects to duplicate elements
>>> to control common build scenarios, which then causes more
>>> maintenance... and in the end ultimately ends up in a rather big mess
>>> :-(
>>>
>>
>> Composition versus inheritance. The same problem has arisen with the POM.
>>
>> For something like a release profile, or release tool chain and import
>> or mixin approach would be far more convenient.
>
> Yes, this is really what I'm thinking of. A way to mixin a shared
> profile, or to configure a set of dependency and plugin versions which
> have been _blessed_, etc.
>
>
>> The problem is how and where to get the information to mixin. I think
>> it should come from the repository, so something like the release
>> profile becomes a mixin taken from a reliable source like the
>> repository. Otherwise being able to mixin anything potentially leads
>> to build portability problems. In order to do this we also have a not
>> to trivial task of figuring out what takes precedence, merging versus
>> aggregation ... and we really don't have solid rules for much of this
>> behavior at the moment.
>
> I'm definitely thinking that the bits to mixin come from the
> repository, and I'm even thinking they are just regular old poms...
> configured like:
>
> ----8<----
> <project>
> <modelVersion>...
> <parent>
> ...
> </parent>
>
> <imports>
> <import>
> <groupId>foo.bar</groupId>
> <artifactId>some-shared-pom-muck</artifactId>
> <version>1.0</version>
> </import>
> </imports>
> </project>
> ---->8----
Couldn't it just be multiple parents, like
<parents>
<parent>
...
</parent>
<parent>
...
</parent>
</parents>
This would only be a small extension to the POM format and POM assembly
code, and would not introduce new concepts.
>
> I know that the precedence thing may be problematic... so I suggest a
> simple solution of exposing an additional element in the <import>
> bits, which are optional to control how that pom is merged in. Of
> course we come up with some reasonable default, say, always overlay
> that stuff last after parent is merged in. But maybe the user might
> want the imported pom to take precedence, or for the import to take
> precedence over the parent, but not other profiles, etc.
How about a general mechanism working for all kinds of "combination"
(parents, profiles, *management sections). Right now, you can use the
"combine.*" attributes, which could be extended to allow more
fine-grained combination control (e.g. removal of parts of a list).
Precedence then can stay as it is now, and the user can explicitly
specify what parts of the pom should be combined in which way.
Regards,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 28, 2007, at 8:52 AM, Jason van Zyl wrote:
> On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
>> Folks, I think this may have come up before, though I've not gone
>> digging in the jira or mailing list trenches for it...
>>
>> I would be *really, really useful* if a pom could include other
>> poms into its effective pom *in addition to* the parent pom. The
>> parent pom and tree structure is very useful for defining projects
>> and scoped configuration muck for a single project, but when
>> wanting to share more pom elements with many projects, the
>> inheritance model breaks down significantly and ends up causing
>> projects to duplicate elements to control common build scenarios,
>> which then causes more maintenance... and in the end ultimately
>> ends up in a rather big mess :-(
>>
>
> Composition versus inheritance. The same problem has arisen with
> the POM.
>
> For something like a release profile, or release tool chain and
> import or mixin approach would be far more convenient.
Yes, this is really what I'm thinking of. A way to mixin a shared
profile, or to configure a set of dependency and plugin versions
which have been _blessed_, etc.
> The problem is how and where to get the information to mixin. I
> think it should come from the repository, so something like the
> release profile becomes a mixin taken from a reliable source like
> the repository. Otherwise being able to mixin anything potentially
> leads to build portability problems. In order to do this we also
> have a not to trivial task of figuring out what takes precedence,
> merging versus aggregation ... and we really don't have solid rules
> for much of this behavior at the moment.
I'm definitely thinking that the bits to mixin come from the
repository, and I'm even thinking they are just regular old poms...
configured like:
----8<----
<project>
<modelVersion>...
<parent>
...
</parent>
<imports>
<import>
<groupId>foo.bar</groupId>
<artifactId>some-shared-pom-muck</artifactId>
<version>1.0</version>
</import>
</imports>
</project>
---->8----
I know that the precedence thing may be problematic... so I suggest a
simple solution of exposing an additional element in the <import>
bits, which are optional to control how that pom is merged in. Of
course we come up with some reasonable default, say, always overlay
that stuff last after parent is merged in. But maybe the user might
want the imported pom to take precedence, or for the import to take
precedence over the parent, but not other profiles, etc.
I dunno, just kinda thinking out loud...
> So general mixins I agree would be highly useful, but the devil is
> in the details. It would be quite easy to pull a chunk of XML, we
> could either do it at the modello level or the project builder
> level, but what to ultimately do with the information is the problem.
I agree... but I really think that this is a critical missing part of
Maven to allow build configurations to be shared and re-used. Right
now the best we can do is chuck stuff into a common parent and then
get projects to extend from that parent to share the common
configuration (which is what the genesis project-config module is for
in the geronimo project). but folks rather tend to not like that, as
its got some ugly wrinkles, so more often folks just copy-paste which
ends up with more bits to go flip when that shared configuration
changes, which it does all the time.
Along the same lines, I was thinking that it would be a really good
idea, once this works, to setup some common mixin pom for a basic
project, a maven plugin, a groovy project, etc... that basically
configure the latest supported and working version details for
plugins that might be used for that type of project, as well as a
recommended release profile and probably some integration testing
profile. So that folks can easily quickly start creating complex and
powerful builds with out having to know about all that xml.
I think for each mvn release we'd roll out a new set of these project
genre poms with updated versions, and then make point releases over
time until the next mvn release when supporting plugins are released
and known to be compatible with that version of mvn and the other
plugins and bits configured.
It is possible to do something like this now, but its a PITA due to
the parent/child bits. Like we could create these, maybe have them
extend the ASF poms, but no everyone who wants to use it wants that
ASF stuff in there. If they are root poms, then folks will have to
add that ASF stuff to each of their projects. I think you know what
I'm talking about. So, the mixin pom bits are really important here,
as well as other places, to allow build configuration to trully shared.
> The rest of the system is a little fragile for this to be turned on
> IMO as useful as it would be.
How can we make it less fragile? I've really been wanting this
functionality for a few years now... I keep making parent poms to put
in config, and I want to keep re-using that config, but it becomes
problematic and messy to manage some of the duplicate information,
and well, projects just tend to get rust slowly overtime. :-(
> If you want to start looking at it that would be cool, but I don't
> think it's a weekend project. The impact of turning on a feature
> like that is widespread.
Heh, ya, no kidding. At this point I'm just trying to start a dialog
with the community to get feedback.... on the concept, potential
impacts, potential roadbumps, as well as maybe a hint or two of like
"if you wanted to try, maybe you could look at X.class and see how
parent merging goes, blah, blah, blah" ;-)
Cheers,
--jason
>> I would really like to define a simple pom module, that defines
>> some common pom elements, maybe in a profile, maybe not. And then
>> configure my projects root pom (er the top-level pom that is) to
>> *include* the pom modules to get that poms elements overlaid into
>> the current effective pom. In the same way that works for the
>> parent really. Maybe first apply includes/imports (whatever you
>> call them) then parent, and then local overrides take precedence
>> or something like that.
>>
>> Of course reference the poms to be included in the same way that
>> the parent is defined, yada, yada, yada.
>>
>> IMO, this would be a *HUGE* benefit to the entire Maven community,
>> as then at this point folks can start to develop and share common
>> build configurations and let projects consume them easily.
>>
>> It doesn't seem like rocket science... though I've not dug into
>> the depths of the plexus, modelo and other bits that made the pom
>> inheritance bits work.
>>
>> Just for clarification, I'm not for tossing out the parent/child
>> bits, those are also important, but I think we need a kinda mixin
>> for pom configuration too.
>>
>> Any thoughts?
>>
>> --jason
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
> Folks, I think this may have come up before, though I've not gone
> digging in the jira or mailing list trenches for it...
>
> I would be *really, really useful* if a pom could include other
> poms into its effective pom *in addition to* the parent pom. The
> parent pom and tree structure is very useful for defining projects
> and scoped configuration muck for a single project, but when
> wanting to share more pom elements with many projects, the
> inheritance model breaks down significantly and ends up causing
> projects to duplicate elements to control common build scenarios,
> which then causes more maintenance... and in the end ultimately
> ends up in a rather big mess :-(
>
Composition versus inheritance. The same problem has arisen with the
POM.
For something like a release profile, or release tool chain and
import or mixin approach would be far more convenient.
The problem is how and where to get the information to mixin. I think
it should come from the repository, so something like the release
profile becomes a mixin taken from a reliable source like the
repository. Otherwise being able to mixin anything potentially leads
to build portability problems. In order to do this we also have a not
to trivial task of figuring out what takes precedence, merging versus
aggregation ... and we really don't have solid rules for much of this
behavior at the moment.
So general mixins I agree would be highly useful, but the devil is in
the details. It would be quite easy to pull a chunk of XML, we could
either do it at the modello level or the project builder level, but
what to ultimately do with the information is the problem.
The rest of the system is a little fragile for this to be turned on
IMO as useful as it would be.
If you want to start looking at it that would be cool, but I don't
think it's a weekend project. The impact of turning on a feature like
that is widespread.
> I would really like to define a simple pom module, that defines
> some common pom elements, maybe in a profile, maybe not. And then
> configure my projects root pom (er the top-level pom that is) to
> *include* the pom modules to get that poms elements overlaid into
> the current effective pom. In the same way that works for the
> parent really. Maybe first apply includes/imports (whatever you
> call them) then parent, and then local overrides take precedence or
> something like that.
>
> Of course reference the poms to be included in the same way that
> the parent is defined, yada, yada, yada.
>
> IMO, this would be a *HUGE* benefit to the entire Maven community,
> as then at this point folks can start to develop and share common
> build configurations and let projects consume them easily.
>
> It doesn't seem like rocket science... though I've not dug into the
> depths of the plexus, modelo and other bits that made the pom
> inheritance bits work.
>
> Just for clarification, I'm not for tossing out the parent/child
> bits, those are also important, but I think we need a kinda mixin
> for pom configuration too.
>
> Any thoughts?
>
> --jason
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org