commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [commons-parent] drop cobertura
Date Sat, 29 Dec 2012 20:50:50 GMT
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 <phil.steitz@gmail.com>
>>> To: Commons Developers List <dev@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 <phil.steitz@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
>>> <phil.steitz@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


Mime
View raw message