Hey Mark,
bnd is in ramp down phase targetting a release in Feb so if you do find an
issue soon-ish we can work to get it in the release.
Ray
On Wed, Jan 26, 2022 at 4:05 AM Mark Thomas wrote:
> I have made some progress on this over the last few days. The current
> status is:
>
> - Builds are
I have made some progress on this over the last few days. The current
status is:
- Builds are reproducible (excluding signing of Windows binaries) when
using the same OS / Java / Ant combination.
- JSign gives us what we need to handling the signing of the Windows
binaries. "Just" need to i
On 24/01/2022 11:50, Rainer Jung wrote:
I had a little nag about ant.tstamp.now.iso mailed on January 20th.
Thanks. Fixed.
I switched from ant.tstamp.now.iso to ant.tstamp.now shortly after
adding the property but missed a couple of references in that switch.
Should be OK now.
Mark
Cop
I had a little nag about ant.tstamp.now.iso mailed on January 20th.
Copying here:
Am 15.01.2022 um 12:56 schrieb ma...@apache.org:
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/to
On 21/01/2022 17:11, Christopher Schultz wrote:
Maybe patch ant to work differently?
I agree, that is the longer term fix. I'm not too familiar with the Ant
code but I didn't see a simple way to fix it.
At the moment the short-term fix of renaming or deleting stuff seems to
be working. I
Mark,
On 1/20/22 17:56, Mark Thomas wrote:
On 20/01/2022 11:02, Mark Thomas wrote:
On 19/01/2022 16:56, Rémy Maucherat wrote:
On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg
wrote:
Fortunately a non-reproducible javadoc isn't really important, what
matters the most is to have reproducible exe
On Thu, Jan 20, 2022 at 11:57 PM Mark Thomas wrote:
>
> On 20/01/2022 11:02, Mark Thomas wrote:
> > On 19/01/2022 16:56, Rémy Maucherat wrote:
> >> On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg wrote:
> >>> Fortunately a non-reproducible javadoc isn't really important, what
> >>> matters the mos
On 20/01/2022 11:02, Mark Thomas wrote:
On 19/01/2022 16:56, Rémy Maucherat wrote:
On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg wrote:
Fortunately a non-reproducible javadoc isn't really important, what
matters the most is to have reproducible executable packages.
That seems like a reasona
On 19/01/2022 16:56, Rémy Maucherat wrote:
On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg wrote:
Fortunately a non-reproducible javadoc isn't really important, what
matters the most is to have reproducible executable packages.
That seems like a reasonable statement !
Ack. I'll look at the J
On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg wrote:
> Fortunately a non-reproducible javadoc isn't really important, what
> matters the most is to have reproducible executable packages.
That seems like a reasonable statement !
Rémy
-
Le 18/01/2022 à 21:03, Mark Thomas a écrit :
I'm wondering about second issue. It would be nice to have a complete
fix but if the full docs package isn't reproducible how much of an issue
is that?
Reproducibility issues with javadoc are quite frequent unfortunately,
many Java packages in Deb
On 19/01/2022 07:47, Romain Manni-Bucau wrote:
Hi Mark,
It is possible to use jdk.javadoc/jdk.compiler as libs and plug in through
the Context class forcing a JavaFileManager to force a DocFileFactory in
the HtmlConfiguration but it will be way more complex than
unzipping/rezipping the jar.
Ni
Hi Mark,
It is possible to use jdk.javadoc/jdk.compiler as libs and plug in through
the Context class forcing a JavaFileManager to force a DocFileFactory in
the HtmlConfiguration but it will be way more complex than
unzipping/rezipping the jar.
Another option can be a light javaagent patching the
Mark,
On 1/18/22 15:03, Mark Thomas wrote:
On 18/01/2022 19:39, Mark Thomas wrote:
The first issue looks relatively simple to fix. I don't see an easy
fix for the second. My best idea so far is some sort of
post-processing for the Javadoc generation that extracts the file from
the zip, set
On 18/01/2022 19:39, Mark Thomas wrote:
The first issue looks relatively simple to fix. I don't see an easy fix
for the second. My best idea so far is some sort of post-processing for
the Javadoc generation that extracts the file from the zip, sets the
timestamp and then re-zips it. Suggesti
Hi all,
I've been looking at reproducible builds and my research so far
indicates we have the following issues to solve:
1. ObjectReflectionPropertyInspector is not generating consistent code
for XReflectionIntrospectionUtils. I think this is due to the various
hash based collections returni
16 matches
Mail list logo