ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <jeanlouis.boud...@gmail.com>
Subject Easyant - Plugin conflict management
Date Sat, 03 Aug 2013 11:33:03 GMT
Hi there,

It becomes necesssary to manage conflicts between plugins.
This issues has been raised many time and is referenced on jira[1].

Currently easyant offers import task taking some specific attributes to
resolve a plugin (mainly organisation, module name and revision).
<ea:import org="mycompany" module="myplugin" revision="x.x"/>

This task will :
 * resolve the given plugin or buildtypr
 * create a dynamic classpath for this plugin
 * expose location of others extra files through properties (ex
checkstyle.xml containing checkstyle rules, this files is shipped in the
plugin). Thoses properties will then be reused by the plugin itself
 * import the real ant file (invoke the importTask from ant core under the
hood)

This task is currently used :
 * dynamically by easyant to load system plugins (skeletons for example)
 * dynamically by easyant when you specify <ea:build> or <ea:plugin> tags
in module.ivy files
 * invoked in plugin ant file itselfs
 * invoked in module.ant if users has complex needs

Additionnal there is two "alliases" for this task to import plugins and
buildtype.
<ea:plugin module="compile-java" revision="0.9"/>
<ea:plugin module="build-std-java" revision="0.9"/>
If organisation attribute is not specified on aliases  default one will be
used.

It does the job but it doesn't handle conflict between plugins.

Some plugins relies on abstract ones.
Exemple:
package-jar depends on abstract-package, abstract-package depends on
abstract-compile, but compile-java plugin also depends on abstract-compile.
Which versi of abstract-compile will be taken in case both plugins load
different version ? The answer is the first one !
This becomes more problematic on buildtypes, as buildtypes loads a set of
plugins (including themself others abstract-plugins).

Ok so now you should have a quick picture of the problem.

What could be done  ?

We can rely on ivy to describe dependency on plugins. But then how could we
know in which order plugins should be loaded ?

I suggest to introduce a deferred import mechanism.

We should split responsibility in two distinct steps.
1 - resolve (based on ivy) the whole graph of plugins and store the resolve
report somewhere as a reusable reference in ant project
2 - invoke a new import task should import already resolved plugins (the
task could rely on the report stored as a reference in ant project)

Exemple :
compile java will have an ivy dependency on abstract-compile
<dependency org="org.apache.easyant.plugins" module="abstract-compile"
revision="1.0"/>

The compile java ant script will import the resolved plugin
<ea:import-deferred org="org.apache.easyant.plugins"
module="abstract-compile"/>

Note that i'm not fixed yet with the task name. Any suggestion (even for
alliases are welcome).

To maintain backward compatibility i'm in favor of creating new aliases
"import-plugin" and "import-buildtype" instead of reusing existing ones.

People would be able to continue using existing task with known the
limitation (no conflict management on plugins).
This can help if someone wants to load plugins in module.ant after setting
a few properties.

I also recommend adding a warning on existing task to recommend people
using the new import mechanism.

What do you think ?ea

[1] https://issues.apache.org/jira/browse/EASYANT-13
-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/

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