Archive of Java jar and sources, re-compile

See vishia.org/SwEng/html/srcFileTree.html

The working tree should contain

If you get a zip file with examples etc, for example vishia.org/Fpga/deploy/J2Vhdl_Workbox-2023-10-16.zip , you get only the src directory. More is not necessary.

The src/load_tools contains:

The tools.bom contains all necessary information to load the tools from internet:

The script for MS-Windows looks like:

And similar the linux shell script:

The used function to load or only check is written in Java and contained in the vishiaMinisys.jar. Only this file, approximately with 100 kByte, should be a part of the tools or source download package beside some textual files etc. of the tool or source files beside a example of specific solution. All other executable, jar and libs can be downloaded one time from internet.

If you have downloaded the file there are stored in the given location, and the software run without internet connection. A second call of the script in src/load_tools checks only the correctness of the MD5 check sum given in the tools.bom with the given files. You do not need internet connection.

One advantage of the tools/…​ directory beside the src/…​ is: This is your necessary tool, jar or lib file for your application. For further usage you can also store your application sources with the tools to be independent of the internet. Think about long time support.

Now the essential question is: What does the tools? What is contained in the jars? The Open Source approach says: You can inform yourself. You can change your tools in your responsibility. You can contribute.

For that firstly it is necessary to get the sources and build the tool (jar) files again, check whether the gotten sources are really the sources for your used tool / jar. Only if yes, you can simple study, change, contribute. That’s why reproducible build is given. See also reproducibleJar.html and https://reproducible-builds.org

The version archive at https://www.vishia.org/Java/deploy contains per version the jar-Files as run able libraries and their sources. Additionally an MD5.txt-file is given. For example:

The used *.jar file is given in the bill of material, see previous chapter. Beside you find the sources. From the sources the binaries (here jars) are newly able to build.

You can decide by yourself to use newer versions as in the currently build of materials preferred. That is your experience. Maybe you need newer features of a tool, they are contained in the newer jars, but the currently deployment of the tool use yet only the older sources in its bill of material. Usual newer versions should be compatible to older ones. It means you can use the newer version. But nobody guarantees that is really proper. You need existing new features, you can try by yourself. You can compare the sources which changes are really done. You can try usage, report found errors, all that helps to improve.

Last not least you can fix found errors by yourself, maybe (should be ) with adequate feedback.

The build scripts for all vishia jar files are shell scripts. They can be executed in Linux, but also in Windows using for example MinGW. MinGW is contained in a standard git environment. git contains a MinGW Linux environment, because git runs originally under Linux. The same can be done with any gcc (GNU compiler) collections. In other words, a shell execution environment should be available to everybody who is trying to compile something.

On my Windows PC I have combined the extension .sh with a batch file, git-script.bat which contains

There are some more necessities especially conversion the backslash from the command line file argument on double click to the slash. The home path can contain some information also used for git, not for this scripts.

The second necessary one is a JDK, Java Developer Kit, of course. It is not necessary to have it installed, it is sufficient that it is present on the PC platform. You can have several versions of JDK at the same time, from Oracle, or OpenJDK.

Therefore the environment variable JAVAC_HOME should be set to that directory, which contains a bin/javac. This environment variable can be set by the system, if a JDK is preferred. If it is not set then the file

is called. This file can/should be adapted by the user to select the correct location of the JDK. For Linux compilation sometime JAVAC_HOME is not present but javac is possible as command because the JDK/bin is in the systems’s PATH. That is proper and regarded in the script.

It is possible to re-generate the jar file with the exact same content, hence the same MD5 check code, using the …​source.zip archive.

The first statements in a makejar_Component.sh checks and changes the current directory:

It works correct also if the directory on call is arbitrary because it uses the script calling path in $0.

The build and tools should be already present there, as described in chapter What about tools directory and The build directory

For the reproducible build the time stamp of the files in the jar is essential. This timestamp may be also for example 1970-01-01, but it is better to have a real time stamp. This timestamp is determined by

The VERSIONSTAMP determines the names of the created files. If it is left empty as here, the current date will be used. That is usual proper because it does only influence the file name, not internal content.

The TIMEinJAR is the time stamp of all files which are packed into the jar file. Here the file time is essential for the check sum of the file. Hence you must not change this value for a reproduced build. But if some things in the sources are changed, you should set a proper time stamp value in the new version of the makejar…​sh file.

It may be possible to read the sVersion variable from the source files, usual or often contained there, and build the time stamp of the class file with it. This is an interesting feature because then the version of each file is documented in the jar file on the file time. But this feature presumes that all files have such a version string, (or use 1970-01-01+00:00 is not found), and it is an effort. It may be done in future.

Some varibales determine the output file names and the files to compile.

This name is used for the output files.

Either the SRC_ALL and optional also SRC_ALL2 is set with a path. Then all *.java files in that path(s) are used to compile. There is no exclusion possible. In this case two locations with java files are given. This is the proper variant to get a jar file as library from the whole component. Then also the SRCPATH is determined by this SRC_ALL.

Or the other variant, one or some top level files are given to compile, whereby depending files are automatically located whether they are available in a given jar file as library (see CLASSPATH in next chapter), or there should be able to find in the SRCPATH. The files given as package/to/name.java can be contained also in a list file. This is done for example on build of the vishiaMinisys.jar. It looks like (see makejar_vishiaBase.sh):

Then the SRCPATH should be given where these files are located.

The CLASSPATH variable describes the path where already compiled *.class files, usual in jar libraries are able to find. If there is no CLASSPATH necessary left it empty or unset it.

It may be different in the working tree whether a tools or a jars sub directory may be used. See chapter File tree organization for sources and components. Hence it is checked, here with existing check of the necessary jar file.

The next problem is: The path separator in a javac command line argument is unfortunately different between MS-Windows and Linux. Hence the OS should be testet. All Windows-OS (testet till Windows-10) contains this checked environment variable. If not, set it in the shell script batch organization, see chapter Necessary tools on your computer for build jar files In this example the separator is not necessary, but it is given as pattern here.

The CLASSPATH variable should be contain the `-cp ` option as shown.

The MANIFEST variable describes the *.manifest file necessary in jar files:

The RESOURCEFILES variable contains the path(s) separated with space to some more files which should be stored in the jar. They are taken originally from the src/component/…​ location containing between the *.java sources.

The colon : in this path (as also in SRCADD_ZIP) is essential: It separates the base path (used for access, but not stored in zip and jar) from the local path (starting after :) which is part in the zip archive. In this example the SRC_ALL is reused to address the source files, ** means, all sub trees, then **/*.ext addresses the file with the given extension. This writing style is a feature of org.vishia.util.FileFunctions.addFilesWithBasePath(…​) used for the zip algorithm, it is amazing proper.

If a SRCADD_ZIP variable is existing (exported), only then a …​source.zip is created.

Here this variable contains the path to the makeScripts files. The paths in SRC_ALL and SRC_ALL2 are added also to the …​source.zip file. But if FILE1SRC and also SRCPATH is only given, no source files are added because of them. Then the SRCADD_ZIP should contain all file paths.

Other than in the jar zip file the local paths in the …​source.zip starts from the working directory, always should start with the src/…​. This assures that the …​source.zip is consistently to the working tree structure. The .: on start is necessary because elsewhere the local path containing in the zip is not detected. ‘.’ means the current directory. ‘:’ determines the local directory start after the colon. You can add any other location also, writing before the ‘:’ if necessary.

More paths should be separated by a space.