Re: [commons-parent] drop cobertura

[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