incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>
Subject Re: code coverage and sonar integration
Date Wed, 04 Jul 2012 20:25:03 GMT
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 <Janne.Jalkanen@ecyrd.com>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" <juanpablo.santos@gmail.com>
> > An: jspwiki-dev@incubator.apache.org
> > 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 <
> janne.jalkanen@ecyrd.com>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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message