NASA-PDS
Validate fails when installed into the same directory
Checked for duplicates
No - I haven't checked
🐛 Describe the bug
Okay this one is decidedly off-nominal, but just in case...
Someone installed two versions of validate into the same directory (i.e. on top of each other). I can see this happening if people want a constant "validate" dir instead of e.g. "validate-3.5.1" which changes at every release.
After doing that, validate kept trying to validate a jar file. After an hour or so of poking into it, I found this in the validate startup script:
VALIDATE_JAR=`ls ${LIB_DIR}/validate-*.jar`
...
"${JAVA_CMD}" -Xms2048m -Xmx4096m -Dresources.home=${PARENT_DIR}/resources -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Djava.util.logging.config.file=logging.properties -jar ${VALIDATE_JAR} "$@"
So if there are two versions of validate*.jar in the lib dir (as happened with the double-install), VALIDATE_JAR ends up with two words and that makes the second one appear as a target rather than a jar on the main command line. So it tries to validate the jar file and fails, then goes ahead and validates the target as it should.
Easy fix would be to pipe that through tail -1 :
VALIDATE_JAR=`ls ${LIB_DIR}/validate-*.jar | tail -1`
which should pick up the highest numbered version if there's more than one. But I don't know if anything else would fail in this scenario. If there are other things that could fail, you could check for more than one jar in the lib dir and error out if so.
🕵️ Expected behavior
I expected validate to figure it out and grab the latest
📜 To Reproduce
see above
🖥 Environment Info
$ uname -a
Linux machine 3.10.0-1160.76.1.el7.x86_64 #1 SMP Tue Jul 26 14:15:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
openjdk version "1.8.0_345"
OpenJDK Runtime Environment (build 1.8.0_345-b01)
OpenJDK 64-Bit Server VM (build 25.345-b01, mixed mode)
📚 Version of Software Used
3.5.1 for the recent install. Don't recall the old install, was 2.something.
🩺 Test Data / Additional context
No response
🦄 Related requirements
No response
⚙️ Engineering Details
No response
🎉 Integration & Test
No response
@rgdeen unfortunately, the tail -1 solution won't work, since that would not be able to handle semantic versions, e.g. 10.1.0, 1.0.0 will not order properly. tossing this into the backlog since this is not a use case we have often found with users (this is the first time this issue has arisen), but we will get it into the plan sometime in the future
@jordanpadams
Should not be doing any parsing of versions. It should use the version defined by the download as in:
VALIDATE_JAR=${LIB_DIR}/validate-3.5.1.jar
@al-niessner I did not have the time to figure out how to get maven to inject the project.version into that file. If you can figure that out, a PR would be great.