You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Juan Pablo Santos Rodríguez <ju...@gmail.com> on 2012/06/27 00:11:44 UTC
code coverage and sonar integration
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
Re: code coverage and sonar integration
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi,
I agree that there's room for improvement regarding the build. But I don't
think that is matter of the build system though, it's just that the build
as it is, is complex: the build script takes care not only of compiling and
building the main war, but also does unit testing, precompiles JSPs,
generates digital certificates, javadocs, templates for i18n, starts &
stops an embedded database, etc. The build script is 1500+ lines long
(maybe it could/should be splitted into several files) but that's because
it does a lot of things.
Having said that, I feel that Ant alone is not enough, mainly because it
doesn't take care of the dependency management. I think that Ivy would be
the less disruptive / more conservative approach here (we could set up some
Ant tasks to download the needed jars, but Ivy seems to me a more standard
approach). That would allow us, i.e., to bring in Sonar integration, which
is a tool that helps *a lot* (in our case, specially Sonar's "Design" and
"Clouds" sections), code coverage, generate javadocs with UML diagrams, we
could use LGPL or GPL testing tools, etc.
Regarding alternative build systems: IMO, the best way to simplify the
build would be to modularize it (being module == jar, like
jspwiki-filters.jar, jspwiki-plugins.jar, jspwiki-core.jar, etc). Having an
equivalent one-module maven build would end up with a more or less +1500
line build script with the same 432 classes, which is more or less the
current situation. I suspect that probably the same will happen if going
with a one-module Gradle build. Also, modularizing the build will most
probably go paired with some refactor, so I think this should be scoped for
2.10 (or 2.9.1 or 2.9.2).
Don't know about Gradle, but I think that here Maven would really shine
(disclaimer: been working with Maven for the last ~4 years, so I'm really
fond of it). Maven is mainly about conventions, dependency management and
relating modules one to another, which is basically what we would be doing
here. I recall emails on this list with no so positive opinions on Maven,
so I could just start a maven branch just to see how the refactor could
look and, on that, ask here for opinions about it, but first I'd prefer to
add the Ivy + Cobertura + Sonar support, I think they would add value in
the short term.
Finally, as I've said, I don't know Gradle, but if we decide it should our
build tool, it would be fine for me to learn it. So, from my ignorance and
the fact that is nearly 2.00am in here: how does Gradle tackle these
concerns? (I'll add to my to-do list to take a look at it in the next
days..)
rgrds,
jp
On Wed, Jun 27, 2012 at 11:33 AM, Florian Holeczek <fl...@holeczek.de>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" <ju...@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
> >
> >
>
Re: code coverage and sonar integration
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <Ja...@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" <ju...@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
> >>
> >>
>
>
Re: code coverage and sonar integration
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
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" <ju...@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 <ja...@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
>>
>>
Re: code coverage and sonar integration
Posted by Florian Holeczek <fl...@holeczek.de>.
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" <ju...@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 <ja...@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
>
>
Re: code coverage and sonar integration
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <ja...@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
>
>
Re: code coverage and sonar integration
Posted by Janne Jalkanen <ja...@ecyrd.com>.
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