add gradle build process, remove ant

[Orbiter]

A lot of libraries should be upgraded, but I do not want to bloat the jar libraries inside this repository any more. The best step would be to ditch the ant build process and start new with gradle.

This is (also) a call for gradle hackers who are experienced with building of Windows/Mac-native applications.

[sixcooler]

I already startet on freshing libs. (will go on, whenever I've some time) Why to prefer gradle over maven?

[yacylover]

Hi,

 

Great!

It would be great, too if this bug can be fixed in one of the next releases:

https://github.com/yacy/yacy_search_server/issues/372

It is still present in actual builds 1.922/100*

 

 

Best

 

LA_FORGE

Am 19.08.2020 um 12:06 schrieb sixcooler:

I already startet on freshing libs. (will go on, whenever I've some time) Why to prefer gradle over maven?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/yacy/yacy_search_server/issues/377#issuecomment-676074862, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6GWDHBLOMKSVWG35XKIFTSBOP2XANCNFSM4QETSBQQ.

 

[Orbiter]

@sixcooler the main purpose of this is to get away from libraries in the repository. So maven/gradle is both on the right side of a solution. However I consider maven a bit outdated since xml is a bit outdated.

[reger24]

A lot of libraries should be upgraded, but I do not want to bloat the jar libraries inside this repository any more. The best step would be to ditch the ant build process and start new with gradle.

This is (also) a call for gradle hackers who are experienced with building of Windows/Mac-native applications.

Right now the Gradle script is a joke - the old Maven at least worked w/o ant (except the htroot additional source path w/o package structure etc.). But I hear you - Gradle it is.

Me not beeing a Gradle hacker but I guess I can at least do some stuff to support the migration from Ant to Gradle. So I'll start and after 80-90% is migrated we can decide if we do things different if Gradle build it requires.

No reply expected... I'll start as long as I've some spare time.

[reger24]

with commit https://github.com/yacy/yacy_search_server/commit/6dcb58a4b59ef4f0aadc92858c8bf7c7c322e826 all needed legacy Ant tasks are available in Gradle build

List of Ant targets (with result comment)

• "readBuildProperties" = see no use
• "init" = not needed (ant internal prop initialization)
• "javadoc" = gradle-task javadoc
• "compile-core" = gradle-task build
• "compile-htroot" = gradle-task compileHtrootServlets
• "compile" = gradle-task build
• "all" = gradle-task build
• "copyMain4Dist" = gradle-task packageDist
• "compileTest" = gradle-task compileTestJava (std)
• "test" = gradle-task test (std)
• "dist" = gradle-task packageDist
• "portalsearch" = gradle-task packagePortalsearch (is that file still used?)
• "clean" = gradle-task clean (std)
• "run" = gradle-task run (std) or shell
• "run-single" = not needed (old stuff)
• "debug" = won't gradleize ide or run
• "stop" = just a shell script
• "create-doc" = gradle-task javadoc
• "distWinInstaller" = gradle-task distWinInstaller
• "distMacApp" = won't impl. external tool needed
• "deleteData" = hm, won't impl. use nomale system

[Orbiter]

Wow, great!

[reger24]

@Orbiter thank's .... I leave it up to you, when to delete the (old) build.xml

[Orbiter]

I have recently installed openjdk 16.0.2 and since then I run into problems with all gradle projects.

• gradle below 7.0 fail with Unsupported class file major version 60
• the gradle version in the commited gradlew is 6.9 and upgrading to 7.3 creates a strange Entry yacycore-1.925/lib/yacycore.jar is a duplicate but no duplicate handling strategy has been set.

So the obvious solution would be a migration to gradle >= 7.3 .. to support also jdk 17 https://docs.gradle.org/7.3/release-notes.html#java17

[reger24]

I'd similar class file version issue at the beginning with using Gradle 6.9 (coming from 7.3) my error was an other version number (think 52 or so), fix was (if I remember right) to set the correct and SAME JDK version for everything instead of using Gradles's bundled one

anyway ... don't like/want to stay with 6.9 forever ..... and on my side Gradle 7.3.3 works fine The mentioned duplicate error ist fixed by ) ( https://github.com/yacy/yacy_search_server/commit/68e5c413850b51328feca6f9e74b1f8aea809ce6 )

By the way the build-in distTar and distZip have a predefined directory layout with /lib and /bin, so the /lib directory fit's by accident to our old structure in the /bin is a yacycore (sh script) and yacycore.bat automatically include and intended to start YaCy result on my Win

• The input line is too long.
• The syntax of the command is incorrect. With other words - they don't work with the full classpath (the startYaCy by accident does)

So in the moment we've 2 distributions .... the default (distZip, distTart which not completely work) and the legacy archive with the old/known naming convention ( yacy_v1.925_20220125_10198.tar.gz / yacy_v1.925_20220125_10198.zip ) At one day it needs to be decided which one should survive !

[reger24]

one more word to standard distZip / distTar,

• on reason that I duped the old distribution was (besides the before mentioned issue with run script not working), that even if adjusting the tar/zip base name to the known archive naming convention - gradle always add the project version to the end of the base name (see also comment in build.gradle distributions)
• resulting in yacy_v1.925_20220125_10198-1.925.tar / yacy_v1.925_20220125_10198-1.925.zip -> thought you don't like it and changing distribution name either
• distTar creates a pure tar (not gzipped)

for both last points I found now a possible workaround by specifically configuring standard distZip and distTar

but once in a while there maybe a output arch. "yacynull_v1.925_null_null.zip".

So IT IS possible to use the standard distZip/distTar and dump task packageDist (legacy migration)

build.gradle adjustment would be as follows (see commit https://github.com/yacy/yacy_search_server/commit/3996fb092054b51cc4d9c2ff27645e3f7e2c890c ) tasks.findByName('assembleDist').dependsOn('prepYaCyProperties') distTar { compression 'GZIP' archiveExtension = 'tar.gz' String Dst = project.ext.filterTokens.get('DSTAMP') String rNr = project.ext.filterTokens.get('releaseNr') String branch = project.ext.filterTokens.get('branch') archiveVersion = '' // important as otherwise version is added automatically again to the end of archiveBaseName archiveBaseName = 'yacy' + branch + 'v' + project.version + '' + Dst + '_' + rNr }

distZip { String Dst = project.ext.filterTokens.get('DSTAMP') String rNr = project.ext.filterTokens.get('releaseNr') String branch = project.ext.filterTokens.get('branch') archiveVersion = '' // important as otherwise version is added automatically again to the end of archiveBaseName archiveBaseName = 'yacy' + branch + 'v' + project.version + '' + Dst + '_' + rNr }

[Orbiter]

ok, I am really happy with this, I believe that was a lot of work.

About the release naming convention: well we should overthink this, obviosly making a version number out of number-of-commits-since-last-release plus 9000 is strange. There was once a reason for that, the migration from svn, but we should move forward somehow.

Another point: I recently made my first "nix-file" for nixos. (here: https://github.com/yacy/searchlab/blob/master/default.nix ) That thing requires a version number which is identical with a git tag. So that must be taken into account.

To finalize this, we must test all release options. For example: the dockerfile, which depends on ant.