On 2018-02-05, Gintautas Grigelionis wrote:
> I adjusted the proposal and I hope that I addressed your criticism.
Unfortunately it doesn't.
I'm afraid that we would be sending a wrong signal here. On top of that
I don't think Ant would actually work if parts of it are used as
modules. We use classloaders and Class.forName all over the place, not
ServiceLoader, for example.
If the taskdef/typedef implementation classes are loaded via a module
path and a custom task lives on the CLASSPATH will taskdef be able to
load it at all?
Without really having tried a setup of some of our jars coming from a
module loader and the rest living on a CLASSPATH and trying out all the
different scenarios of custom tasks/types/loggers, taking into account
classes that do something like
public void add(SomeInterface foo) { ,,, }
in order to allow any typedeffed implementation of the interface to be
used as a nested child element and all the other edge cases, I wouldn't
want to send the slightest signal that Ant was supporting the module
system in any way. It simply has been designed for a classloader world
and heavily relies on it.
As for moving classes and adding stubs for backwards compatibility -
let's please evaluate what we'd gain with such a move.
Ant is used as a code dependency by way more things than we know. We do
know Gradle and SBT directly call into Ant classes under the
covers. Lots and lots of custom tasks have been written that rely on our
API. If you use some kind of Maven antrun construct then moving classes
around and adding a new jar means you have to add a new dependency when
you want to upgrade to a new version. This is inconvenient and may turn
out to cause difficult to diagnose problems.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
