commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [commons-parent] drop cobertura
Date Sat, 29 Dec 2012 18:44:02 GMT
> 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 <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


Mime
View raw message