On Thu, Feb 22, 2018 at 5:58 PM, Shawn Wells <shawn@redhat.com> wrote:

The current check:
- First evaluates the JBOSS_HOME environmental variable, looks for version.txt in that filepath, and runs a regex to ensure the Enterprise version is installed
- Failing to find JBOSS_HOME, it looks in /etc/eap/version.txt (which is where the JBoss Product Managers told us JBoss is installed for VMs and container images, IIRC)

Before going into the code to much, is that approach appropriate?

By contrast, it looks like your script unzips jar files and looks in META-INF/maven/org.jboss.modules/jboss-modules/pom.properties. I don't have enough JBoss knowledge to know if these approaches are effectively the same, or if one is more ideal. Can you help us understand?

Sure.  I've run across situations where users have deleted the version.txt file, renamed directories, and generally wreak havoc on what version is being run.  Generally, no assumptions can be made on where files are located, whether there's a version.txt file, or what directories are named.

My goal was to have a methodology that identifies what's installed regardless of where files were placed.  Older versions of JBossAS have a run.jar file and newer versions use a jboss-modules.jar file, where both of those files *MUST* be present in order for JBoss AS to run.  The script I created searches for those specific files and then examines the metadata within to determine if it's an enterprise or community release.  I've tested this against 110 community releases of JBossAS/WildFly and 87 releases of EAP with community being correctly identified and enterprise releases being ignored.  JBossAS/WildFly/EAP follow consistent nomenclature in the metadata that makes all this possible.

It's important to note that this can only detect whether JBoss community is on the filesystem, not that it's actually being run or used.