incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Dependency management of the easyant plugins
Date Fri, 22 Apr 2011 11:43:12 GMT
I would like to discuss the way the plugins are declaring the dependencies with each other.

In easyant 0.8, there was some easyant include. Since it is an include and not an import,
each plugin is somehow embedding its dependencies at runtime without directly exposing them
to the plugins which are dependencies of it. So if two plugins wants to share some targets,
they shouldn't declare these dependencies, it would be the responsibility to the one which
includes them both to also include the plugin in common.

In the refactoring of EASYANT-27 [1], I changed the includes with imports so there is no transitive
issue about using extension point. Using extension point is kind of different of phases since
the dependencies between targets are now explicit. Phases were the workflow every plugins
was relying on. Now each plugin expose its points of extension, so each plugins is actually
relying on each other. So include was not possible.
I hope this is OK for everyone ?

Then I would like to go further. Because each plugin manage its own dependency, each import
is an Ivy resolve behind the hood, there is not much dependency management of the plugins.
Ivy is here barely used more than just downloading build files. There is no transitive dependency
or conflict management.
For instance:
* build-std-java imports compile-java and ivy-provisioning
* compile-java imports ivy-provisioning
In this example, ivy-provisioning is resolved two times, and it is possible that the two resolved
versions are not the same.

I then suggest to move to a real dependency management of the plugins, by really using Ivy.
Each plugin rather than importing himself its dependencies, it would just declares them. As
a proof of concept, I implemented an Ant task that just does that. See the "experiment" folder
I have just committed to test it.
To run the sample, put the jars of both easyant and ivy into sample/ea-jars.
Two special ant properties controls the task behaviour:
* easyant.refresh : set it to true to force a resolve. Otherwise the last resolve report will
be used
* easyant.localrepo.basedir : set folder in which the scripts are retrieved, useful for embedding
the build. If not set, the scripts are imported directly from the cache.

As you could see the plugin dependencies are nicely resolved. So nicely that a script can
have dependencies reusable in the script itself. See the script of org.apache.easyant#groovyfrontend.
The classpath to find the project helper is computed by Ivy from the ivy.xml of the plugin.

WDYT of the idea ?

Nicolas


Mime
View raw message