Re: [commons-parent] drop cobertura
On Sat, Dec 29, 2012 at 8:21 PM, Phil Steitz phil.ste...@gmail.com wrote: 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? 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. 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 - 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
Re: [commons-parent] drop cobertura
We should just move the non-development stuff (stuff that we'll run in a CI environment, though) into a profile. On Sat, Dec 29, 2012 at 7:28 PM, Olivier Lamy ol...@apache.org wrote: 2012/12/29 Oliver Heger oliver.he...@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.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
Re: [commons-parent] drop cobertura
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 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
Re: [commons-parent] drop cobertura
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? 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
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 luc.maison...@free.fr To: Commons Developers List dev@commons.apache.org Cc: Sent: Saturday, December 29, 2012 9:43 AM Subject: Re: [commons-parent] drop cobertura 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? 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
Re: [commons-parent] drop cobertura
Hi Mark, 2012/12/29 Mark Struberg strub...@yahoo.de or just move it to a profile? In our project we have this enabled via $ mvn clean instal -Pcoverage LieGrue, strub We've been trying to do that unsuccessfully in Commons Math. What project are you talking about? We could look at the pom. Thanks, Sébastien - Original Message - From: Luc Maisonobe luc.maison...@free.fr To: Commons Developers List dev@commons.apache.org Cc: Sent: Saturday, December 29, 2012 9:43 AM Subject: Re: [commons-parent] drop cobertura 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? 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
Re: [commons-parent] drop cobertura
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.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-parent] drop cobertura
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. 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
Re: [commons-parent] drop cobertura
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
Re: [commons-parent] drop cobertura
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 at 12:46 PM, Oliver Heger oliver.he...@oliver-heger.de 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/121254https://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. 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-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [commons-parent] drop cobertura
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 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
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
Re: [commons-parent] drop cobertura
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.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
Re: [commons-parent] drop cobertura
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? 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
Re: [commons-parent] drop cobertura
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
Re: [commons-parent] drop cobertura
2012/12/29 Oliver Heger oliver.he...@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.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-parent] drop cobertura
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
Re: [commons-parent] drop cobertura
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 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
Re: [commons-parent] drop cobertura
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 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
Re: [commons-parent] drop cobertura
On Dec 28, 2012, at 15:11, Phil Steitz phil.ste...@gmail.com 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 won't be in front of my PC much until the holidays are over so I hope someone else can help. Gary 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
