On 22/04/14 15:17, Sébastien Boulet wrote:
Thanks for your answer.
For now, i will copy the testing directory in my project.
Probably the best option, certainly the quickest.
More backgound:
There are a number of test suites that run from testing/ for different
modules. e.g. the SPARQL WG test suite, RDf WG test suite, .... Those
are assumed to be located in files (with URLs at least). It would be
possible and non-trivial to convert to work out of "resources", maybe
with a adapter for the Stream Manager which sits on the model.read path.
But for now, it means the <type>tests</type> artifacts are really there
to pass the testing frameworks between modules, and not enable the tests
to be run outside a checked-out Jena codebase.
Andy
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 22 avr. 2014 à 11:26, Dave Reynolds <[email protected]> a écrit :
[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
