incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <>
Subject Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Date Tue, 20 Mar 2012 13:51:31 GMT
Fresh news, i've almost stabilized the version and recently commited it.
All plugins, buildtypes,  and core have been updated to remove phases.
Currently the build is broken on jenkins as trunk requires the most recent
plugins [1].

What are the next steps before the release ?

   - Update the documentation to remove phases

   - Update plugin tutorial to explain how  you can write plugins using
   groovy (groovyfront) instead of XML

   - Create a short lifecycle to share common high level targets for end
   users such as compile, package, test (ideally a diagram of this short
   lifecycle on the documentation could be great)

   - Update the main class to display those high level target when invoking
   project help (easyant -p)

We recently made some experimentation to enhance conflict and dependency
management between plugins.
For the details we've changed two things :

   - We've introduced a second easyant's import task[2] which is aware of
   all plugins dependencies and can deal with conflict. Tthis task is
   considered as experimental. By default we use the old implementation for
   the moment.
   - We tried to limit target duplication by enforcing all plugins to use
   "import" instead of "include"[3].

For the first point, I suggest to continue in this way on the next release.
We've spend too much time without releasing and we need to reactivate the

I'm personnaly not satisfied by the second point for many reasons :

   - We initially made this change to avoid dupplication of
   "abstract-module" targets (like abstract-test-module). As we have no strong
   dependency management on plugins, when a someone use two test plugins for
   example (say junit and antunit) and both included abstract-test, you gets
   some side effects. All targets of this abstract modules gets dupplicated
   with two distinct prefix one for junit one for antunit. This is probably
   the only one case where moving from "include" to import" can make sense.
   Otherwise it does not answer fully our initial problem.
   - If we continue enhancing the conflict and dependency management on
   import task we will be able to solve the problem at resolution time
   - Targets are not prefixed ! Since the begining all plugins are
   "include"d with  a prefix, and all targets gets it. Exemple in javadoc
   plugin the target ":javadoc" is by default prefixed by the plugin name. As
   a end user you will call javadoc:javadoc. If we choose to use "import"
   mechanism instead of "include" will not have any prefix by default. This
   means when writting plugins you will need to manually put your own prefix
   on each target and cross the finger that no one has the same target name.
   This sounds terribly error prone for me and i really want to find a
   solution before the release. Any idea ?

IMHO, we should get back to include as it was before and put all our effort
on the new easyant's import task.

Note that ant-core 1.8.x seems to be buggy when using "include" and
extensionPoints. Though this can be patched if we all agree to go in this



[3] see the "How is <import>
different from <include>?" section

2012/1/17 Jean-Louis Boudart <>

> Changes in the code itself should be commited at the end of the week. And
> i will probably write a blog entry about this.
> Then to finalize the release the documentation needs to be updated and i
> don't know yet how many time will be required to update it.
> 2012/1/17 <>
> It's a very good news.
>> Have you got a date for the change between phase and extension point.
>> I think it is very important for users to have news on the site and a new
>> release.
>> Sbert.
>> Envoyé depuis mon HTC
>> ----- Reply message -----
>> De : "Jean-Louis Boudart" <>
>> Pour : <>
>> Objet : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012
>> ([ppmc]))
>> Date : lun., janv. 16, 2012 11:18
>> Hi,
>> Sorry for the delay i've not been available as  much as expected those
>> last
>> months.
>> I'll be more available at the end of the week i think and i plan to finish
>> and commit the refactoring of phases.
>> As you pointed out we're in Apache Incubator since one year and we still
>> have not achieved our objectives.
>> I assume the main problem comes from our huge refactoring due to one of
>> the
>> core developper who didn't sign the CLA. As a consequence we've removed
>> lot
>> of features which were part of easyant (plugin documentation, some
>> plugins,
>> etc..). It probably affects a bit the motivation of others, at least it is
>> my case, reimplementing stuff is not so fun (removing it either cc Nicolas
>> :p).
>> I still believe Apache is the place to be for EasyAnt i still plan to make
>> this project live and to create interaction with Ant and Ivy community.
>> To release the next version we need to finish our refactoring on phases
>> and
>> update documentation (including plugins). Then i propose for a n+1release
>> (probably the 1.0) to provide a way to  test plugins and to generate
>> documentation for plugins.
>> Cheers,
>> Le 9 janvier 2012 14:39, Nicolas Lalevée <> a
>> écrit :
>> >
>> > Le 6 janv. 2012 à 07:35, Stefan Bodewig a écrit :
>> >
>> > > Agreed, this needs to be done, but do we have any timeframe by which
>> > > this will be done or by which we call incubation failed?  To some
>> degree
>> > > I'm playing devil's advocate here, but eternal incubation is not an
>> > > option.
>> >
>> > I am starting to think it quite loud so I'll write it. If there is no
>> much
>> > progress until the next report, 3 month from now, I'm thinking that we
>> > shouldn't bother Apache any longer. It would make a little more than one
>> > year of incubation. "One year" is a period mentioned on the
>> > incubator-general when there was a discussion about how long a podling
>> > should last. It was just a discussion there, not official, podling can
>> last
>> > longer, but I think this is a good period length for podling to ask
>> > themself if they are not wasting ASF resources.
>> > And guys, it absolutely doesn't mean EasyAnt would be dead, it will just
>> > mean it is not enough active to demonstrate proper integration into the
>> > ASF. It can properly live back on
>> >
>> > Nicolas
>> >
>> >
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter

Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter

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