Make LRC library loading dynamic

[PHameete]

Currently, the gradle config is hard-coded to reference the Pitch x64 LRC jars on the default Windows installation path. Upon building a distribution these jars are also included in the lib folder of the distribution which is not allowed.

By containerizing the IVCT we can expose different LRC vendor libraries via container extension or volume mounting. The IVCT need not concern with the specific type of LRC library that is being used.

We need to discuss and come up with a solution that:

• Is convenient for local development. The locally installed LRC libraries should work out of the box, or with minimal configuration, when running / debugging from Eclipse
• Allows an easy way to inject the LRC libraries for the distributions. For example, the MSG 163/164 images expose the LRC libraries via an ENV variable $LRC_CLASSPATH.

[PHameete]

@rhzg could you elaborate on the solution that you mentioned yesterday: having the IEEE1516e dummy project as a compile dependency, but not runtime. Perhaps we can modify the gradle script that generated the distribution to exclude any LRC jars, and to include the $LRC_CLASSPATH ENV variable as a mounting point.

[rhzg]

there is a gradle dependency declaration called "compileOnly". We need to test if this helps to use some libraries only for compile time and not include them into the distribution.

[PHameete]

I'm running into this again now that i'm dockerizing the TC Runner.

The gradle script generated a startup script with a CLASSPATH.

This CLASSPATH needs to have the $LRC_CLASSPATH environment variable included and that would solve the problem.

Currently I modified the startup script for the container to add this by using a find and replace on the startup script. This is a temporary workaround though!

For local development we use the 'dummy' implementation, or prti if configured.

[rhzg]

the gradle script (it is the gradle application plugin) is not very flexible. It just collects all runtime jar's and creates a bat-file with a preconfigured CLASSPATH. In order to create a docker container, would you even use this application plugin? Is there not a gradle plugin to create the images? (I know there are some maven plugins to do this - but I have no experience with gradle)

[ducana]

Have made a first attempt to solve this problem: both MAK and Pitch have distinctive environment variables to point to the RTI installation. The gradle scripts use this fact to build the IVCT test system corresponding to the RTI available. Further tests have to be made to check if this will solve the problem when building the docker containers.

[PHameete]

Ive tested your change and this works for PRTI. The gradle install automatically makes the projects depend on the prti lib folder when that is installed. When I remove the ENV variable it uses the IEEE1516e dummy lib.

Part 2 of this issue however is to find a way to link the LRC libraries at runtime for the distributions that are built with gradle. Currently I use a bit of a hacky script (see https://github.com/MSG134/IVCT_Framework/blob/development/TC.exec/docker/start.sh) to replace the CLASSPATH with one that also contains the LRC libraries of the container.

Better would be to have a dedicated ENV variable always included in this CLASSPATH and then just set that to point to the LRC libs instead.

[ducana]

Pieter: I have made a change in my code to use $LRC_CLASSPATH for the RTI *.jar files. Let me know when you want me to check-in this version, since the test system won't work until the $LRC_CLASSPATH is set.

[PHameete]

Hey! If you could check it out on a branch that is branched from development so I can try it out before we merge to development that would be perfect!

Op ma 29 okt. 2018 om 14:11 schreef ducana notifications@github.com:

Pieter: I have made a change in my code to use $LRC_CLASSPATH for the RTI *.jar files. Let me know when you want me to check-in this version, since the test system won't work until the $LRC_CLASSPATH is set.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MSG134/IVCT_Framework/issues/100#issuecomment-433904131, or mute the thread https://github.com/notifications/unsubscribe-auth/ADvVgFTAN-iOkx2EujQYSqZG1IM66ztjks5upv6YgaJpZM4UETWj .

[ducana]

Hi Pieter, this change is on the branch "issue-100". The $LRC_CLASSPATH was added to the classpath in the gradle script and it means that if this variable is set previously to the LRC *.jar files, then IVCT should work "out of the box".

[ducana]

Once this has been tested, just need to do the pull merge request.