Reasoner::getReasonerName returns null

[balhoff]

Calling Reasoner::getReasonerName returns null. I'm using release
"net.sourceforge.owlapi" % "org.semanticweb.hermit" % "1.4.0.432" in a Scala application. I see it's implemented as getClass().getPackage().getImplementationTitle(); I guess this needs to be in the pom.xml as in ELK?

Sorry to report this here. :-) @ignazio1977 doesn't have Issues enabled on his fork. Is there any other official location for issues?

[ykazakov]

I think java takes ImplementationTitle from Manifest.mf (which is created in the case of ELK by maven)

[ignazio1977]

I'll enable the issue tracking. There was talk a few months back to move my fork to the owlcs group and make it a complete site - the official home of the fork, so to speak.

[ignazio1977]

Issues are now enabled.

[ignazio1977]

HermiT has a manifest.mf file included but it does not contain Specification tags, it's got Bundle tags. The build file needs a few tweaks.

[balhoff]

I'm curious why not just return "HermiT";? It doesn't seem like something that needs to be so dynamic.

[ignazio1977]

Strangely enough I can't get the desired behaviour to work. OWLAPI uses the exact same code in VersionInfo and has a similar manifest file, and that works fine. HermiT on the other hand refuses to play ball.

There's precious little documentation on troubleshooting this kind of issue. I'm inclined to hardcode the string, as it doesn't make much difference to hardcode it in a pom file or in the Java code.

[ignazio1977]

Fixed on master branch and version4 branch at https://github.com/ignazio1977/hermit-reasoner/

[ykazakov]

@ignazio1977, I am curious what exactly did not work for you (before you hardcoded the string)? Clearly, the problem was because the "Implementation-Title" was not present in the HermiT Manifest file. Did it not work for you to add "Implementation-Title" to the Manifest file or the code getClass().getPackage().getImplementationTitle() did not return the value from the Manifest file?

Also, there is a problem with getReasonerVersion() similar to liveontologies/elk-reasoner#49. I wonder how the InferredOntologyGenerator was used with HermiT so far.

[ignazio1977]

I changed the pom to add Implementation-Title to the manifest file - that part worked fine. Snippet below - it's the same approach OWLAPI uses, and which works for OWLAPI.

However, getClass().getPackage().getImplementationTitle() kept returning null

		<plugin>
			<groupId>org.apache.felix</groupId>
			<artifactId>maven-bundle-plugin</artifactId>
			<version>3.2.0</version>
			<extensions>true</extensions>
			<configuration>
				<instructions>
					<Implementation-Title>${project.name}</Implementation-Title>

I haven't been able to change that behaviour.

I considered whether the package the classes are in could be part of the problem, but there is no split package to confuse the VM here.

According to some Oracle documentation, it is possible to specify Implementation-Title on a per-package base - i.e., org.semanticweb.HermiT could have its own Implementation-Title by specifying a Name: org/semanticweb/HermiT entry immediately before the package specific entries in MANIFEST.MF. However, I could not find a way to add Name through the maven bundle plugin. The plugin complains that this interferes with the Name section in the MANIFEST.MF, which kind of is the point.

I assume I could get the desired result by shading the bundle and applying some transform, but at this point my energy was exhausted :-)

Same problem with the getReasonerVersion method - like you're seeing in ELK, I was getting back 0.0.0.0. I've worked around it with a hardcoded Version instance in the reasoner. It requires manual update before a release, which is suboptimal; long term, I'd want to figure out what is going wrong instead.

[ignazio1977]

I wonder how the InferredOntologyGenerator was used with HermiT so far.

The failing string is the build section of the implementation version tag, and that was not always including a build timestamp - if I remember correctly, that's a recent change. I'm guessing most users of InferredOntologyGenerator have not used it with recent HermiT versions, or did not get errors generating axioms - as far as I can tell, in InferredOntologyGenerator the reasoner name and version are only used when reporting exceptions, so it might not be as common an occurrence as we'd think.

[ykazakov]

Hmm. Do you get null from eclipse? For ELK I also get null for getClass().getPackage().getImplementationTitle() in eclipse if I enable workspace resolution (of maven projects), but if I disable that I get the right value.
What I also found out is that if there is a same package somewhere else (for example, in tests you write in a test project in the workspace) then java got confused and choses null or the correct value non-deterministically.

[ykazakov]

Note that for getReasonerVersion() the problem was different (also for HermiT!). The value was correctly taken from the Manifest file, but the problem was in converting it to a sequence of integers as required by getReasonerVersion() since this string contained not only integer characters.

[ignazio1977]

I created a new project in Eclipse, and lo and behold, everything worked as expected on extracting the implementation title and version from the manifest file. I did not have to play with workspace resolution.

Sounds definitely like a fragile setup, though. Most developers using HermiT won't have the HermiT source checked out in their Eclipse workspace, but those who do will get variable results based on non obvious conditions.

In OWLAPI VersionInfo tries to extract the string from the manifest, but it has a default value if that fails - that's not perfect either, but logging an error message so that developers can be alerted if the version they're seeing is defaulted should avoid the bulk of issues.

[ignazio1977]

For the version, a snapshot version looks like this:

1.4.1.514-SNAPSHOT.2018-04-14T12:14:20Z

Unfortunately the Version class cannot deal with the patch and build sections of the string. It would fail in situations such as working with a SNAPSHOT build, or a BETA release, and so on. No good solution without an interface change, I think - we could add String fields to Version so that those systems that are aware can expose the complete version string, and those which are not aware can still use the ints to describe the version. Snipping the SNAPSHOT and leaving the build number to 0 might be the best approach.

[ykazakov]

I created a new project in Eclipse, and lo and behold, everything worked as expected on extracting the implementation title and version from the manifest file. I did not have to play with workspace resolution.

Did you have HermiT as a project in the workspace? If not, the workspace resolution would not make a difference. If it is checked out in the workspace, then Eclipse by default includes the project in the class path instead of the jar dependency. If Eclipse cannot find the Manifest file of HermiT (in the project), then returning the reasoners names and versions from Manifest will not work. I guess the Manifest it is only packaged within jar, so Eclipse does not find it. In ELK we specifically change the location of Manifest file for this purpose. See here.

[ykazakov]

B.t.w., I cannot compile HermiT from this repository. When I do mvn compile I get:

[INFO] ------------------------------------------------------------------------
[INFO] Building HermiT 1.4.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- buildnumber-maven-plugin:1.4:create (default) @ org.semanticweb.hermit ---
[INFO] Change the default 'svn' provider implementation to 'javasvn'.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.091 s
[INFO] Finished at: 2018-04-15T12:58:40+02:00
[INFO] Final Memory: 21M/309M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.4:create (default) on project org.semanticweb.hermit: Cannot get the revision information from the scm repository :
[ERROR] Exception while executing SCM command. svn: E155007: '/Users/test/git/hermit-reasoner' is not a working copy

It seems like it tries to get a version number from an svn repository, whereas it is a git repository.

[ykazakov]

Unfortunately the Version class cannot deal with the patch and build sections of the string. It would fail in situations such as working with a SNAPSHOT build, or a BETA release, and so on.

It also does not work for the released version. The current version 1.4.0.432 from maven central, for example, has the following Implementation-Version in Manifest:

1.4.0.432.2017-09-14T19:37:35Z

What I did in ELK, is just ignored all characters except for digits and dots. See here.

[ignazio1977]

Did you have HermiT as a project in the workspace? If not, the workspace resolution would not make a difference.

Yes I did - I had it open yesterday as well, when my test project did not work. That's why I think the difference is subtle and we'll see developers reporting difficult to replicate issues.

[ykazakov]

So, how does Eclipse find the HermiT Manifest file in your setup?

[ignazio1977]

It doesn't - given a maven project that declares a HermiT dependency, accessing the manifest works, but if the HermiT project is added to the Projects section of the eclipse project, eclipse overrides the maven jar with the local project.

I'm under the impression that in some situations eclipse will automatically add a workspace project as a dependency when the corresponding maven dependency is added, but not in all situations - hence the variable results we've seen.

[ykazakov]

If Eclipse does not find the Manifest file, then how extraction of the implementation title now works for you (after creating a new project)? Can you check the class path of this project? Does it use HermiT from the workspace or from the jar from the local repository?

In any case, the problem should be resolved after placing Manifest file in the root of the project as I mentioned.

I agree that Eclipse can glitch, but I do not think that this is a good reason to hard-code (particularly the version) values.

[ignazio1977]

how extraction of the implementation title now works for you (after creating a new project)?

By ensuring the new project does not have the HermiT /project/ in its classpath, only the HermiT /jar/.

I agree that Eclipse can glitch, but I do not think that this is a good reason to hard-code (particularly the version) values.

Indeed. Now that we know what's going wrong, I'm going to remove the hard coding.