I am able to obtain and build the latest Apache NetBeans incubator sources and
build, but not without first modifying the MD5 sums within a number of the
binaries-list files to match those that are "expected". Is there a reason that
these MD5 sums are not up-to-date if one attempts to build fro
See https://nextbeans.com/reproducible.html
Our builds are not reproducible.
--emi
‐‐‐ Original Message ‐‐‐
On 15 June 2018 2:42 PM, Josh Juneau wrote:
> I am able to obtain and build the latest Apache NetBeans incubator sources
> and build, but not without first modifying the MD5 su
Hi Josh,
Do I understand correctly that you clone, and then simply run "ant"? Then
I'd expect no need to update any hashes (the correct dependencies should be
downloaded). Do you have an example where you had to change the hash?
Thanks,
Jan
On Fri, Jun 15, 2018 at 1:42 PM, Josh Juneau wrot
Hi Jan and Emilian,
Thanks for the responses. Yes, after I clone, I simply run ant. I just
performed a new clone to test the issue again, and here is example of the hash
update:
Download of
B9BBF5BF22E1B8603F312F6E02ABC6267996B38A-net.java.html.boot.fx-1.5.1.jar
produced content with hash B
This most definitely should *not* happen.
Note that Travis builds NetBeans all the time and downloads dependencies just
like you do and builds would fail when this happens.
Do *not* change hashes if you don't know why it must be changed. From a
security standpoint it is very dangerous.
--emi
Hi Josh,
Am Freitag, den 15.06.2018, 10:41 -0500 schrieb Josh Juneau:
> Thanks for the responses. Yes, after I clone, I simply run ant. I
> just performed a new clone to test the issue again, and here is
> example of the hash update:
>
> Download of B9BBF5BF22E1B8603F312F6E02ABC6267996B38A-
> n
Thanks for the responses on this issue. Indeed, it is a bad idea to modify
hashes...that is my reason for starting this thread.
It sounds like there is an issue with my local maven repository. I will start
by troubleshooting there to see if I can repair. Thanks for checking the jar
file to
Hi,
Thanks for the information. I suspect this may be caused by a local build
of HTML4J, which installs the artifacts into the local .m2 storage, and
these are then picked up by the NB build. I think I have an idea how to fix
that, need to try it.
Jan
On Fri, Jun 15, 2018 at 6:10 PM, Josh Junea
Hi all,
looking at the url for maven central I was wondering if we should use https?
-Sven
Jan Lahoda schrieb am Fr., 15. Juni 2018, 22:11:
> Hi,
>
> Thanks for the information. I suspect this may be caused by a local build
> of HTML4J, which installs the artifacts into the local .m2 storage,
> looking at the url for maven central I was wondering if we should use https?
That would only accomplish making the download more private (ie the ISP
wouldn't see you downloading this JAR) but since we check the hash there's no
way to tamper the bits.
--emi
‐‐‐ Original Message ‐‐‐
O
10 matches
Mail list logo
