Situation: if you change a proceudure name / add a procedure in java source
and at the same time use the new procedure in htroot servlet
-> build fails with ant:javac error during gradle configuration phase
-> also clean build won't help as 1. gradle action is configure
see also https://github.com/yacy/yacy_search_server/issues/454#issuecomment-1031106178
Reason: in build directory is still the old yacycore.jar without the new procedure so javac - class not found will occur in compileHtrootServlets task
Quickfix: delete build/libs/yacycore.jar or the whole build directory
applied optimization
defining inputs and outputs for lifecycle detection in gradle task
and have the work done in a doLast section
- added multiproject in libbuild to compile and install all needed jars (reproduceing old maven build)
- adjusted GitComInf (use a project version, build script with less hardcoded strings)
- adjusted J7Zip-modified
- include common version number for output jar
- add task installJarToRoot to copy output jar to yacycore /lib
- adjust main build with updated jar names
as files are the same - updated also old build.xml
And the Eclipse specific .classpath (with shall be deleted until complete move to gradle)
- 1. not needed as in dev environment IDE's and from commandline gradlew run should/is be used to run YaCy (instead of startYACY) and Gradle makes sure yacycore.jar is on classpath
- 2. creates problem on compile if in source AND htroot some code has changed
as old yacycore.jar remains in lib (not removed by clean)
The properties contain info from the local git (the last commitDate and the number of commints since last distribution-label +9000)
currently Gradle build script must execute external jar (libbuild/GitComInf-All.jar) which creates a property file. other build targets relay on the properties - so here is a currently a timing problem.
1. nice would be we could get rid of the whole gitbuildnumber thing on work with current date etc.
Changed it now to create the property file at the end - after a build
so during init no external jar execution is required but just reading the prop file.
At least a bit more stable.
in addition I include it in the repository so that a fresh pime build has it available (even some measure included to use some fake if file is missing)
distTar is configured to use tar+gzip compression and creates now a archive named like yacy_v1.925_20220125_10199.tar.gz or distZip like yacy_v1.925_20220125_10199.zip
The legacy migration from Ant -> gradle task packageDist creates the same archive names.
but NOW in directory build/distributions/legacyDistFiles
to be able to use both in parallel (until knowing which one works better)
commit dfc7a23e60 uncomments the fake additional Gradle sourceSet (to make htroot in IDE visible), resulting in build error in IntelliJ IDEA if one uses just the IDE build button (and the old Ant build.xml is not available ... what is to expect soon).
This button runs as to expect the default Gradle task
> Task :htrootClasses (not our task compileHtrootServlets)
result :
htroot\processing\domaingraph\applet\domaingraph.java:1: error: package processing.core does not exist
import processing.core.*; import traer.physics.*; import traer.animation.*; import processing.net.*; import java.applet.*; import java.awt.*; import java.awt.image.*; import java.awt.event.*; import java.io.*; import java.net.*; import java.text.*; import java.util.*; import java.util.zip.*; public class domaingraph extends PApplet {// Domain visualization graph for YaCy
test case
- install IntelliJ IDEA
- New -> Project from Version Control ..... and clone from github
- IntelliJ Infobox "Gradle build script found" -> "Load Gradle Project"
- in UI execute task build
result: build error in compileHtrootServlets - (which would require manual interaction to get rid of)
reason IntelliJ apparently creates build directory before run build.gradle or configured as gradle project
solution: use other check condition for compileHtrootServlets to run
reason of failure was task compileHtrootServlets executing during gradle init
and javac resulting in error as not dependencies available in build dir
- happened only on very first build with with a fresh cloned repository
- updated some jar's (as Gradle build relies only on one jar in lib dir)
- guava-31.0.1-jre.jar
- jsoup-1.14.3.jar
- pdfbox-2.0.25.jar
- removed the not overwrite loop in copyDependenciesForDistribution as target dir is buildDir (not lib)
found this nice NSIS plugin which doesn't require local NSIS installation
allowing to implement similar function as in old Ant build
using the existing build.nsi
- task distWinInstaller
- resulting *.exe in build/distributions
- in case it's really used separately
with that most Ant build targets are available native in Gradle build (imho all targets we really need - see list of legacy Ant targets)
- "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" = won't impl. external tool needed
- "distMacApp" = won't impl. external tool needed
- "deleteData" = hm, won't impl. use nomale system
- Gradle task to execute "packageDist"
- this will create *.tar.gz and *.zip archive
- with legacy file name convention
- archive is created in build/distributions
- for the libbuild J7Zip-modified.jar use fallback as file dependency in lib
as Gradle/Groovy use internal just the classes from subprojects with result
that in above no jar is included in lib but a bunch of *.class files
- added also the option to publish J7Zip-modified.jar to mavenLocal() repo.
- with currently used version
- updated support/subproject J7Zip-modified (in libbuild) to be compilable via Gradle
- added dependency reference as sub-project
- skip the before applied copy of jars to lib directory (no benefit)
- new support library GitComInf to generate a property file for use in Gradle
- adjusted build.gradle to make use of it to create the yacyBuildProperties.java
- including additon of properties ext.filterTokens as store for Gradle
- added gradle-compile-htroot (w/o depends) to old build.xml as target until complete migration
as it is imho important
imho: much to complicated to get a running number - should be supplied by repo or simplified
to be able to use/reuse Ant targets where task has not been implemented in Gradle build.
- use the import to include the compile of htroot as first important task
! it is possible that first build fails an compile of GitRevTask.jar !
! solution/workaround -> use "ant all" once to compile GitRevTask.jar !
- adjusted build.xml a little
- split compile-core into compile-core and compile-htroot to have a target for htroot comp. only
- set build-path to reuse Gradles build directory
- (fix javadoc failure)
- changed the filtered-copy of yacyBuildProperties.java to ! the build path :-(
as current (copy,delete,exclude) is complicated and not migration worthy,
used simple/straigt forward approach (using a yacyBuildProperties.java.template file as copy source)
This is almost working with many workarounds:
- run rm lib/yacycore.jar
- run ./gradlew clean build bundleNative
- run ant clean all
- run again rm lib/yacycore.jar
- run ./fixMacBuild.sh
The build is then inside build/mac/YaCy.app
Right now this works so far but it does not have the correct release
number inside.
Target is to make this working for Windows releases and to embedd jre
entirely.