Hi, just committed it a few moments ago:
ant [clean] coverage-reports generates cobertura reports in ./tests/build/cobertura ant [clean] sonar to connect to a default sonar installation (i.e., running at localhost:9000, using derby database) non AL-dependencies are downloaded via maven-ant-tasks to ./tests/build/libs-opt br, juan pablo On Thu, Jun 28, 2012 at 7:59 PM, Janne Jalkanen <[email protected]>wrote: > > What we're pretty successfully doing right now at my current work is that > we use Maven for dependency management (and Eclipse integration), but Ant > for scripting, building, etc. We just dumped Ivy because it's hard to > configure correctly and has inferior IDE integration. > > Check out ant-maven-tasks; it's pretty useful. > > /Janne > > On Jun 27, 2012, at 12:33 , Florian Holeczek wrote: > > > Hi Juan Pablo and Janne, > > > > improving our build management is something I've had in mind for a long > time already. Just having a look at the output of some Ant visualization > tool is demonstrating that there is much room for improvement :-) > > I remember a discussion with Janne on this. He wasn't really in favour > of Maven, and, after I've personally seen some not that huge project > suffering from Maven's complexity, I tend to share his opinion. > > IMO, JSPWiki has definitely grown too big for Ant, but it's ways too > small for Maven. I think Ivy might be a small partial improvement regarding > dependency management, but the most promising candidate to me is Gradle [1]. > > Heard of it already? WDYT? > > > > Regards > > Florian > > > > [1] http://www.gradle.org/ > > > > > > ----- Ursprüngliche Mail ----- > > Von: "Juan Pablo Santos Rodríguez" <[email protected]> > > An: [email protected] > > Gesendet: Mittwoch, 27. Juni 2012 10:49:37 > > Betreff: Re: code coverage and sonar integration > > > > hmmm.., then I'd rather go adding Ivy support to manage all dependencies > > (or even to a maven-based build). Will begin on this as soon as I can. > Thx > > for the info on this :-) > > > > > > regards, > > jp > > > > On Wed, Jun 27, 2012 at 9:18 AM, Janne Jalkanen < > [email protected]>wrote: > > > >> > >> Nope. > >> > >> But what you can do is to make an ant task which downloads Cobertura and > >> the relevant JARs when you run "ant coverage-tests" or whatever. > >> > >> /Janne > >> > >> On 27 Jun 2012, at 01:11, Juan Pablo Santos Rodríguez wrote: > >> > >>> Hi again, > >>> > >>> I was curious and have added the needed jars and the related ant task > to > >>> see how JSPWiki is performing in terms of test coverage. I was about to > >>> commit the changes, but I'm not very sure if we can commit the > Cobertura > >>> jar, as it is not clear to me if their license is AL-compatible or not > >> (by > >>> the way, if anybody is curious, I've uploaded the reports to [1]). > >>> > >>> Cobertura ant tasks are AL-licensed [2], but cobertura.jar contains > both > >>> ant-tasks and Cobertura itself, which is GPL. Is it OK to commit this > jar > >>> in tests/lib? Regarding asm-3.0.jar and asm-tree-3.0.jar, they seem OK > >> [3]. > >>> > >>> Also, following up with the coverage reports, I've also made the > >> appropiate > >>> task to let Sonar gather some statistics from JSPWiki. The point is, > >> Sonar > >>> is LGPL'ed, which means we can't add the Sonar ant tasks to the > project, > >>> so, does it make sense to commit these build.xml changes? As I have > them > >>> now, they assume that the Sonar ant tasks are placed inside > $ANT_HOME/lib > >>> > >>> > >>> regards, > >>> juan pablo > >>> > >>> > >>> [1]: http://people.apache.org/~juanpablo/coverage_2.9.0-incubating-3 > >>> [2]: http://cobertura.sourceforge.net/license.html > >>> [3]: http://asm.ow2.org/license.html > >> > >> > >
