You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Dennis Lundberg <de...@apache.org> on 2007/08/27 20:30:37 UTC
Community review of the next commons-logging pom
Hi all
The poms for commons logging has taken some beating on this list over
the years. The reason for that has been the dependencies section.
Previous poms of commons-logging was created for Maven 1. These were
then converted into Maven 2 poms with various degree of success. In
particular the scope wasn't set properly.
We are now preparing the next release of commons-logging (version 1.1.1)
which will be built with Maven 2. That means that the pom that ends up
in the Maven 2 repository will be the same one that we have created.
To make sure that we have covered all bases this time we invite you, the
community, to help us get it right. The current pom.xml is available for
your viewing in our subversion repository:
https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
Please post any comments you have on the pom to this list, and I will
bring the over to the commons community.
--
Dennis Lundberg
Apache Commons committer and PMC member
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
I would like to extend a big "Thank you" to the Maven community for
helping us out with this review.
--
Dennis Lundberg
on behalf of the Apache Commons Logging team
Dennis Lundberg wrote:
> Hi all
>
> The poms for commons logging has taken some beating on this list over
> the years. The reason for that has been the dependencies section.
> Previous poms of commons-logging was created for Maven 1. These were
> then converted into Maven 2 poms with various degree of success. In
> particular the scope wasn't set properly.
>
> We are now preparing the next release of commons-logging (version 1.1.1)
> which will be built with Maven 2. That means that the pom that ends up
> in the Maven 2 repository will be the same one that we have created.
>
> To make sure that we have covered all bases this time we invite you, the
> community, to help us get it right. The current pom.xml is available for
> your viewing in our subversion repository:
>
>
> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>
>
> Please post any comments you have on the pom to this list, and I will
> bring the over to the commons community.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <mi...@ferritdev.co.nz>.
> Why? Only with dependencyManagement you're able to manage transitive
> versions.
In order to keep clean dependency graphs I have used standard OO principles to
encasulate functionality in this case I will use spring as an example.
Spring provided many artifacts. I have many projects that use different groups
of spring projects so I have pulled the spring dependencies out into two
compositions one that deals with contexts and the other persistence.
All my projects depend upon those compositions which means that all
aggregations end up with bottleneck in the dependency graph at the point
where the actual spring versions are resolved. Hence no conflict in the jars
that actually end up in aggregations. On other key thing is a careful use of
ranges to restrict which version of the composition is pulled in. For example
at the moment i have one for spring [2.0,2.1) and one for [2.1,2.2) its
impossible for an aggregation via two different trees to accidentally include
spring 2.0.6 and 2.1-beta for example as the maven dependency will complain
of an over contrained dependency. This evangenlism is usually accompanied by
a A2 page of dependency graph scribbles ;-)
> They are optional, so you do not depend on them transitively.
>
so in order to enable something thats optional i have to include those same
dependencies myself? Rather than depend upon an artifact that will resolve
only the dependencies I want and the correct graph for what I need?
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
"Optional dependencies are used when it's not really possible (for whatever
reason) to split a project up into sub-modules. The idea is that some of the
dependencies are only used for certain features in the project, and will not
be needed if that feature isn't used. Ideally, such a feature would be split
into a sub-module that depended on the core functionality project...this new
subproject would have only non-optional dependencies, since you'd need them
all if you decided to use the subproject's functionality."
> Commons logging has a different philosophy. But this is OT for this list.
If the difference in philosophy means more difficulty in managing dependency
graphs then its not OT for this list but very pertinent.
On Tuesday 28 August 2007 18:03, Jörg Schaible wrote:
> Hi Michael,
>
> Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
> > IMO the log4j, logkit, avalon dependencies all need to go... I as I
> > imagine most people do only use one logging implementation in the
> > deployed systems why introduce a dependency on several
> > implementations at the top level?
>
> They are optional, so you do not depend on them transitively.
>
> > check out http://www.slf4j.com for an appropriate break up of the
> > artifacts and use cases
>
> Commons logging has a different philosophy. But this is OT for this list.
>
> > I've generally stopped using dependencyManagement in favour of
> > dependency composition
>
> Why? Only with dependencyManagement you're able to manage transitive
> versions.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Development Lead
Ferrit Ltd
cell: 021.576.907
msn: gholam@xtra.co.nz
jabber: mccallum.michael@gmail.com
aim: gholamses
http://www.ferrit.co.nz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dan Tran <da...@gmail.com>.
agree with Michael here.
-D
On 8/27/07, Michael McCallum <gh...@apache.org> wrote:
> IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
> most people do only use one logging implementation in the deployed systems
> why introduce a dependency on several implementations at the top level?
>
> check out http://www.slf4j.com for an appropriate break up of the artifacts
> and use cases
>
> I've generally stopped using dependencyManagement in favour of dependency
> composition
>
> On Tuesday 28 August 2007 10:06, Stephane Nicoll wrote:
> > For the servlet-api dependency, provided scope is enough (provided is
> > not transitive).
> >
> > Thanks,
> > Stéphane
> >
> > On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> > > Hi all
> > >
> > > The poms for commons logging has taken some beating on this list over
> > > the years. The reason for that has been the dependencies section.
> > > Previous poms of commons-logging was created for Maven 1. These were
> > > then converted into Maven 2 poms with various degree of success. In
> > > particular the scope wasn't set properly.
> > >
> > > We are now preparing the next release of commons-logging (version 1.1.1)
> > > which will be built with Maven 2. That means that the pom that ends up
> > > in the Maven 2 repository will be the same one that we have created.
> > >
> > > To make sure that we have covered all bases this time we invite you, the
> > > community, to help us get it right. The current pom.xml is available for
> > > your viewing in our subversion repository:
> > >
> > >
> > > https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revisi
> > >on=568979&view=markup
> > >
> > > Please post any comments you have on the pom to this list, and I will
> > > bring the over to the commons community.
> > >
> > > --
> > > Dennis Lundberg
> > > Apache Commons committer and PMC member
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
but i want it managed across 75 artifacts in 11 groups with 9 aggregations...
using inheritance to manage a change in the version of spring for example is
way too time consuming and prone to error. Unless i specify all the deps in
the aggregation i can never be sure of what version of any library i actually
end up with
it might make more sense if you saw how i have the structure set up... the
most important part of the development environment for me is that i can check
out any maven artifact in isolation and work on it and release it...
On Wednesday 29 August 2007 02:06, Jörg Schaible wrote:
> Michael McCallum wrote on Tuesday, August 28, 2007 2:39 PM:
> >> OK. But this will not help you, if you include another artifact that
> >> depends transitively on Spring or Hibernate in different versions.
> >> And therefore we use a company or at least a master POM for a
> >> project with a dependencyManagement section. This way you can
> >> overwrite the versions of the transitive deps.
> >
> > incorrect. maven will resolve the dependencies from closest
> > to furtherest but
> > not tranverse transitions if there is a better match. So if I
> > hide all of the
> > transitions behind a composition in all cases
>
> That's the point. By using the compositions you have to update them or
> create new ones everytime you add a new dep. I simply add it to my
> dependencyManagement.
>
> > - which means i
> > have to exclude
> > deps from 3rd party libraries in some cases - then the spring
> > libraries are only resolved as transitions of composition and nothing
> > else... as you can
> > have on one instance of an artifact in the graph that gets
> > selected there is
> > on one set of transitions from the selected compositions... and voila
> > consistent dependencies
>
> Since the depMgmnt oiverwrites the version of the inherited deps: voila no
> inconsistent dep ;-)
>
> But you have your point. By using compositions you can combine them
> individually, while the depMgmnt approach is kind of "all or nothing" for a
> project.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Community review of the next commons-logging pom
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Michael McCallum wrote on Tuesday, August 28, 2007 2:39 PM:
>> OK. But this will not help you, if you include another artifact that
>> depends transitively on Spring or Hibernate in different versions.
>> And therefore we use a company or at least a master POM for a
>> project with a dependencyManagement section. This way you can
>> overwrite the versions of the transitive deps.
> incorrect. maven will resolve the dependencies from closest
> to furtherest but
> not tranverse transitions if there is a better match. So if I
> hide all of the
> transitions behind a composition in all cases
That's the point. By using the compositions you have to update them or create new ones everytime you add a new dep. I simply add it to my dependencyManagement.
> - which means i
> have to exclude
> deps from 3rd party libraries in some cases - then the spring
> libraries are only resolved as transitions of composition and nothing
> else... as you can
> have on one instance of an artifact in the graph that gets
> selected there is
> on one set of transitions from the selected compositions... and voila
> consistent dependencies
Since the depMgmnt oiverwrites the version of the inherited deps: voila no inconsistent dep ;-)
But you have your point. By using compositions you can combine them individually, while the depMgmnt approach is kind of "all or nothing" for a project.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
>
> OK. But this will not help you, if you include another artifact that
> depends transitively on Spring or Hibernate in different versions. And
> therefore we use a company or at least a master POM for a project with a
> dependencyManagement section. This way you can overwrite the versions of
> the transitive deps.
incorrect. maven will resolve the dependencies from closest to furtherest but
not tranverse transitions if there is a better match. So if I hide all of the
transitions behind a composition in all cases - which means i have to exclude
deps from 3rd party libraries in some cases - then the spring libraries are
only resolved as transitions of composition and nothing else... as you can
have on one instance of an artifact in the graph that gets selected there is
on one set of transitions from the selected compositions... and voila
consistent dependencies
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Community review of the next commons-logging pom
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Michael McCallum wrote on Tuesday, August 28, 2007 1:56 PM:
> http://en.wikipedia.org/wiki/Relation_composition
>
> group.id.composition.spring 2.0.6
> -> spring-beans 2.0.6
> -> spring-context 2.0.6
>
> group.id.composition.spring.persistence 2.0.6
> ->group.id.composition.spring 2.0.6
> -> hibernate 3.1.3
> -> spring-hibernate3
>
> group.id.artifact.a X
> -> group.id.composition.spring.persistence [2.0, 2.1)
>
> group.id.artifact.b Y
> -> group.id.composition.spring [2.0, 2.1)
>
> group.id.aggregation Z
> -> group.id.artifact.b Y
> -> group.id.artifact.a X
>
> when building aggregation - think war or ear - you get a graph with a
> common composition element when it resolves you only get one of those
> and the resultant transitions down the graph
OK. But this will not help you, if you include another artifact that depends transitively on Spring or Hibernate in different versions. And therefore we use a company or at least a master POM for a project with a dependencyManagement section. This way you can overwrite the versions of the transitive deps.
> I will concede the logging artifacts as OT but you may see me on
> commons later ;-)
You're welcome :D
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
http://en.wikipedia.org/wiki/Relation_composition
group.id.composition.spring 2.0.6
-> spring-beans 2.0.6
-> spring-context 2.0.6
group.id.composition.spring.persistence 2.0.6
->group.id.composition.spring 2.0.6
-> hibernate 3.1.3
-> spring-hibernate3
group.id.artifact.a X
-> group.id.composition.spring.persistence [2.0, 2.1)
group.id.artifact.b Y
-> group.id.composition.spring [2.0, 2.1)
group.id.aggregation Z
-> group.id.artifact.b Y
-> group.id.artifact.a X
when building aggregation - think war or ear - you get a graph with a common
composition element when it resolves you only get one of those and the
resultant transitions down the graph
I will concede the logging artifacts as OT but you may see me on commons
later ;-)
On Tuesday 28 August 2007 23:28, Jörg Schaible wrote:
> Michael McCallum wrote on Tuesday, August 28, 2007 1:15 PM:
> >> Why? Only with dependencyManagement you're able to manage transitive
> >> versions.
> >
> > In order to keep clean dependency graphs I have used standard
> > OO principles to
> > encasulate functionality in this case I will use spring as an example.
> >
> > Spring provided many artifacts. I have many projects that use
> > different groups of spring projects so I have pulled the spring
> > dependencies
> > out into two
> > compositions one that deals with contexts and the other persistence.
>
> [snip]
>
> You still did not explain, what "composition" means. It's no word used in
> standard Maven terminology. Your description does not make it clear what
> you *actually* have done.
>
> [snip]
>
> >> Commons logging has a different philosophy. But this is OT
> >
> > for this list.
> > If the difference in philosophy means more difficulty in
> > managing dependency
> > graphs then its not OT for this list but very pertinent.
>
> It is OT, since it is up to the Apache Commons community how they carve
> their artifacts. And splitting an artifact into 6 where 5 of them contain a
> single wrapper class is where philosophy starts. You may discuss this at
> Apache Commons.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
http://en.wikipedia.org/wiki/Object_composition is really just the software
equivalent of the first link i sent
> [snip]
>
> You still did not explain, what "composition" means. It's no word used in
> standard Maven terminology. Your description does not make it clear what
> you *actually* have done.
>
> [snip]
>
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Community review of the next commons-logging pom
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Michael McCallum wrote on Tuesday, August 28, 2007 1:15 PM:
>> Why? Only with dependencyManagement you're able to manage transitive
>> versions.
> In order to keep clean dependency graphs I have used standard
> OO principles to
> encasulate functionality in this case I will use spring as an example.
>
> Spring provided many artifacts. I have many projects that use
> different groups of spring projects so I have pulled the spring
> dependencies
> out into two
> compositions one that deals with contexts and the other persistence.
[snip]
You still did not explain, what "composition" means. It's no word used in standard Maven terminology. Your description does not make it clear what you *actually* have done.
[snip]
>> Commons logging has a different philosophy. But this is OT
> for this list.
> If the difference in philosophy means more difficulty in
> managing dependency
> graphs then its not OT for this list but very pertinent.
It is OT, since it is up to the Apache Commons community how they carve their artifacts. And splitting an artifact into 6 where 5 of them contain a single wrapper class is where philosophy starts. You may discuss this at Apache Commons.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
> Why? Only with dependencyManagement you're able to manage transitive
> versions.
In order to keep clean dependency graphs I have used standard OO principles to
encasulate functionality in this case I will use spring as an example.
Spring provided many artifacts. I have many projects that use different groups
of spring projects so I have pulled the spring dependencies out into two
compositions one that deals with contexts and the other persistence.
All my projects depend upon those compositions which means that all
aggregations end up with bottleneck in the dependency graph at the point
where the actual spring versions are resolved. Hence no conflict in the jars
that actually end up in aggregations. On other key thing is a careful use of
ranges to restrict which version of the composition is pulled in. For example
at the moment i have one for spring [2.0,2.1) and one for [2.1,2.2) its
impossible for an aggregation via two different trees to accidentally include
spring 2.0.6 and 2.1-beta for example as the maven dependency will complain
of an over contrained dependency. This evangenlism is usually accompanied by
a A2 page of dependency graph scribbles ;-)
> They are optional, so you do not depend on them transitively.
>
so in order to enable something thats optional i have to include those same
dependencies myself? Rather than depend upon an artifact that will resolve
only the dependencies I want and the correct graph for what I need?
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
"Optional dependencies are used when it's not really possible (for whatever
reason) to split a project up into sub-modules. The idea is that some of the
dependencies are only used for certain features in the project, and will not
be needed if that feature isn't used. Ideally, such a feature would be split
into a sub-module that depended on the core functionality project...this new
subproject would have only non-optional dependencies, since you'd need them
all if you decided to use the subproject's functionality."
> Commons logging has a different philosophy. But this is OT for this list.
If the difference in philosophy means more difficulty in managing dependency
graphs then its not OT for this list but very pertinent.
On Tuesday 28 August 2007 18:03, Jörg Schaible wrote:
> Hi Michael,
>
> Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
> > IMO the log4j, logkit, avalon dependencies all need to go... I as I
> > imagine most people do only use one logging implementation in the
> > deployed systems why introduce a dependency on several
> > implementations at the top level?
>
> They are optional, so you do not depend on them transitively.
>
> > check out http://www.slf4j.com for an appropriate break up of the
> > artifacts and use cases
>
> Commons logging has a different philosophy. But this is OT for this list.
>
> > I've generally stopped using dependencyManagement in favour of
> > dependency composition
>
> Why? Only with dependencyManagement you're able to manage transitive
> versions.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Barrie Treloar <ba...@gmail.com>.
On 8/28/07, Jörg Schaible <Jo...@elsag-solutions.com> wrote:
> Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
> > I've generally stopped using dependencyManagement in favour of
> > dependency composition
>
> Why? Only with dependencyManagement you're able to manage transitive versions.
Michael, could you expand on what you mean by dependency composition
as I have the same question as Jörg.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Community review of the next commons-logging pom
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Hi Michael,
Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
> IMO the log4j, logkit, avalon dependencies all need to go... I as I
> imagine most people do only use one logging implementation in the
> deployed systems why introduce a dependency on several
> implementations at the top level?
They are optional, so you do not depend on them transitively.
> check out http://www.slf4j.com for an appropriate break up of the
> artifacts and use cases
Commons logging has a different philosophy. But this is OT for this list.
> I've generally stopped using dependencyManagement in favour of
> dependency composition
Why? Only with dependencyManagement you're able to manage transitive versions.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
Michael McCallum wrote:
> IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
> most people do only use one logging implementation in the deployed systems
> why introduce a dependency on several implementations at the top level?
Commons-logging only has one level, the top level. So these all need to
be in the one, and only, pom we have. If we decide in the future (not
for this patch release) to "mavenize" commons-logging there would be a
hierarchy of poms.
> check out http://www.slf4j.com for an appropriate break up of the artifacts
> and use cases
I will not get into a debate on which logging library to use. The
purpose of my first mail was to make sure that the pom for
commons-logging is as good as it can be, for the way commons-logging works.
> I've generally stopped using dependencyManagement in favour of dependency
> composition
>
> On Tuesday 28 August 2007 10:06, Stephane Nicoll wrote:
>> For the servlet-api dependency, provided scope is enough (provided is
>> not transitive).
>>
>> Thanks,
>> Stéphane
>>
>> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>>> Hi all
>>>
>>> The poms for commons logging has taken some beating on this list over
>>> the years. The reason for that has been the dependencies section.
>>> Previous poms of commons-logging was created for Maven 1. These were
>>> then converted into Maven 2 poms with various degree of success. In
>>> particular the scope wasn't set properly.
>>>
>>> We are now preparing the next release of commons-logging (version 1.1.1)
>>> which will be built with Maven 2. That means that the pom that ends up
>>> in the Maven 2 repository will be the same one that we have created.
>>>
>>> To make sure that we have covered all bases this time we invite you, the
>>> community, to help us get it right. The current pom.xml is available for
>>> your viewing in our subversion repository:
>>>
>>>
>>> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revisi
>>> on=568979&view=markup
>>>
>>> Please post any comments you have on the pom to this list, and I will
>>> bring the over to the commons community.
>>>
>>> --
>>> Dennis Lundberg
>>> Apache Commons committer and PMC member
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Michael McCallum <gh...@apache.org>.
IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
most people do only use one logging implementation in the deployed systems
why introduce a dependency on several implementations at the top level?
check out http://www.slf4j.com for an appropriate break up of the artifacts
and use cases
I've generally stopped using dependencyManagement in favour of dependency
composition
On Tuesday 28 August 2007 10:06, Stephane Nicoll wrote:
> For the servlet-api dependency, provided scope is enough (provided is
> not transitive).
>
> Thanks,
> Stéphane
>
> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> > Hi all
> >
> > The poms for commons logging has taken some beating on this list over
> > the years. The reason for that has been the dependencies section.
> > Previous poms of commons-logging was created for Maven 1. These were
> > then converted into Maven 2 poms with various degree of success. In
> > particular the scope wasn't set properly.
> >
> > We are now preparing the next release of commons-logging (version 1.1.1)
> > which will be built with Maven 2. That means that the pom that ends up
> > in the Maven 2 repository will be the same one that we have created.
> >
> > To make sure that we have covered all bases this time we invite you, the
> > community, to help us get it right. The current pom.xml is available for
> > your viewing in our subversion repository:
> >
> >
> > https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revisi
> >on=568979&view=markup
> >
> > Please post any comments you have on the pom to this list, and I will
> > bring the over to the commons community.
> >
> > --
> > Dennis Lundberg
> > Apache Commons committer and PMC member
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
Yes, it is enough, but by adding <optional>true</optional> we wanted to
show that the dependency is also optional. You will only need it if you
use certain features of commons-logging. And <scope>provided</scope>
says that it will be provided by the container, if you decide to use
those features.
Stephane Nicoll wrote:
> For the servlet-api dependency, provided scope is enough (provided is
> not transitive).
>
> Thanks,
> Stéphane
>
> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>> Hi all
>>
>> The poms for commons logging has taken some beating on this list over
>> the years. The reason for that has been the dependencies section.
>> Previous poms of commons-logging was created for Maven 1. These were
>> then converted into Maven 2 poms with various degree of success. In
>> particular the scope wasn't set properly.
>>
>> We are now preparing the next release of commons-logging (version 1.1.1)
>> which will be built with Maven 2. That means that the pom that ends up
>> in the Maven 2 repository will be the same one that we have created.
>>
>> To make sure that we have covered all bases this time we invite you, the
>> community, to help us get it right. The current pom.xml is available for
>> your viewing in our subversion repository:
>>
>>
>> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>>
>> Please post any comments you have on the pom to this list, and I will
>> bring the over to the commons community.
>>
>> --
>> Dennis Lundberg
>> Apache Commons committer and PMC member
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Stephane Nicoll <st...@gmail.com>.
For the servlet-api dependency, provided scope is enough (provided is
not transitive).
Thanks,
Stéphane
On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> Hi all
>
> The poms for commons logging has taken some beating on this list over
> the years. The reason for that has been the dependencies section.
> Previous poms of commons-logging was created for Maven 1. These were
> then converted into Maven 2 poms with various degree of success. In
> particular the scope wasn't set properly.
>
> We are now preparing the next release of commons-logging (version 1.1.1)
> which will be built with Maven 2. That means that the pom that ends up
> in the Maven 2 repository will be the same one that we have created.
>
> To make sure that we have covered all bases this time we invite you, the
> community, to help us get it right. The current pom.xml is available for
> your viewing in our subversion repository:
>
>
> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>
> Please post any comments you have on the pom to this list, and I will
> bring the over to the commons community.
>
> --
> Dennis Lundberg
> Apache Commons committer and PMC member
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Carlos Sanchez <ca...@apache.org>.
You can ping the people from Apache Felix, they create bundles of
apache projects for consumption in OSGi with the goal of contributing
it back to the projects.
They will tell you if it's ready or not for the projects.
On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> Hi Tom
>
> I've heard the term OSGi from time to time, but have never took the time
> to learn more about it. Do you know of a good place where I can find out
> more about it?
>
> A quick look at Google suggests that it has something to do with entries
> in the manifest in the jar file, is that correct?
>
> What would they look like and what is the benefit for the community if
> we add them?
>
> Tom Huybrechts wrote:
> > Is there any chance that OSGi headers could be added ?
> >
> > On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> >> Hi all
> >>
> >> The poms for commons logging has taken some beating on this list over
> >> the years. The reason for that has been the dependencies section.
> >> Previous poms of commons-logging was created for Maven 1. These were
> >> then converted into Maven 2 poms with various degree of success. In
> >> particular the scope wasn't set properly.
> >>
> >> We are now preparing the next release of commons-logging (version 1.1.1)
> >> which will be built with Maven 2. That means that the pom that ends up
> >> in the Maven 2 repository will be the same one that we have created.
> >>
> >> To make sure that we have covered all bases this time we invite you, the
> >> community, to help us get it right. The current pom.xml is available for
> >> your viewing in our subversion repository:
> >>
> >>
> >> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
> >>
> >> Please post any comments you have on the pom to this list, and I will
> >> bring the over to the commons community.
> >>
> >> --
> >> Dennis Lundberg
> >> Apache Commons committer and PMC member
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
Thanks Tom,
I'll bring this up with the commons developers and we'll see what
happens. Probably won't be in this release though.
Tom Huybrechts wrote:
> This is the OSGi technical whitepaper:
> http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf .
> Most relevant here is the Modularity section of the Architecture
> chapter.
>
> To be usable in an OSGi setting, the jar manifest needs to have some
> entries added. Most important are the name and version, and a list of
> packages that are provided and/or used by the plugin.
>
> The Apache Felix project has a maven-bundle-plugin that automates this process.
> More info here:
> http://cwiki.apache.org/confluence/display/FELIX/Maven+Bundle+Plugin+%28BND%29
> One of the things you can also do with this plugin, is select which
> packages end up in your jar. Looking at the current POM, that might be
> useful.
>
> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>> Hi Tom
>>
>> I've heard the term OSGi from time to time, but have never took the time
>> to learn more about it. Do you know of a good place where I can find out
>> more about it?
>>
>> A quick look at Google suggests that it has something to do with entries
>> in the manifest in the jar file, is that correct?
>>
>> What would they look like and what is the benefit for the community if
>> we add them?
>>
>> Tom Huybrechts wrote:
>>> Is there any chance that OSGi headers could be added ?
>>>
>>> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>>>> Hi all
>>>>
>>>> The poms for commons logging has taken some beating on this list over
>>>> the years. The reason for that has been the dependencies section.
>>>> Previous poms of commons-logging was created for Maven 1. These were
>>>> then converted into Maven 2 poms with various degree of success. In
>>>> particular the scope wasn't set properly.
>>>>
>>>> We are now preparing the next release of commons-logging (version 1.1.1)
>>>> which will be built with Maven 2. That means that the pom that ends up
>>>> in the Maven 2 repository will be the same one that we have created.
>>>>
>>>> To make sure that we have covered all bases this time we invite you, the
>>>> community, to help us get it right. The current pom.xml is available for
>>>> your viewing in our subversion repository:
>>>>
>>>>
>>>> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>>>>
>>>> Please post any comments you have on the pom to this list, and I will
>>>> bring the over to the commons community.
>>>>
>>>> --
>>>> Dennis Lundberg
>>>> Apache Commons committer and PMC member
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Tom Huybrechts <to...@gmail.com>.
This is the OSGi technical whitepaper:
http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf .
Most relevant here is the Modularity section of the Architecture
chapter.
To be usable in an OSGi setting, the jar manifest needs to have some
entries added. Most important are the name and version, and a list of
packages that are provided and/or used by the plugin.
The Apache Felix project has a maven-bundle-plugin that automates this process.
More info here:
http://cwiki.apache.org/confluence/display/FELIX/Maven+Bundle+Plugin+%28BND%29
One of the things you can also do with this plugin, is select which
packages end up in your jar. Looking at the current POM, that might be
useful.
On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> Hi Tom
>
> I've heard the term OSGi from time to time, but have never took the time
> to learn more about it. Do you know of a good place where I can find out
> more about it?
>
> A quick look at Google suggests that it has something to do with entries
> in the manifest in the jar file, is that correct?
>
> What would they look like and what is the benefit for the community if
> we add them?
>
> Tom Huybrechts wrote:
> > Is there any chance that OSGi headers could be added ?
> >
> > On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> >> Hi all
> >>
> >> The poms for commons logging has taken some beating on this list over
> >> the years. The reason for that has been the dependencies section.
> >> Previous poms of commons-logging was created for Maven 1. These were
> >> then converted into Maven 2 poms with various degree of success. In
> >> particular the scope wasn't set properly.
> >>
> >> We are now preparing the next release of commons-logging (version 1.1.1)
> >> which will be built with Maven 2. That means that the pom that ends up
> >> in the Maven 2 repository will be the same one that we have created.
> >>
> >> To make sure that we have covered all bases this time we invite you, the
> >> community, to help us get it right. The current pom.xml is available for
> >> your viewing in our subversion repository:
> >>
> >>
> >> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
> >>
> >> Please post any comments you have on the pom to this list, and I will
> >> bring the over to the commons community.
> >>
> >> --
> >> Dennis Lundberg
> >> Apache Commons committer and PMC member
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
Hi Tom
I've heard the term OSGi from time to time, but have never took the time
to learn more about it. Do you know of a good place where I can find out
more about it?
A quick look at Google suggests that it has something to do with entries
in the manifest in the jar file, is that correct?
What would they look like and what is the benefit for the community if
we add them?
Tom Huybrechts wrote:
> Is there any chance that OSGi headers could be added ?
>
> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>> Hi all
>>
>> The poms for commons logging has taken some beating on this list over
>> the years. The reason for that has been the dependencies section.
>> Previous poms of commons-logging was created for Maven 1. These were
>> then converted into Maven 2 poms with various degree of success. In
>> particular the scope wasn't set properly.
>>
>> We are now preparing the next release of commons-logging (version 1.1.1)
>> which will be built with Maven 2. That means that the pom that ends up
>> in the Maven 2 repository will be the same one that we have created.
>>
>> To make sure that we have covered all bases this time we invite you, the
>> community, to help us get it right. The current pom.xml is available for
>> your viewing in our subversion repository:
>>
>>
>> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>>
>> Please post any comments you have on the pom to this list, and I will
>> bring the over to the commons community.
>>
>> --
>> Dennis Lundberg
>> Apache Commons committer and PMC member
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Tom Huybrechts <to...@gmail.com>.
Is there any chance that OSGi headers could be added ?
On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> Hi all
>
> The poms for commons logging has taken some beating on this list over
> the years. The reason for that has been the dependencies section.
> Previous poms of commons-logging was created for Maven 1. These were
> then converted into Maven 2 poms with various degree of success. In
> particular the scope wasn't set properly.
>
> We are now preparing the next release of commons-logging (version 1.1.1)
> which will be built with Maven 2. That means that the pom that ends up
> in the Maven 2 repository will be the same one that we have created.
>
> To make sure that we have covered all bases this time we invite you, the
> community, to help us get it right. The current pom.xml is available for
> your viewing in our subversion repository:
>
>
> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>
> Please post any comments you have on the pom to this list, and I will
> bring the over to the commons community.
>
> --
> Dennis Lundberg
> Apache Commons committer and PMC member
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Dennis Lundberg <de...@apache.org>.
Wayne Fay wrote:
> A couple comments... take them or not, entirely your choice:
>
> 1. The properties at the bottom -- any reason you aren't just
> configuring maven-compiler-plugin instead?
Actually we are, in the parent. I forgot to send the url to the parent
pom in my first mail, but here it is:
https://svn.apache.org/viewvc/commons/proper/commons-parent/tags/commons-parent-4/pom.xml?revision=564649&view=markup
> 2. Its a bit unfortunate the maven-jar-plugin doesn't support the
> includes/excludes you require, and so you have to use antrun instead.
> I found MJAR-30 so its been posted as an issue, but it seems like no
> one has offered any patches for it. This seems like an old issue, with
> a number of people being interested in it, so I'm not quite sure why
> it hasn't been addressed -- the lack of a patch seems to be a failure
> in the community/process.
Yeah, I've been meaning to have a look at fixing that, but have always
been sidetracked :-(
> 3. Many of your plugins do not declare any scope, meaning default
> "compile" scope. I prefer to declare all scopes rather than assuming
> default. So I'd add <scope>compile</scope> to those missing a scope.
That sounds like good advice. I'll look into it, later.
> 4. Some but not all of your plugins have versions declared. I like to
> see versions for everything.
Yes, we do too. Some are declared in pluginManagement in the parent. But
I see now that antrun-plugin and assembly-plugin are missing versions.
I'll attend to that.
> 5. I like <dependencyManagement> and <pluginManagement>. You don't
> have to use them (and you're obviously not using them right now), but
> I like them.
See above.
> The areas I'm primarily concerned with seem to be handled in this
> version, so Bravo! These are minor nits.
Thanks a lot for your time Wayne.
>
> Wayne
>
> On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
>> Hi all
>>
>> The poms for commons logging has taken some beating on this list over
>> the years. The reason for that has been the dependencies section.
>> Previous poms of commons-logging was created for Maven 1. These were
>> then converted into Maven 2 poms with various degree of success. In
>> particular the scope wasn't set properly.
>>
>> We are now preparing the next release of commons-logging (version 1.1.1)
>> which will be built with Maven 2. That means that the pom that ends up
>> in the Maven 2 repository will be the same one that we have created.
>>
>> To make sure that we have covered all bases this time we invite you, the
>> community, to help us get it right. The current pom.xml is available for
>> your viewing in our subversion repository:
>>
>>
>> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>>
>> Please post any comments you have on the pom to this list, and I will
>> bring the over to the commons community.
>>
>> --
>> Dennis Lundberg
>> Apache Commons committer and PMC member
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Community review of the next commons-logging pom
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Wayne Fay wrote on Monday, August 27, 2007 8:55 PM:
> A couple comments... take them or not, entirely your choice:
>
> 1. The properties at the bottom -- any reason you aren't just
> configuring maven-compiler-plugin instead?
Although not done here, but you need the same values configuring the javadoc plugin ... and that one you might have to configure in two places ;-)
[snip]
Other topics already answered by Dennis,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Community review of the next commons-logging pom
Posted by Wayne Fay <wa...@gmail.com>.
A couple comments... take them or not, entirely your choice:
1. The properties at the bottom -- any reason you aren't just
configuring maven-compiler-plugin instead?
2. Its a bit unfortunate the maven-jar-plugin doesn't support the
includes/excludes you require, and so you have to use antrun instead.
I found MJAR-30 so its been posted as an issue, but it seems like no
one has offered any patches for it. This seems like an old issue, with
a number of people being interested in it, so I'm not quite sure why
it hasn't been addressed -- the lack of a patch seems to be a failure
in the community/process.
3. Many of your plugins do not declare any scope, meaning default
"compile" scope. I prefer to declare all scopes rather than assuming
default. So I'd add <scope>compile</scope> to those missing a scope.
4. Some but not all of your plugins have versions declared. I like to
see versions for everything.
5. I like <dependencyManagement> and <pluginManagement>. You don't
have to use them (and you're obviously not using them right now), but
I like them.
The areas I'm primarily concerned with seem to be handled in this
version, so Bravo! These are minor nits.
Wayne
On 8/27/07, Dennis Lundberg <de...@apache.org> wrote:
> Hi all
>
> The poms for commons logging has taken some beating on this list over
> the years. The reason for that has been the dependencies section.
> Previous poms of commons-logging was created for Maven 1. These were
> then converted into Maven 2 poms with various degree of success. In
> particular the scope wasn't set properly.
>
> We are now preparing the next release of commons-logging (version 1.1.1)
> which will be built with Maven 2. That means that the pom that ends up
> in the Maven 2 repository will be the same one that we have created.
>
> To make sure that we have covered all bases this time we invite you, the
> community, to help us get it right. The current pom.xml is available for
> your viewing in our subversion repository:
>
>
> https://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?revision=568979&view=markup
>
> Please post any comments you have on the pom to this list, and I will
> bring the over to the commons community.
>
> --
> Dennis Lundberg
> Apache Commons committer and PMC member
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org