incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Third Party Jars
Date Thu, 10 Mar 2011 11:23:47 GMT
On 2011-03-09, Jean-Louis Boudart wrote:

> 2011/3/9 Stefan Bodewig <>

>> On 2011-03-09, Jean-Louis Boudart wrote:

>>> Then come the problem of plugins. As you should know easyant a
>>> plugin based architecture. A plugin is a reusable ant script
>>> answering a given need such as "compile-java" or "package-jar". Some
>>> plugins additionnal relies on existing ant tasks such as :

>>>    - Checkstyle

>> Such a plugin cannot be distributed as ASF software since it is in
>> Categoy X - might be an option.

> Just to be sure is this kind of plugin really forbidden in ASF  ?

> I guess the plugin basically uses checkstyle ant task and require a
> given version of checkstyle as a dependency.  For example ant's
> build.xml uses checkstyle task, isn't it? The problem is probably
> about distributing checkstyle jars.

We are talking about two or three different things.

(1) using something at build time

    You can use whatever you want no matter what the license says (as
    long as you are legally allowed to run it, of course).  Be that gcc,
    Visual Studio or checkstyle.

    This is what Ant's build file does.

(2) writing code that depends on an external library

    This is a no-go for external dependencies with reciprocal licenses.
    I'm afraid the checkstyle plugin falls into this category.

(3) distributing a library

    This is OK for Category A and B but not for Category X as defined in

    This would prohibit distribution of checkstyle.jar or the checkstyle
    Ant task.

> So plugins could be released under apache licenses and specify in their
> dependencies such as :
> <dependency org="checkstyle" module="checkstyle" revision="xxx"/>

It is not possible to write a checkstyle plugin that was licensed under
any license incompatible with the LGPL - this includes the Apache
Software License.  Unless you write a task like Cobertura's Ant task
that jumps through a hoop or two in order to insulate itself from the

>>>    - Antunit
>>>    - compile-groovy (using groovy.jar)
>>>    - compile-scala (usign scala-compiler.jar)
>>>    - scm-svn (using svnant.jar)
>>>    - cobertura
>>>    - emma
>>>    - ogsi-bundle (using bnd.jar)
>>>    - jetty-deploy (using jetty.jar)

>> We'll need to review their licenses as well.

Category-A: AntUnit (obviously), Groovy, Scala, bnd, cobertura Ant tasks,
            Jetty (in case of Jetty 7+ you need to make clear you are
            using the Apache Software License as it is dual licensed).

Category-B: emma

Category-X: cobertura

I've been unable to find license information about svnant.  If it is
under the same license as Subclipse (EPL 1.0) it is in Category B.

Cobertura seems to go a long way to make the Ant task Apache licensed,
so a plugin using Cobertura's Ant task is OK as is distributing the
Cobertura Ant tasks, but distributing the dependencies of the Ant task
is not.


View raw message