Things to do before the next Ant release?!

[Stefan Bodewig <bo...@apache.org>]

Hi all

we planned to cut a new release of Ant soonish in order to help out the
people who use JVMs by Microsoft that all released versions of Ant
identify as an ancient JVM which needs special handling that breaks
things today.

I've got two things I want to get resolved one way or the other that
I've raised in threads over the past two weeks or so:

* Is my change to DateUtils#getNow fine as it is or should I separate
  the "override the notion of now" and "we want reproducible build"
  questions? If we opt for the latter, what should be the signal, is it
  the presence of SOURCE_DATE_EPOCH (as in getNow) or something else?
  And what should be "now" if it is something else?

* For Antlibs I really want to have a way for an Antlib to extend the
  classloader used by another Antlib. This basically is a requirement
  for Antlibs depending on Ivy that you want to load via Ivy. I'm fine
  with allowing typedef/taskdef to get a new parentLoaderRef for this
  (which would require writing some code, but much of it already exists)
  - or with documenting the classloader task that has been there for a
  long time (and is the reason much of the code for the former option
  already exists :-).

I'm completely neutral on both topics.

Is there anything else anybody is working on? Any issue we should
resolve upfront? Right now I assume that PRs that have been open for
years are not blocking as they've not blocked past releases either :-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Things to do before the next Ant release?!

[Jaikiran Pai <ja...@apache.org>]

On 08/08/26 4:02 pm, Stefan Bodewig wrote:
> ...
>
> Is there anything else anybody is working on? Any issue we should
> resolve upfront? Right now I assume that PRs that have been open for
> years are not blocking as they've not blocked past releases either :-)
I don't have anything planned nor am I working on anything that would be 
necessary in the next release :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Things to do before the next Ant release?!

[Stefan Bodewig <bo...@apache.org>]

On 2026-08-11, Emmanuel Bourg wrote:

> Thinking further about it, instead of DateUtils.getNow() I'd suggest
> adding a Project.getBuildDate() or Project.getDate() method. That
> looks more natural and clearly communicates what the date
> represents. Also the fact that getNow() returns a date that is not now
> is a bit counterintuitive.

True. I'd opt for getBuildDate.

> Regarding Project.isReproducibleBuild(), I’m not sure it's needed. One
> could argue that builds should always be reproducible by default, so
> there shouldn't be a strong use case for querying that state
> explicitly.

I've got such a case in the CycloneDX Antlib. The CycloneDX
specification is explicitly designed to create non-reproducible SBOMs
(the serial number is expected to change with every creation even if all
other content stays the same[1]). Right now (i.e. in the git main
branch) I only "break" the spec if the user explicitly asks for it.

Stefan

[1] https://cyclonedx.org/docs/1.7/json/#serialNumber - I just see I
could completely skip it and conform to the spec, but I'm not sure tools
really treat it as optional.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Things to do before the next Ant release?!

[Emmanuel Bourg <eb...@apache.org>]

Hi Stefan,

Le 08/08/2026 à 12:32, Stefan Bodewig a écrit :

> * Is my change to DateUtils#getNow fine as it is or should I separate
>   the "override the notion of now" and "we want reproducible build"
>   questions? If we opt for the latter, what should be the signal, is it
>   the presence of SOURCE_DATE_EPOCH (as in getNow) or something else?
>   And what should be "now" if it is something else?

Thinking further about it, instead of DateUtils.getNow() I'd suggest 
adding a Project.getBuildDate() or Project.getDate() method. That looks 
more natural and clearly communicates what the date represents. Also the 
fact that getNow() returns a date that is not now is a bit counterintuitive.

Regarding Project.isReproducibleBuild(), I’m not sure it's needed. One 
could argue that builds should always be reproducible by default, so 
there shouldn't be a strong use case for querying that state explicitly.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org