incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Third Party Jars
Date Wed, 09 Mar 2011 09:30:01 GMT

Le 9 mars 2011 à 08:31, Jean-Louis Boudart a écrit :

> 2011/3/9 Stefan Bodewig <>
>> On 2011-03-09, Jean-Louis Boudart wrote:
>>> I'll try to clarify some points.
>> Thank you.
>>> EasyAnt core it self depends on Apache Ant, Apache Ivy and antcontrib.
>>> Those dependencies came from repository/third-party-lib for conveniance.
>>> 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.

I'll comment to be more precise of what it means regarding releasing and licensing:

> To resolve plugins and their dependecies we rely on Apache Ivy. So we can
> have multiple repository.
> My idea would be to have at least 3 repository :
> one local shipped in easyant distribution and storing core plugins
> (compile-java, package-jar, etc...)

This repository will be developed by us, mainly some build.xml files, shipped in the tgz of
easyant which would be on

> one official public repository ideally hosted @apache (hosting all easyant
> plugins)

the plugins will be developed by us too, this will mainly be some build.xml files too. I'm
not sure yet where we will release it, I'm not sure apache dist is meant for that.

> and maven public repository (where easyant will fetch plugin dependencies)

Plugin dependencies are basically third party jars and we will hopefully find everything we
want on third party repositories. So we will only have pointers to these third party repositories.

> So plugins could be released under apache licenses and specify in their
> dependencies such as :
> <dependency org="checkstyle" module="checkstyle" revision="xxx"/>
> Plugin dependencies will then be downloaded on the fly at runtime if end
> users use this kind of plugins.
> What do you think ?



>>>   - 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.
>>> Like i mentioned in an other thread, between 0.7 and 0.8 there was
> around 6
>>> month, this was mostly due to new additionnal  plugin (maven-publication
> for
>>> example). Those additionnal plugin should not "lock" the release. Having
> an
>>> online repository should allow us to make release of plugins
> independently
>>> of easyant core (except if a plugin needs to use a recent feature of
>>> easyant-core).
>> Having different release cycles for core and plugins seems to be a good
>> idea.
> Then, we need to clarify how we could host plugins in a public repository. I
> ll open a thread on this.
> -- 
> Jean Louis Boudart
> Independent consultant
> Project Lead

View raw message