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.ste...@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.ste...@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.ste...@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-unsubscr...@commons.apache.org
For additional commands, e-mail:
dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
