You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2012/12/28 18:21:26 UTC
[commons-parent] drop cobertura
Any objections to this? In [math] at least we can't seem to turn it
off and it is causing the site build to take forever.
Thanks!
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 28/12/2012 18:21, Phil Steitz a écrit :
> Any objections to this? In [math] at least we can't seem to turn it
> off and it is causing the site build to take forever.
Go for it.
Luc
>
> Thanks!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Dec 29, 2012 at 8:21 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/29/12 10:44 AM, Mark Struberg wrote:
>>> Any better suggestions for [math]?
>> Yes, as I see it there are two options.
>>
>> a.) move some parts into a profile
>
> How exactly would this work? Can we get rid of stuff that way,
> really? We can get it to ignore stuff the parent specifies? Or are
> you talking about yet another profile in the parent?
>> b.) create 2 parent pom. One with the infrastructure stuff and one with all the tons of additional goodies only needed for the other projects.
>
> That seems pretty ugly. I wonder how bad it would be, actually, to
> just get rid of the parent and define the stuff we actually use /
> need in [math] itself. I think I have on balance spent more time
> figuring out what was going on in the parent than I would have spent
> just maintaining properties actually used by the components that I
> work on. Maybe just strip it down to some common properties and
> things like the mailing lists. At the very least, we should drop
> the reporting section and the one you mention below.
>
>>
>>
>> LieGrue,
>> strub
>>
>>
>> PS: I find it pretty weird that the commons-parent has a profile to build all the other stuff. This can be done much cleaner in having an own build-aggregator pom which just contains the <modules>.
>
> Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
I've used it in the past - useful for testing all components with
changes to commons parent or the commons plugin which generates some
of the site pages. Its in a profile, so does no harm.
Niall
> Phil
>>
>>
>> ----- Original Message -----
>>> From: Phil Steitz <ph...@gmail.com>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> Cc:
>>> Sent: Saturday, December 29, 2012 7:29 PM
>>> Subject: Re: [commons-parent] drop cobertura
>>>
>>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>>> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>>>> commons components to Sonar, just do not mess up development for all the
>>>> other components because one class in [math] is not performing acceptably
>>>> for the Cobertura report.
>>> The problem is that the plugin is bugged and effectively impossible
>>> to turn off.
>>>
>>> I think the sonar idea is a great one and consistent with what we
>>> have talked about on and off for years - separating the CI-type
>>> development reports from the component sites. As we are about to go
>>> over the "site deployment cliff ;" now is a great time to think
>>> about losing some weight :)
>>>
>>> I guess an alternative for [math] is to drop commons-parent
>>> entirely, just grabbing the stuff we need. Any better suggestions
>>> for [math]?
>>>
>>> Phil
>>>> Gary
>>>>
>>>>
>>>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
>>> wrote:
>>>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>>>> It seems a shame to turn off this feature for ALL
>>> projects
>>>>>>>>> because one
>>>>>>>>> project can't figure out a workaround.
>>>>>>>> Can *any* project find a workaround? Is there *any way* to
>>> turn
>>>>>>>> this thing off?
>>>>>>> What about every project being declared in the aggregator
>>> project
>>>>>>> Olivier set up in our instance of Sonar
>>>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We could then even disable more reports in the components' poms
>>>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>>>> instance.
>>>>>>
>>>>>> This would provide comprehensive up-to-date statistics for all
>>>>>> components. It would also be a step forward in making the
>>>>>> components more uniform.
>>>>> +1 - and as yet another bonus, it would reduce wasted infra
>>>>> resources duplicating all of the images, etc on all of the
>>>>> individual sites and the need to store all of that stuff in svn.
>>>>>
>>>>> Phil
>>>>>> Oliver
>>>>>>
>>>>>>> Luc
>>>>>>>
>>>>>>>> Phil
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
>>> <ph...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Any objections to this? In [math] at least we
>>> can't seem to
>>>>>>>>>> turn it
>>>>>>>>>> off and it is causing the site build to take
>>> forever.
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by James Carman <ja...@carmanconsulting.com>.
We should just move the non-development stuff (stuff that we'll run in
a CI environment, though) into a profile.
On Sat, Dec 29, 2012 at 7:28 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/12/29 Oliver Heger <ol...@oliver-heger.de>:
>> Am 29.12.2012 21:21, schrieb Phil Steitz:
>>
>>> On 12/29/12 10:44 AM, Mark Struberg wrote:
>>>>>
>>>>> Any better suggestions for [math]?
>>>>
>>>> Yes, as I see it there are two options.
>>>>
>>>> a.) move some parts into a profile
>>>
>>>
>>> How exactly would this work? Can we get rid of stuff that way,
>>> really? We can get it to ignore stuff the parent specifies? Or are
>>> you talking about yet another profile in the parent?
>>
>>
>> Could we move the major part of the reports into a profile which is not
>> enabled per default? Then everybody can build a site locally containing all
>> these reports by just enabling the profile. The official sites would not
>> contain reports, but reference Sonar.
> Sounds good call it reporting.
> If folks want to run cobertura, findbugs etc they just need to add -Preporting.
> If you want to publish those reports run maven site with it.
>
>>
>> Oliver
>>
>>
>>>> b.) create 2 parent pom. One with the infrastructure stuff and one with
>>>> all the tons of additional goodies only needed for the other projects.
>>>
>>>
>>> That seems pretty ugly. I wonder how bad it would be, actually, to
>>> just get rid of the parent and define the stuff we actually use /
>>> need in [math] itself. I think I have on balance spent more time
>>> figuring out what was going on in the parent than I would have spent
>>> just maintaining properties actually used by the components that I
>>> work on. Maybe just strip it down to some common properties and
>>> things like the mailing lists. At the very least, we should drop
>>> the reporting section and the one you mention below.
>>>
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> PS: I find it pretty weird that the commons-parent has a profile to build
>>>> all the other stuff. This can be done much cleaner in having an own
>>>> build-aggregator pom which just contains the <modules>.
>>>
>>>
>>> Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
>>>
>>> Phil
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>> From: Phil Steitz <ph...@gmail.com>
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> Cc:
>>>>> Sent: Saturday, December 29, 2012 7:29 PM
>>>>> Subject: Re: [commons-parent] drop cobertura
>>>>>
>>>>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>>>>>
>>>>>> Using Sonar is an orthogonal issue to using reports in the POM. Sure,
>>>>>> add
>>>>>> commons components to Sonar, just do not mess up development for all
>>>>>> the
>>>>>> other components because one class in [math] is not performing
>>>>>> acceptably
>>>>>> for the Cobertura report.
>>>>>
>>>>> The problem is that the plugin is bugged and effectively impossible
>>>>> to turn off.
>>>>>
>>>>> I think the sonar idea is a great one and consistent with what we
>>>>> have talked about on and off for years - separating the CI-type
>>>>> development reports from the component sites. As we are about to go
>>>>> over the "site deployment cliff ;" now is a great time to think
>>>>> about losing some weight :)
>>>>>
>>>>> I guess an alternative for [math] is to drop commons-parent
>>>>> entirely, just grabbing the stuff we need. Any better suggestions
>>>>> for [math]?
>>>>>
>>>>> Phil
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>>>>>>
>>>>>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>>>>>>
>>>>>>>>> Hi Phil,
>>>>>>>>>
>>>>>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>>>>>>
>>>>>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>>>>>>
>>>>>>>>>>> It seems a shame to turn off this feature for ALL
>>>>>
>>>>> projects
>>>>>>>>>>>
>>>>>>>>>>> because one
>>>>>>>>>>> project can't figure out a workaround.
>>>>>>>>>>
>>>>>>>>>> Can *any* project find a workaround? Is there *any way* to
>>>>>
>>>>> turn
>>>>>>>>>>
>>>>>>>>>> this thing off?
>>>>>>>>>
>>>>>>>>> What about every project being declared in the aggregator
>>>>>
>>>>> project
>>>>>>>>>
>>>>>>>>> Olivier set up in our instance of Sonar
>>>>>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> We could then even disable more reports in the components' poms
>>>>>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>>>>>> instance.
>>>>>>>>
>>>>>>>> This would provide comprehensive up-to-date statistics for all
>>>>>>>> components. It would also be a step forward in making the
>>>>>>>> components more uniform.
>>>>>>>
>>>>>>> +1 - and as yet another bonus, it would reduce wasted infra
>>>>>>> resources duplicating all of the images, etc on all of the
>>>>>>> individual sites and the need to store all of that stuff in svn.
>>>>>>>
>>>>>>> Phil
>>>>>>>>
>>>>>>>> Oliver
>>>>>>>>
>>>>>>>>> Luc
>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
>>>>>
>>>>> <ph...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Any objections to this? In [math] at least we
>>>>>
>>>>> can't seem to
>>>>>>>>>>>>
>>>>>>>>>>>> turn it
>>>>>>>>>>>> off and it is causing the site build to take
>>>>>
>>>>> forever.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>
>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>
>>>>> dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>
>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>> For additional commands, e-mail:
>>>>>
>>>>> dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>>>
>>>>> dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/29 Oliver Heger <ol...@oliver-heger.de>:
> Am 29.12.2012 21:21, schrieb Phil Steitz:
>
>> On 12/29/12 10:44 AM, Mark Struberg wrote:
>>>>
>>>> Any better suggestions for [math]?
>>>
>>> Yes, as I see it there are two options.
>>>
>>> a.) move some parts into a profile
>>
>>
>> How exactly would this work? Can we get rid of stuff that way,
>> really? We can get it to ignore stuff the parent specifies? Or are
>> you talking about yet another profile in the parent?
>
>
> Could we move the major part of the reports into a profile which is not
> enabled per default? Then everybody can build a site locally containing all
> these reports by just enabling the profile. The official sites would not
> contain reports, but reference Sonar.
Sounds good call it reporting.
If folks want to run cobertura, findbugs etc they just need to add -Preporting.
If you want to publish those reports run maven site with it.
>
> Oliver
>
>
>>> b.) create 2 parent pom. One with the infrastructure stuff and one with
>>> all the tons of additional goodies only needed for the other projects.
>>
>>
>> That seems pretty ugly. I wonder how bad it would be, actually, to
>> just get rid of the parent and define the stuff we actually use /
>> need in [math] itself. I think I have on balance spent more time
>> figuring out what was going on in the parent than I would have spent
>> just maintaining properties actually used by the components that I
>> work on. Maybe just strip it down to some common properties and
>> things like the mailing lists. At the very least, we should drop
>> the reporting section and the one you mention below.
>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> PS: I find it pretty weird that the commons-parent has a profile to build
>>> all the other stuff. This can be done much cleaner in having an own
>>> build-aggregator pom which just contains the <modules>.
>>
>>
>> Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
>>
>> Phil
>>>
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>> From: Phil Steitz <ph...@gmail.com>
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>> Cc:
>>>> Sent: Saturday, December 29, 2012 7:29 PM
>>>> Subject: Re: [commons-parent] drop cobertura
>>>>
>>>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>>>>
>>>>> Using Sonar is an orthogonal issue to using reports in the POM. Sure,
>>>>> add
>>>>> commons components to Sonar, just do not mess up development for all
>>>>> the
>>>>> other components because one class in [math] is not performing
>>>>> acceptably
>>>>> for the Cobertura report.
>>>>
>>>> The problem is that the plugin is bugged and effectively impossible
>>>> to turn off.
>>>>
>>>> I think the sonar idea is a great one and consistent with what we
>>>> have talked about on and off for years - separating the CI-type
>>>> development reports from the component sites. As we are about to go
>>>> over the "site deployment cliff ;" now is a great time to think
>>>> about losing some weight :)
>>>>
>>>> I guess an alternative for [math] is to drop commons-parent
>>>> entirely, just grabbing the stuff we need. Any better suggestions
>>>> for [math]?
>>>>
>>>> Phil
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
>>>>
>>>> wrote:
>>>>>>
>>>>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>>>>>
>>>>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>>>>>
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>>>>>
>>>>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>>>>>
>>>>>>>>>> It seems a shame to turn off this feature for ALL
>>>>
>>>> projects
>>>>>>>>>>
>>>>>>>>>> because one
>>>>>>>>>> project can't figure out a workaround.
>>>>>>>>>
>>>>>>>>> Can *any* project find a workaround? Is there *any way* to
>>>>
>>>> turn
>>>>>>>>>
>>>>>>>>> this thing off?
>>>>>>>>
>>>>>>>> What about every project being declared in the aggregator
>>>>
>>>> project
>>>>>>>>
>>>>>>>> Olivier set up in our instance of Sonar
>>>>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> We could then even disable more reports in the components' poms
>>>>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>>>>> instance.
>>>>>>>
>>>>>>> This would provide comprehensive up-to-date statistics for all
>>>>>>> components. It would also be a step forward in making the
>>>>>>> components more uniform.
>>>>>>
>>>>>> +1 - and as yet another bonus, it would reduce wasted infra
>>>>>> resources duplicating all of the images, etc on all of the
>>>>>> individual sites and the need to store all of that stuff in svn.
>>>>>>
>>>>>> Phil
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>>> Luc
>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
>>>>
>>>> <ph...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Any objections to this? In [math] at least we
>>>>
>>>> can't seem to
>>>>>>>>>>>
>>>>>>>>>>> turn it
>>>>>>>>>>> off and it is causing the site build to take
>>>>
>>>> forever.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail:
>>>>
>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>> For additional commands, e-mail:
>>>>
>>>> dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>
>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>
>>>>>>>>>> For additional commands, e-mail:
>>>>
>>>> dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail:
>>>>
>>>> dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 29.12.2012 21:21, schrieb Phil Steitz:
> On 12/29/12 10:44 AM, Mark Struberg wrote:
>>> Any better suggestions for [math]?
>> Yes, as I see it there are two options.
>>
>> a.) move some parts into a profile
>
> How exactly would this work? Can we get rid of stuff that way,
> really? We can get it to ignore stuff the parent specifies? Or are
> you talking about yet another profile in the parent?
Could we move the major part of the reports into a profile which is not
enabled per default? Then everybody can build a site locally containing
all these reports by just enabling the profile. The official sites would
not contain reports, but reference Sonar.
Oliver
>> b.) create 2 parent pom. One with the infrastructure stuff and one with all the tons of additional goodies only needed for the other projects.
>
> That seems pretty ugly. I wonder how bad it would be, actually, to
> just get rid of the parent and define the stuff we actually use /
> need in [math] itself. I think I have on balance spent more time
> figuring out what was going on in the parent than I would have spent
> just maintaining properties actually used by the components that I
> work on. Maybe just strip it down to some common properties and
> things like the mailing lists. At the very least, we should drop
> the reporting section and the one you mention below.
>
>>
>>
>> LieGrue,
>> strub
>>
>>
>> PS: I find it pretty weird that the commons-parent has a profile to build all the other stuff. This can be done much cleaner in having an own build-aggregator pom which just contains the <modules>.
>
> Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
>
> Phil
>>
>>
>> ----- Original Message -----
>>> From: Phil Steitz <ph...@gmail.com>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> Cc:
>>> Sent: Saturday, December 29, 2012 7:29 PM
>>> Subject: Re: [commons-parent] drop cobertura
>>>
>>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>>> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>>>> commons components to Sonar, just do not mess up development for all the
>>>> other components because one class in [math] is not performing acceptably
>>>> for the Cobertura report.
>>> The problem is that the plugin is bugged and effectively impossible
>>> to turn off.
>>>
>>> I think the sonar idea is a great one and consistent with what we
>>> have talked about on and off for years - separating the CI-type
>>> development reports from the component sites. As we are about to go
>>> over the "site deployment cliff ;" now is a great time to think
>>> about losing some weight :)
>>>
>>> I guess an alternative for [math] is to drop commons-parent
>>> entirely, just grabbing the stuff we need. Any better suggestions
>>> for [math]?
>>>
>>> Phil
>>>> Gary
>>>>
>>>>
>>>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
>>> wrote:
>>>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>>>> It seems a shame to turn off this feature for ALL
>>> projects
>>>>>>>>> because one
>>>>>>>>> project can't figure out a workaround.
>>>>>>>> Can *any* project find a workaround? Is there *any way* to
>>> turn
>>>>>>>> this thing off?
>>>>>>> What about every project being declared in the aggregator
>>> project
>>>>>>> Olivier set up in our instance of Sonar
>>>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We could then even disable more reports in the components' poms
>>>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>>>> instance.
>>>>>>
>>>>>> This would provide comprehensive up-to-date statistics for all
>>>>>> components. It would also be a step forward in making the
>>>>>> components more uniform.
>>>>> +1 - and as yet another bonus, it would reduce wasted infra
>>>>> resources duplicating all of the images, etc on all of the
>>>>> individual sites and the need to store all of that stuff in svn.
>>>>>
>>>>> Phil
>>>>>> Oliver
>>>>>>
>>>>>>> Luc
>>>>>>>
>>>>>>>> Phil
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
>>> <ph...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Any objections to this? In [math] at least we
>>> can't seem to
>>>>>>>>>> turn it
>>>>>>>>>> off and it is causing the site build to take
>>> forever.
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/29/12 10:44 AM, Mark Struberg wrote:
>> Any better suggestions for [math]?
> Yes, as I see it there are two options.
>
> a.) move some parts into a profile
How exactly would this work? Can we get rid of stuff that way,
really? We can get it to ignore stuff the parent specifies? Or are
you talking about yet another profile in the parent?
> b.) create 2 parent pom. One with the infrastructure stuff and one with all the tons of additional goodies only needed for the other projects.
That seems pretty ugly. I wonder how bad it would be, actually, to
just get rid of the parent and define the stuff we actually use /
need in [math] itself. I think I have on balance spent more time
figuring out what was going on in the parent than I would have spent
just maintaining properties actually used by the components that I
work on. Maybe just strip it down to some common properties and
things like the mailing lists. At the very least, we should drop
the reporting section and the one you mention below.
>
>
> LieGrue,
> strub
>
>
> PS: I find it pretty weird that the commons-parent has a profile to build all the other stuff. This can be done much cleaner in having an own build-aggregator pom which just contains the <modules>.
Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
Phil
>
>
> ----- Original Message -----
>> From: Phil Steitz <ph...@gmail.com>
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc:
>> Sent: Saturday, December 29, 2012 7:29 PM
>> Subject: Re: [commons-parent] drop cobertura
>>
>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>>> commons components to Sonar, just do not mess up development for all the
>>> other components because one class in [math] is not performing acceptably
>>> for the Cobertura report.
>> The problem is that the plugin is bugged and effectively impossible
>> to turn off.
>>
>> I think the sonar idea is a great one and consistent with what we
>> have talked about on and off for years - separating the CI-type
>> development reports from the component sites. As we are about to go
>> over the "site deployment cliff ;" now is a great time to think
>> about losing some weight :)
>>
>> I guess an alternative for [math] is to drop commons-parent
>> entirely, just grabbing the stuff we need. Any better suggestions
>> for [math]?
>>
>> Phil
>>> Gary
>>>
>>>
>>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
>> wrote:
>>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>>> Hi Phil,
>>>>>>
>>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>>> It seems a shame to turn off this feature for ALL
>> projects
>>>>>>>> because one
>>>>>>>> project can't figure out a workaround.
>>>>>>> Can *any* project find a workaround? Is there *any way* to
>> turn
>>>>>>> this thing off?
>>>>>> What about every project being declared in the aggregator
>> project
>>>>>> Olivier set up in our instance of Sonar
>>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>>
>>>>> +1
>>>>>
>>>>> We could then even disable more reports in the components' poms
>>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>>> instance.
>>>>>
>>>>> This would provide comprehensive up-to-date statistics for all
>>>>> components. It would also be a step forward in making the
>>>>> components more uniform.
>>>> +1 - and as yet another bonus, it would reduce wasted infra
>>>> resources duplicating all of the images, etc on all of the
>>>> individual sites and the need to store all of that stuff in svn.
>>>>
>>>> Phil
>>>>> Oliver
>>>>>
>>>>>> Luc
>>>>>>
>>>>>>> Phil
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
>> <ph...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Any objections to this? In [math] at least we
>> can't seem to
>>>>>>>>> turn it
>>>>>>>>> off and it is causing the site build to take
>> forever.
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Mark Struberg <st...@yahoo.de>.
> Any better suggestions for [math]?
Yes, as I see it there are two options.
a.) move some parts into a profile
b.) create 2 parent pom. One with the infrastructure stuff and one with all the tons of additional goodies only needed for the other projects.
LieGrue,
strub
PS: I find it pretty weird that the commons-parent has a profile to build all the other stuff. This can be done much cleaner in having an own build-aggregator pom which just contains the <modules>.
----- Original Message -----
> From: Phil Steitz <ph...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Saturday, December 29, 2012 7:29 PM
> Subject: Re: [commons-parent] drop cobertura
>
> On 12/29/12 10:02 AM, Gary Gregory wrote:
>> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>> commons components to Sonar, just do not mess up development for all the
>> other components because one class in [math] is not performing acceptably
>> for the Cobertura report.
>
> The problem is that the plugin is bugged and effectively impossible
> to turn off.
>
> I think the sonar idea is a great one and consistent with what we
> have talked about on and off for years - separating the CI-type
> development reports from the component sites. As we are about to go
> over the "site deployment cliff ;" now is a great time to think
> about losing some weight :)
>
> I guess an alternative for [math] is to drop commons-parent
> entirely, just grabbing the stuff we need. Any better suggestions
> for [math]?
>
> Phil
>>
>> Gary
>>
>>
>> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com>
> wrote:
>>
>>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>>> Hi Phil,
>>>>>
>>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>>> It seems a shame to turn off this feature for ALL
> projects
>>>>>>> because one
>>>>>>> project can't figure out a workaround.
>>>>>> Can *any* project find a workaround? Is there *any way* to
> turn
>>>>>> this thing off?
>>>>> What about every project being declared in the aggregator
> project
>>>>> Olivier set up in our instance of Sonar
>>>>> <https://analysis.apache.org/components/index/121254>?
>>>>>
>>>> +1
>>>>
>>>> We could then even disable more reports in the components' poms
>>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>> instance.
>>>>
>>>> This would provide comprehensive up-to-date statistics for all
>>>> components. It would also be a step forward in making the
>>>> components more uniform.
>>> +1 - and as yet another bonus, it would reduce wasted infra
>>> resources duplicating all of the images, etc on all of the
>>> individual sites and the need to store all of that stuff in svn.
>>>
>>> Phil
>>>> Oliver
>>>>
>>>>> Luc
>>>>>
>>>>>> Phil
>>>>>>> Gary
>>>>>>>
>>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz
> <ph...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Any objections to this? In [math] at least we
> can't seem to
>>>>>>>> turn it
>>>>>>>> off and it is causing the site build to take
> forever.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/29/12 10:02 AM, Gary Gregory wrote:
> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
> commons components to Sonar, just do not mess up development for all the
> other components because one class in [math] is not performing acceptably
> for the Cobertura report.
The problem is that the plugin is bugged and effectively impossible
to turn off.
I think the sonar idea is a great one and consistent with what we
have talked about on and off for years - separating the CI-type
development reports from the component sites. As we are about to go
over the "site deployment cliff ;" now is a great time to think
about losing some weight :)
I guess an alternative for [math] is to drop commons-parent
entirely, just grabbing the stuff we need. Any better suggestions
for [math]?
Phil
>
> Gary
>
>
> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>>> Hi Phil,
>>>>
>>>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>>>> It seems a shame to turn off this feature for ALL projects
>>>>>> because one
>>>>>> project can't figure out a workaround.
>>>>> Can *any* project find a workaround? Is there *any way* to turn
>>>>> this thing off?
>>>> What about every project being declared in the aggregator project
>>>> Olivier set up in our instance of Sonar
>>>> <https://analysis.apache.org/components/index/121254>?
>>>>
>>> +1
>>>
>>> We could then even disable more reports in the components' poms
>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>> instance.
>>>
>>> This would provide comprehensive up-to-date statistics for all
>>> components. It would also be a step forward in making the
>>> components more uniform.
>> +1 - and as yet another bonus, it would reduce wasted infra
>> resources duplicating all of the images, etc on all of the
>> individual sites and the need to store all of that stuff in svn.
>>
>> Phil
>>> Oliver
>>>
>>>> Luc
>>>>
>>>>> Phil
>>>>>> Gary
>>>>>>
>>>>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Any objections to this? In [math] at least we can't seem to
>>>>>>> turn it
>>>>>>> off and it is causing the site build to take forever.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Gary Gregory <ga...@gmail.com>.
Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
commons components to Sonar, just do not mess up development for all the
other components because one class in [math] is not performing acceptably
for the Cobertura report.
Gary
On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/29/12 9:46 AM, Oliver Heger wrote:
> > Am 29.12.2012 09:43, schrieb Luc Maisonobe:
> >> Hi Phil,
> >>
> >> Le 28/12/2012 21:10, Phil Steitz a écrit :
> >>> On 12/28/12 11:44 AM, Gary Gregory wrote:
> >>>> It seems a shame to turn off this feature for ALL projects
> >>>> because one
> >>>> project can't figure out a workaround.
> >>>
> >>> Can *any* project find a workaround? Is there *any way* to turn
> >>> this thing off?
> >>
> >> What about every project being declared in the aggregator project
> >> Olivier set up in our instance of Sonar
> >> <https://analysis.apache.org/components/index/121254>?
> >>
> >
> > +1
> >
> > We could then even disable more reports in the components' poms
> > (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
> > instance.
> >
> > This would provide comprehensive up-to-date statistics for all
> > components. It would also be a step forward in making the
> > components more uniform.
>
> +1 - and as yet another bonus, it would reduce wasted infra
> resources duplicating all of the images, etc on all of the
> individual sites and the need to store all of that stuff in svn.
>
> Phil
> >
> > Oliver
> >
> >> Luc
> >>
> >>>
> >>> Phil
> >>>>
> >>>> Gary
> >>>>
> >>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Any objections to this? In [math] at least we can't seem to
> >>>>> turn it
> >>>>> off and it is causing the site build to take forever.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>>
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [commons-parent] drop cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/29/12 9:46 AM, Oliver Heger wrote:
> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>> Hi Phil,
>>
>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>> It seems a shame to turn off this feature for ALL projects
>>>> because one
>>>> project can't figure out a workaround.
>>>
>>> Can *any* project find a workaround? Is there *any way* to turn
>>> this thing off?
>>
>> What about every project being declared in the aggregator project
>> Olivier set up in our instance of Sonar
>> <https://analysis.apache.org/components/index/121254>?
>>
>
> +1
>
> We could then even disable more reports in the components' poms
> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
> instance.
>
> This would provide comprehensive up-to-date statistics for all
> components. It would also be a step forward in making the
> components more uniform.
+1 - and as yet another bonus, it would reduce wasted infra
resources duplicating all of the images, etc on all of the
individual sites and the need to store all of that stuff in svn.
Phil
>
> Oliver
>
>> Luc
>>
>>>
>>> Phil
>>>>
>>>> Gary
>>>>
>>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com>
>>>> wrote:
>>>>
>>>>> Any objections to this? In [math] at least we can't seem to
>>>>> turn it
>>>>> off and it is causing the site build to take forever.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Phil
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Gary Gregory <ga...@gmail.com>.
Using Sonar is useless for local development. When I make changes and run a
build, I want to see all of the reports based on my local changes, not what
is in the VCS. I know we usually do CTR but this would force me to commit
to see reports in Sonar, a non-starter IMO.
Gary
On Sat, Dec 29, 2012 at 12:46 PM, Oliver Heger <oliver.heger@oliver-heger.de
> wrote:
> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>
> Hi Phil,
>>
>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>
>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>
>>>> It seems a shame to turn off this feature for ALL projects because one
>>>> project can't figure out a workaround.
>>>>
>>>
>>> Can *any* project find a workaround? Is there *any way* to turn
>>> this thing off?
>>>
>>
>> What about every project being declared in the aggregator project
>> Olivier set up in our instance of Sonar
>> <https://analysis.apache.org/**components/index/121254<https://analysis.apache.org/components/index/121254>
>> >?
>>
>>
> +1
>
> We could then even disable more reports in the components' poms (findbugs,
> pmd, checkstyle, ...) and just add a link to the Sonar instance.
>
> This would provide comprehensive up-to-date statistics for all components.
> It would also be a step forward in making the components more uniform.
>
> Oliver
>
>
> Luc
>>
>>
>>> Phil
>>>
>>>>
>>>> Gary
>>>>
>>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>> Any objections to this? In [math] at least we can't seem to turn it
>>>>> off and it is causing the site build to take forever.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Phil
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [commons-parent] drop cobertura
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 29.12.2012 09:43, schrieb Luc Maisonobe:
> Hi Phil,
>
> Le 28/12/2012 21:10, Phil Steitz a écrit :
>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>> It seems a shame to turn off this feature for ALL projects because one
>>> project can't figure out a workaround.
>>
>> Can *any* project find a workaround? Is there *any way* to turn
>> this thing off?
>
> What about every project being declared in the aggregator project
> Olivier set up in our instance of Sonar
> <https://analysis.apache.org/components/index/121254>?
>
+1
We could then even disable more reports in the components' poms
(findbugs, pmd, checkstyle, ...) and just add a link to the Sonar instance.
This would provide comprehensive up-to-date statistics for all
components. It would also be a step forward in making the components
more uniform.
Oliver
> Luc
>
>>
>> Phil
>>>
>>> Gary
>>>
>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> Any objections to this? In [math] at least we can't seem to turn it
>>>> off and it is causing the site build to take forever.
>>>>
>>>> Thanks!
>>>>
>>>> Phil
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Simone Tripodi <si...@apache.org>.
> or just move it to a profile?
+1
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Mark,
2012/12/29 Mark Struberg <st...@yahoo.de>
> or just move it to a profile?
> In our project we have this enabled via
>
> $> mvn clean instal -Pcoverage
>
> LieGrue,
> strub
>
> We've been trying to do that unsuccessfully in Commons Math. What project
are you talking about? We could look at the pom.
Thanks,
Sébastien
>
>
>
> ----- Original Message -----
> > From: Luc Maisonobe <Lu...@free.fr>
> > To: Commons Developers List <de...@commons.apache.org>
> > Cc:
> > Sent: Saturday, December 29, 2012 9:43 AM
> > Subject: Re: [commons-parent] drop cobertura
> >
> > Hi Phil,
> >
> > Le 28/12/2012 21:10, Phil Steitz a écrit :
> >> On 12/28/12 11:44 AM, Gary Gregory wrote:
> >>> It seems a shame to turn off this feature for ALL projects because one
> >>> project can't figure out a workaround.
> >>
> >> Can *any* project find a workaround? Is there *any way* to turn
> >> this thing off?
> >
> > What about every project being declared in the aggregator project
> > Olivier set up in our instance of Sonar
> > <https://analysis.apache.org/components/index/121254>?
> >
> > Luc
> >
> >>
> >> Phil
> >>>
> >>> Gary
> >>>
> >>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com>
> > wrote:
> >>>
> >>>> Any objections to this? In [math] at least we can't seem to
> > turn it
> >>>> off and it is causing the site build to take forever.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Phil
> >>>>
> >>>>
> > ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [commons-parent] drop cobertura
Posted by Mark Struberg <st...@yahoo.de>.
or just move it to a profile?
In our project we have this enabled via
$> mvn clean instal -Pcoverage
LieGrue,
strub
----- Original Message -----
> From: Luc Maisonobe <Lu...@free.fr>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Saturday, December 29, 2012 9:43 AM
> Subject: Re: [commons-parent] drop cobertura
>
> Hi Phil,
>
> Le 28/12/2012 21:10, Phil Steitz a écrit :
>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>> It seems a shame to turn off this feature for ALL projects because one
>>> project can't figure out a workaround.
>>
>> Can *any* project find a workaround? Is there *any way* to turn
>> this thing off?
>
> What about every project being declared in the aggregator project
> Olivier set up in our instance of Sonar
> <https://analysis.apache.org/components/index/121254>?
>
> Luc
>
>>
>> Phil
>>>
>>> Gary
>>>
>>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com>
> wrote:
>>>
>>>> Any objections to this? In [math] at least we can't seem to
> turn it
>>>> off and it is causing the site build to take forever.
>>>>
>>>> Thanks!
>>>>
>>>> Phil
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Phil,
Le 28/12/2012 21:10, Phil Steitz a écrit :
> On 12/28/12 11:44 AM, Gary Gregory wrote:
>> It seems a shame to turn off this feature for ALL projects because one
>> project can't figure out a workaround.
>
> Can *any* project find a workaround? Is there *any way* to turn
> this thing off?
What about every project being declared in the aggregator project
Olivier set up in our instance of Sonar
<https://analysis.apache.org/components/index/121254>?
Luc
>
> Phil
>>
>> Gary
>>
>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> Any objections to this? In [math] at least we can't seem to turn it
>>> off and it is causing the site build to take forever.
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Gary Gregory <ga...@gmail.com>.
On Dec 28, 2012, at 15:11, Phil Steitz <ph...@gmail.com> wrote:
> On 12/28/12 11:44 AM, Gary Gregory wrote:
>> It seems a shame to turn off this feature for ALL projects because one
>> project can't figure out a workaround.
>
> Can *any* project find a workaround? Is there *any way* to turn
> this thing off?
I won't be in front of my PC much until the holidays are over so I
hope someone else can help.
Gary
>
> Phil
>>
>> Gary
>>
>> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> Any objections to this? In [math] at least we can't seem to turn it
>>> off and it is causing the site build to take forever.
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/28/12 11:44 AM, Gary Gregory wrote:
> It seems a shame to turn off this feature for ALL projects because one
> project can't figure out a workaround.
Can *any* project find a workaround? Is there *any way* to turn
this thing off?
Phil
>
> Gary
>
> On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
>
>> Any objections to this? In [math] at least we can't seem to turn it
>> off and it is causing the site build to take forever.
>>
>> Thanks!
>>
>> Phil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-parent] drop cobertura
Posted by Gary Gregory <ga...@gmail.com>.
It seems a shame to turn off this feature for ALL projects because one
project can't figure out a workaround.
Gary
On Dec 28, 2012, at 12:21, Phil Steitz <ph...@gmail.com> wrote:
> Any objections to this? In [math] at least we can't seem to turn it
> off and it is causing the site build to take forever.
>
> Thanks!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org