Hi all,
as already mentioned, I will create a mail thread for each epic that we defined
for the “Support & Care for Apache Maven” initiative
(https://open-elements.com/support-care-maven/).
All information about this specific epic can be found at
https://github.com/OpenElements/maven-support-c
Hi all,
as already mentioned, I will create a mail thread for each epic that we defined
for the “Support & Care for Apache Maven” initiative
(https://open-elements.com/support-care-maven/).
All information about this specific epic can be found at
https://github.com/OpenElements/maven-support-c
On 28 Sep 2019, at 18:21, Hervé BOUTEMY wrote:
> I'll share shortly a discussion on a choice we need to do together to define
> how to configure reproducible builds (property name and value/format of
> current source-date-epoch defined in PoC)
Now that support for this has been released as part
last updates:
- tar.gz archives are now also reproducible (in addition to .zip)
- src archives are also built and reproducible (notice that the result is the
same on every JDK version of a platform. Notice 2: if you don't get the same
result than CI, check that you don't have IDE configuration fi
Le mardi 24 septembre 2019, 02:28:15 CEST Mark Derricutt a écrit :
> Tomo Suzuki wrote on 23/09/19 3:56 PM:
> > Does your approach use such file to record library versions?
>
> I don't know about what Hervé is doing,
I added an "out of scope" paragraph: managing version ranges in a stable way is
Cool. Thanks.
On 24 Sep 2019, at 23:37, Tomo Suzuki wrote:
> versions, rather than ranges. Would you share the background why your tool
> records the ranges?
The full examples is at:
https://github.com/HalBuilder/halbuilder-support-4.x/blob/master/pom.deps
It resolves the locked down versions, but also ret
Oh right! I missed the second half of our pom.deps file:
blacklisted org.hibernate:hibernate-ehcache:4.2.19.Final from
smx3:smx3.bill-of-materials:2.1.1;
deprecated org.hibernate:hibernate-search-engine:4.4.0.Final from
smx3:smx3.bill-of-materials:2.1.1;
resolved org.hibernate:hibernat
Hi Mark,
Thank you for response.
> resolve highest org.jetbrains:annotations:[16.0.3,17.0.0) via public;
For reproducible builds, I expected the lock file contains specific
versions, rather than ranges. Would you share the background why your tool
records the ranges?
--
Regards,
Tomo
Tomo Suzuki wrote on 23/09/19 3:56 PM:
Does your approach use such file to record library versions?
I don't know about what Hervé is doing, but internally we have a tool I
wrote for handling this, we have a pom.deps file that looks like:
repository http://nexus.XX as public;
impor
Le 23/09/2019 à 01:52, Hervé BOUTEMY a écrit :
> after a few years of testing, thinking, procrastination and hard work (thank
> you Thomas for your talk at Devoxx France 2016 [1]), I think I achieved a key
> step this week-end toward native Reproducible Builds with Maven [2]: Maven
> core itself
Le lundi 23 septembre 2019, 05:56:06 CEST Tomo Suzuki a écrit :
> Sounds nice!
don't hesitate to build for yourself, check that you get the same sha512 and
report: this will help me either confirm "it works", or find little remaining
issues.
>
> > The precise result depends only on 2 key facts
Sounds nice!
> The precise result depends only on 2 key facts
When I hear “reproducible builds”, I think of lock files that remember
library versions used.
Gradle’s approach:
https://docs.gradle.org/current/userguide/dependency_locking.html
Does your approach use such file to record library ver
after a few years of testing, thinking, procrastination and hard work (thank
you Thomas for your talk at Devoxx France 2016 [1]), I think I achieved a key
step this week-end toward native Reproducible Builds with Maven [2]: Maven core
itself can be built in a reproducible way!
It means that if
14 matches
Mail list logo
