This allows to remove another jar file from the git repo and the
whole libbuild folder.
The ant task is just a wrapper to call the makensis command. So
there should not be any drawback to remove it.
Previously, the installer downloaded Java and installed a Desktop
shortcut to the downloaded installer. However the old download
URL is dead now and NSIS does not support the new https URLs
without a plugin.
Anyways it is not much of a difference in convenience whether the
installer downloads an installer or opens a browser with the
download location.
It has been considered to switch from NSIS to msitools[1]. However
both technologies are strange to all current YaCy devs and NSIS
still seems to be less complex and more widely adopted.
[1] https://wiki.gnome.org/msitools
I could only test this change in WINE because the developer virtual
machine from microsoft[2] freezed always soon after boot under QEMU.
[2] https://developer.microsoft.com/de-de/windows/downloads/virtual-machines/
The browser did not open under WINE.
The releaseNr is now set to a static value in build.properties. We
can increment it there manually and eventually switch to another
version number scheme if we like.
The https://reproducible-builds.org project invests a lot of work
to make builds reproducible. This is a security property. It allows
to compare the build of binaries from different builder machines.
If they are identical, it means that either the builds have not
been manipulated or an attacker managed to attack all builder
machines in exactly the same way.
One problem that the reproducible-builds project often sees is
that projects include the build time in their binaries. This
makes builds unreproducible for apparently no reason. The build
date should not be of interest since binaries built on different
dates but from the same source code should not be different.
Thus I decided to remove the build date instead of re-implementing
the functionality without the GitRev task. Anyways the reported
date was not the build date but the date of the last git commit
which is even less informative. The git commit ID would have
information value but should only be relevant for "nightly builds".
PKGMANAGER is always false, thus the java code wrapped in
if statements for this property is dead code and can also
be removed.
The Debian packaging removed in c4659f0fb0
did set the PKGMANAGER property to true. When we do distro
packages again, we can revisit this commit and redo it with
property files instead.
RESTARTCMD is only used inside those dead code.
DESTDIR is never used even in the build.xml
I'm about to make changes to the ant build that require to also be
done to the gradle build. However there is no active developer for
gradle in the YaCy project right now.
The motivation to introduce gradle was primarily to manage dependencies
and not commit them to git anymore. This has been solved by using
ivy.
Additionally, there were (to my understanding) still open tasks to
be completed for the gradle migration, e.g. the Windows build.
I came to YaCy with the intention of packaging it for Debian. It
is currently not feasible use gradle in Debian:
"If you have a choice, we recommend to use a different build system
like Ant or Maven which are better supported in Debian and are more
stable when it comes to Debian Java packaging."
-- https://wiki.debian.org/Java/Packaging/Gradle
It seems Fedora has completely given up on packaging gradle. The
last activity seems to be from 2017:
https://bugzilla.redhat.com/show_bug.cgi?id=1191535
This commit also shows how many files are necessary for gradle while
ant just needs build.xml and ivy.xml. It is also ironic that gradle
was introduced here to get rid of binary files in Git (jars) but
apparently gradle itself needs jar files in the repo to work.
First commit of a series to get rid of the git based versioning
implemented in libbuild/ folder as Ant task. It counts commits
since the last tagged version and uses this number added with
9000 as the last part of the version number.
This is a legacy from Subversion times.
Failed build:
https://github.com/yacy/yacy_search_server/runs/6859314856
Relevant build log:
resolve:
[ivy:retrieve] ivy.instance reference an ivy:settings defined in an other classloader. An new default one will be used in this project.
[ivy:retrieve] :: Apache Ivy non official version - :: http://ant.apache.org/ivy/ ::
[ivy:retrieve] :: loading settings :: url = jar:file:/usr/share/java/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
BUILD FAILED
/home/yacy/actions-runner/_work/yacy_search_server/yacy_search_server/build.xml:111:
java.lang.ClassCastException: org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor
cannot be cast to org.apache.ivy.core.module.descriptor.ModuleDescriptor
Finding:
The second call to the resolve target in ant failed apparently due to
two instances of Ivy in the java runtime.
Without full investigation, the problem could be fixed by ensuring that
the resolve target is only called once within one ant build.
