incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Date Tue, 03 Apr 2012 15:29:13 GMT

Le 20 mars 2012 à 14:51, Jean-Louis Boudart a écrit :

> Fresh news, i've almost stabilized the version and recently commited it.
> All plugins, buildtypes,  and core have been updated to remove phases.

good !

> Currently the build is broken on jenkins as trunk requires the most recent
> plugins [1].

This raise me some concerns about the "buildability" of easyant. How it is expected to be
build ? This has consequence of the way we will release it (releasing source without being
able to build has obviously no sense :) ).

> 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

I think it would be a nice to have but not a priority, the Groovy front is yet a proof of

>   - 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
> project.
> 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.

No objection.

What about backward compatibility ?
I am totally fine with breaking it. For now. Until we are satisfied with the general architecture
of Easyant. To me the last point is about the plugin dependency you wrote about.


View raw message