commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: [commons-parent] drop cobertura
Date Sun, 30 Dec 2012 00:28:06 GMT
2012/12/29 Oliver Heger <oliver.heger@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 <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
>



--
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


Mime
View raw message