[This may be a discussion to move to dev.]
The project test set up pre-dates use of Maven and indeed could probably
follow conventions better. However, changing that would be a lot of work
given that there are around 3000 (about 16Mb in total) test resources
used across the various systems. Such a change is unlikely to happen in
the near future, though perhaps something to consider in any future move
towards e.g. jena 3.
For your current development you will need to find a work-around I'm
afraid.
Presumably you could copy or symlink the testing directory into your
project to at least enable you to proceed, even if that's not a
satisfying approach.
Many of the tests probably use the FileManager to load the test
data/test results and you can register alternative Locators with the
FileManager as part of your test setup. Whether that is any cleaner than
the brute force work-around, and whether it would cover enough of the
tests to meet your needs I don't know.
Dave
On 22/04/14 09:54, Sébastien Boulet wrote:
Hi all,
we are working on a new FRuleEngineI implementation I would like to run all
the jena-core tests on our implementation.
To do this, i have added a dependency in the jena-core test module :
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-core</artifactId>
<version>2.11.2-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
and i have configured the following test suite in my project. This test suite
register our engine implementation and add the
com.hp.hpl.jena.reasoner.test.TestPackage test suite.
import junit.framework.TestSuite;
import com.hp.hpl.jena.reasoner.rulesys.impl.FRuleEngineIFactory;
public class EngineTestPackage extends TestSuite {
public static TestSuite suite() {
// use my engine implementation JENA-679
FRuleEngineIFactory.setInstance(new MyEngineFactory());
return new EngineTestPackage();
}
private EngineTestPackage() {
super("myEngine");
addTest("reasoners",
com.hp.hpl.jena.reasoner.test.TestPackage.suite());
}
private void addTest(String name, TestSuite tc) {
tc.setName(name);
addTest(tc);
}
}
Then run the tests using maven
$ mvn test
The principle works but a lot of tests are failing because of the following
exception :
com.hp.hpl.jena.shared.NotFoundException: Not found:
file:testing/reasoners/owl/tbox.owl
at
com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:423)
at
com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:333)
at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:285)
at
com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.testResults(OWLConsistencyTest.java:119)
at
com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.runTest(OWLConsistencyTest.java:137)
The problem is that the tests resources are in a testing folder in the
jena-core module. So these resources are not included by maven in the test jar.
Is it possible to follow the maven convention and put all the jena-core test
resources in the src/test/resources folder ?
Regards
Seb
: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
Sébastien Boulet
Lead développeur
intactile DESIGN
: : Création d’interfaces subtiles : :
+33 (0)4 67 52 88 61
+33 (0)6 89 34 24 12
20 rue du Carré du Roi
34 000 Montpellier, France
www.intactile.com
Le 18 avr. 2014 à 16:57, Sébastien Boulet <[email protected]> a écrit :
It is ok.
Thanks Dave
: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
Sébastien Boulet
Lead développeur
intactile DESIGN
: : Création d’interfaces subtiles : :
+33 (0)4 67 52 88 61
+33 (0)6 89 34 24 12
20 rue du Carré du Roi
34 000 Montpellier, France
www.intactile.com
Le 18 avr. 2014 à 16:17, Dave Reynolds <[email protected]> a écrit :
Thanks, I've committed the changes from the patch.
If you can confirm that they look OK to you and then close the jira.
Dave
On 18/04/14 14:15, Sébastien Boulet wrote:
Ok,
i have just proposed a patch with these modifications.
https://issues.apache.org/jira/browse/JENA-679
Seb
: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
Sébastien Boulet
Lead développeur
intactile DESIGN
: : Création d’interfaces subtiles : :
+33 (0)4 67 52 88 61
+33 (0)6 89 34 24 12
20 rue du Carré du Roi
34 000 Montpellier, France
www.intactile.com
Le 15 avr. 2014 à 19:07, Dave Reynolds <[email protected]> a écrit :
On 15/04/14 14:55, Sébastien Boulet wrote:
Hi all,
i would like to use an alternative implementation of the FRuleEngineI. My
problem is that the FRuleEngineI is instantiated directly from two locations :
in com.hp.hpl.jena.reasoner.rulesys.FBRuleInfGraph
@Override
protected void instantiateRuleEngine(List<Rule> rules) {
if (rules != null) {
if (useRETE) {
engine = new RETEEngine(this, rules);
} else {
engine = new FRuleEngine(this, rules);
}
} else {
if (useRETE) {
engine = new RETEEngine(this);
} else {
engine = new FRuleEngine(this);
}
}
}
and in com.hp.hpl.jena.reasoner.rulesys.RETERuleInfGraph
@Override
protected void instantiateRuleEngine(List<Rule> rules) {
if (rules != null) {
engine = new RETEEngine(this, rules);
} else {
engine = new RETEEngine(this);
}
}
For now, if i want to use another FRuleEngineI, i have to sub class theses
classes for instantiating my own FRuleEngineI implementation. And since theses
classes (FBRuleInfGraph, RETERuleInfGraph) are instantiated directly by others
ones (GenericRuleReasoner, FBRuleReasoner, OWLFBRuleReasoner…), i will have to
sub class a lot of existing classes.
So my question is, is there an easiest way to do this ?
No. It's not be a usecase that's come up before. People have sometimes done
custom versions of FBRuleInfGraph or created new sorts of InfGraph but I'm not
aware of anyone previously replacing the forward engine across all existing
InfGraph types.
If not, i was thinking of introducing a singleton FRuleEngineIFactory (I kept
the useRETE flag for backward compatibility.) :
[Yeah the non-RETE engine and the useRETE flag ought to be removed sometime but
for now it's in there.]
public class FRuleEngineIFactory {
private static FRuleEngineIFactory instance;
[needs to be initialized :)]
public static void setInstance(FRuleEngineIFactory instance) {
FRuleEngineIFactory.instance = instance; }
public FRuleEngineIFactory getInstance() { return instance; }
public FRuleEngineI createFRuleEngineI(ForwardRuleInfGraphI parent,
List<Rule> rules, boolean useRETE) {
FRuleEngineI engine;
if (rules != null) {
if (useRETE) {
engine = new RETEEngine(parent, rules);
} else {
engine = new FRuleEngine(parent, rules);
}
} else {
if (useRETE) {
engine = new RETEEngine(parent);
} else {
engine = new FRuleEngine(parent);
}
}
return engine;
}
}
This factory might be used by
com.hp.hpl.jena.reasoner.rulesys.FBRuleInfGraph
@Override
protected void instantiateRuleEngine(List<Rule> rules) {
engine = FRuleEngineIFactory.getInstance().createFRuleEngineI(this,
rules, useRETE);
}
and by com.hp.hpl.jena.reasoner.rulesys.RETERuleInfGraph
@Override
protected void instantiateRuleEngine(List<Rule> rules) {
engine = FRuleEngineIFactory.getInstance().createFRuleEngineI(this,
rules, true);
}
And i could replace the factory instance by my own instance :
FRuleEngineIFactory.setInstance(new CustomFRuleEngineIFactory());
What do you think of that ?
Sure. That would enable the sort of plug point you are after without causing
knock on problems.
Dave
