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
>>
>>
>> -
ry 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 bui
>>> build-aggregator pom which just contains the .
>>
>>
>> Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
>>
>> Phil
>>>
>>>
>>>
>>> - Original Message -
>>>>
>>>> From
-aggregator pom
which just contains the .
Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
Phil
- Original Message -
From: Phil Steitz
To: Commons Developers List
Cc:
Sent: Saturday, December 29, 2012 7:29 PM
Subject: Re: [commons-parent] drop cobertura
On 12/29
his can be done much cleaner in having an own
> build-aggregator pom which just contains the .
Agreed. I wonder if anyone ever uses this. I would be +1 to drop.
Phil
>
>
> - Original Message -
>> From: Phil Steitz
>> To: Commons Developers List
>> Cc:
>>
r 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
>> o
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.
T
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 Steit
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
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 figur
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 the
> 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-unsubscr...@commons.a
ing about? We could look at the pom.
Thanks,
Sébastien
>
>
>
> - Original Message -
> > From: Luc Maisonobe
> > To: Commons Developers List
> > Cc:
> > Sent: Saturday, December 29, 2012 9:43 AM
> > Subject: Re: [commons-parent] drop cobertura
> >
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
> To: Commons Developers List
> Cc:
> Sent: Saturday, December 29, 2012 9:43 AM
> Subject: Re: [co
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
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 unsubscr
On Dec 28, 2012, at 15:11, Phil Steitz 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 w
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 wr
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 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.
>
> Tha
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-unsubscr...@commons.apache.org
For additional commands, e-mail
20 matches
Mail list logo
