On 2026-08-09, Jaikiran Pai wrote:
> On 26/07/26 12:35 pm, Stefan Bodewig wrote:
>> On 2026-07-25, Emmanuel Bourg wrote:
>>> Mixing the date and the reproducible status in the same return value
>>> doesn't look great. What about adding a isReproducibleBuild() method
>>> instead? I don't know where it would fit the best though, DateUtils
>>> doesn't look right. Maybe in Project?
>> If we add it separately then Project is the logical choice to me as
>> well.
> I had a look at the new DateUtils.getNow(Project) method and the new
> public field ENV_SOURCE_DATE_EPOCH. I think the new public field on
> DateUtils is fine and a natural place for that field. As for the new
> method, I agree with Emmanuel that its return type might need to be
> changed to just return a Date. Furthermore, like you note, I think it
> might be better to move this getNow() method as an instance method to
> the Project class, something like:
> public Date getNow() {
> ...
Fine with me.
> As for whether the callers need to know whether SOURCE_DATE_EPOCH
> environment variable value was used for determining the return value,
I was using this is a signal to say "I want reproducible builds" which
we don't really use in Ant so far, so I can defer that until after the
release. In the case of <propertyfile> and the CycloneDX Antlib I'll
explicitly check for the environment variable right now as you suggest.
> I think the current javadoc (which would be moved to this new method)
> has clear text on what environment variable and magic properties are
> used, and in which order, to determine this value. I think it will be
> rare for callers to additionally require to know which of the
> environment variable or magic property was used, and if they do, then
> it's straightforward for them to do a
> System.getenv(DateUtils.ENV_SOURCE_DATE_EPOCH) or
> Project.getProperty(MagicNames...) to find it out themselves. So I
> think we don't need any new additional API or return type to tell
> callers whether the SOURCE_DATE_EPOCH environment variable was used.
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
