ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: ant git commit: Generate manifest files and add automatic module names for JPMS
Date Wed, 07 Feb 2018 11:51:38 GMT
2018-02-07 11:44 GMT+01:00 Stefan Bodewig <>:

> On 2018-02-06, Gintautas Grigelionis wrote:
> > 2018-02-06 11:05 GMT+01:00 Stefan Bodewig <>:
> >> 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?
> > Anything on the CLASSPATH is in the unnamed module.
> I know. :-)
> > The worst that can happen is the situation where a package split between
> > module path and classpath.
> > That's what --patch-module is for.
> Or where a custom task lives inside of a module itself and you need to
> add an import to that module to Ant. How do you enforce that from inside
> the build file where the taskdef is written? Do you tell users of your
> task to always start with ANT_OPTS=... or provide a wrapper script?

Well, that's the kind of situation that a modularised Ant would address.
My starting question is "what would happen if (parts of) Ant were moved to
the module path?"

All I'm saying is that we need to try out a bunch of use cases to see
> what works and what doesn't. What users could expect of a modularized
> version of Ant and what exactly the benefit for users is going to be.
> Personally I don't expect the "good old classpath world" to disappear
> any time soon, but I've been wrong so many times ...
> > Modules is the way to take back control.
> Of the JDK. I really don't believe it helps writers of build tools in
> any way :-)

I'm tending to give JPMS a benefit of doubt :-)

> My fear is that if the classpath world stops working then a completely
> different version of Ant will be required. A version that has to break
> backwards compatibility in many ways. I'd appreciate anybody trying to
> assess what would need to change in a pure module world, I know I cannot
> be the one.
> Ant plays well with the modularized JDK, we verified that in late 2016
> before the rules were relaxed in Java9. Turning Ant into a "modular"
> application in the sense of Java9 modules is a completely different can
> of worms.

 I'd like to peek into that can... would you be willing to revise a
proposal of
 what classes could be moved around and/or deprecated to start with?


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