RIF PRD translation effort to/from Drools & Jess
by pdl＠agh.edu.pl
Hi all,
I've been working on translators between RIF-PRD, DroolsML and JessML.
I've put the translators in the form of XSLT stylesheets on the following
web site along with samples of rules written in the above languages. I
would greatly appreciate feedback/comments/tips/help on making these
translators more reliable and accurate.
Web site: yieldrif (dot) appspot (dot) com (in case emails containing
URLs are bounced off)
Please note that this is free hosting and has some limitations. Feel free
to add/comment content on this web site or drop me a line. What would be
really helpful is a XML Schema for DroolsML and also the rhs to be in XML
as opposed to drools code.
I look forward to hearing from you,
Pierre
15 years
Re: [rules-dev] RIF PRD translation effort to/from Drools & Jess
by pdl＠agh.edu.pl
Adrian, Wolfgang, all,
I've had issues translating the RHS java code for instance (c.f. XSLT
stylesheet).
It would be nice to have the translation protocol to/from RIF provided
with the specification, at least for the main rule engines.
All the best,
Pierre
On 2/10/2011 8:07 AM, Wolfgang Laun wrote:
On 9 February 2011 22:11, Edson Tirelli <ed.tire...(a)gmail.com
<mailto:ed.tire...@gmail.com>> wrote:
Pierre,
Good to see works like yours being done.
Drools has an internal canonical model that we use to round
trip rules between the syntaxes we support. The best way of
supporting "RIF" in Drools is to simply add a parser that parses
RIF and populates the canonical model. From that we have a DRL
"dumper" that generates DRL, enabling the RIF->DRL translation.
Also, if we create a RIF "dumper", one can then generate RIF rules
from the canonical model, enabling DRL->RIF translation. That
assumes that there is a 1-to-1 semantic mapping between RIF and
DRL (I believe there is, but didn't checked).
Do you mean that all of RIF can be expressed in DRL? Then I'd agree.
But you can't express all of DRL in RIF.
-W
A translator RIF-PRD2DRL should be "conformant RIF-PRD consumer" as in the
recommendation
<http://www.w3.org/TR/2010/REC-rif-prd-20100622/#Semantics-preserving_tran...>.
A translator DRL2RIF-PRD should be a "conformant RIF-PRD producer".
For example, a heuristic validation (test-based) may work in a
"round-trip" i.e. take a Drools ruleset R, do R_RIF= DRL2RIF-PRD(R) then
R1= RIF-PRD2DRL(R_RIF) and compare answers by running Drools on R and R1
When Wolfgang said that not all Drools constructs can translate to RIF-PRD
I assume he is thinking to some lets say "nonlogical" or "procedural"
Drools constructs. However, because RIF can encode any partial recursive
function, DRL2RIF should be always possible i.e. when translating a ruleset
from Drools, one may obtain not only PR rules but, in addition some RIF-BLD
rules too.
Therefore I assume that there is very nice work to do.
-.Adrian Giurca
15 years
Re: [rules-dev] RIF PRD translation effort to/from Drools & Jess
by pdl＠agh.edu.pl
Edson,
I just don't have time to go into the Drools code myself (done that in the
past though, so I know a little bit about it). To go the way you describe,
I suggest filling an application to the google summer of code
(http://www.google-melange.com/) or something similar. I seem to remember
Drools has already taken part in this program so I assume you're familiar
with it.
If I can help with the above, please let me know.
Pierre
Edson Tirelli
Wed, 09 Feb 2011 13:12:01 -0800
Pierre,
Good to see works like yours being done.
Drools has an internal canonical model that we use to round trip rules
between the syntaxes we support. The best way of supporting "RIF" in
Drools
is to simply add a parser that parses RIF and populates the canonical
model.
>From that we have a DRL "dumper" that generates DRL, enabling the
RIF->DRL
translation. Also, if we create a RIF "dumper", one can then generate RIF
rules from the canonical model, enabling DRL->RIF translation. That
assumes
that there is a 1-to-1 semantic mapping between RIF and DRL (I believe
there
is, but didn't checked).
Edson
15 years
RIF PRD translation effort to/from Drools & Jess
by pdl＠agh.edu.pl
Mark, Andrew, Guys,
Yes working with DRL may be better for Drools indeed. But the only way I
see this working is by implementing this directly in the code of Drools.
That's not practical for me, hence I "simply" export/import the rules
in/from XML. This way I can focus on the translation.
If someone would give me pointers on an easy way to work with DRL, I'd do
that of course.
I assume you already had discussions on XML (or anything more structured
and widely spread than DRL) as working format so I won't be going there :)
All the best,
Pierre
On 09/02/2011 16:46, Mark Proctor wrote:
> On 09/02/2011 08:40, pdl at agh.edu.pl wrote:
>> Hi all,
>>
>> I've been working on translators between RIF-PRD, DroolsML and JessML.
>> I've put the translators in the form of XSLT stylesheets on the
following
>> web site along with samples of rules written in the above languages. I
>> would greatly appreciate feedback/comments/tips/help on making these
>> translators more reliable and accurate.
>>
>> Web site: yieldrif (dot) appspot (dot) com (in case emails containing
>> URLs are bounced off)
>>
>> Please note that this is free hosting and has some limitations. Feel
free
>> to add/comment content on this web site or drop me a line. What would
be
>> really helpful is a XML Schema for DroolsML and also the rhs to be in
XML
>> as opposed to drools code.
> Is this converting to Drools DRL? or to our deprecate, unmaintained, out
> of date and very old XML?
Sorry someone just read that sentence back to me, and it probably read
very wrong.
Let me start again. First up great work, it's good to see any
interchange work happening, it's not easy stuff. And I can't wait for us
to figure out how to get this working directly against our more recent
DRL :)
Mark
> Mark
>> I look forward to hearing from you,
>> Pierre
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
15 years
The droolsjbpm repository split-up and directory structure changes - PLEASE READ
by Geoffrey De Smet
Hi guys,
I 'll be doing some changes that will *force you to delete your git
working directory and all your git forks*.
I am sorry to put you through this, but it will make development life
better afterwards.
Contact me if the dates don't work out for you. Suggestions, ideas are
still welcome of course.
Please forward this message to any droolsjbpm developer not reading the
mailing list.
*Please do not make any build changes in the next 2 weeks, because those
changes might be lost.*
Mail me the build changes and I 'll do them for you and make sure they
aren't lost.
What will change?
* We ‘ll split up the monolithic droolsjbpm repository into a few
smaller repositories.
o We will preserve history per repository.
o The droolsjbpm repository will be retired but not deleted.
o Your guvnor clone won’t take 1.2 GB diskspace anymore.
* We ‘ll split up the monolithic build into a few smaller builds
(one per repo).
o You’ll be able to build/test just guvnor.
+ Even if drools-core doesn’t build/test.
* We ‘ll split up the monolithic hudson job into a few smaller jobs
(one per repo).
o If the drools-eclipse guys break a test, the guvnor job will
still be blue (and vica versa), only the drools-eclipse job
will be red.
o The build will be broken less and the cause will be easier
to identify and fix.
o Hudson won’t be red all the time anymore.
* We ‘ll make some directory name changes, so artifactId’s are less
confusing and more correct
o For example: drools-server(which has nothing to do with the
guvnor server) will be renamed to drools-camel-server
* We ‘ll clean up some general things, like file endings, etc
New repository’s
We will end up with these repositories after the split-up is completely
done:
* repo droolsjbpm-parent
o The parent pom (common stuff for the build)
* repo droolsjbpm-knowledge
o The public API and the internal API
* repo drools
o The rule engine modules
* repo jbpm
o The workflow engine modules
* repo drools-planner
o The planning optimizer modules
* repo droolsjbpm-integration (groupId org.droolsjbpm)
o Integrating Drools & jBPM with Seam, Spring, Camel, etc
* repo guvnor
o The web app to manage Drools & jBPM repositories
* repo droolsjbpm-eclipse
o The eclipse plugin for drools & jbpm
* repo droolsjbpm-dist
o Installer, aggregated assemblies, ...
New structure guidelines
* Docs and examples
o Must be updated together with the main and test code => same
pull request!
o Are in the repo that provides their functionality
o Are build (if fast enough) together with the rest
+ docs might be slow, we ‘ll see if we need to only do
them in the -Dfull build
* We prefer long repo names, because
o Project dirs must much artifactId
<http://java.dzone.com/articles/maven-tip-project-directories>
o Forking “eclipse” on github to myUsername would confuse (as
it’s not eclipse but droolsjbpm-eclipse) and clash with
eclipse itself.
+ Not https://github.com/etirelli/eclipsebut
https://github.com/etirelli/droolsjbpm-eclipse
New dir structure
* repo droolsjbpm-parent (groupId org.droolsjbpm)
o This contains one pom, which is the parent pom for all the
general build stuff.
o artifactId renamed from drools
o Includes shell script (and maybe bat script) to clone all of
these repo’s
o droolsjbpm-bom ? - TODO research bill of materialpoms
* repo droolsjbpm-knowledge (groupId org.droolsjbpm)
o knowledge-api
+ renamed from drools-api
# GAV backward independency => TODO document
+ groupId org.droolsjbpm
o knowledge-internal-api
+ empty for now, will be filled by markp, krisv, etc
o TODO later one day: knowledge-core
+ extracted from drools-core
o TODO later one day: knowledge-builder
+ extracted from drools-compiler
o TODO later one day: knowledge-persistence
+ extracted drools-persistence-jpa
o droolsjbpm-introduction-docs
+ renamed drools-docs-introduction
* repo drools (groupId org.drools)
o drools-core
o drools-builder
+ renamed from drools-compiler
o drools-persistence
+ renamed drools-persistence-jpa
o drools-jsr94
o drools-clips
o drools-templates
o drools-decisiontables
o drools-verifier
o drools-expert-docs
o drools-fusion-docs
o drools-expert-examples
+ renamed from drools-examples-drl
o drools-fusion-examples
+ renamed from drools-examples-fusion
* repo jbpm (groupId org.jbpm)
o will be moved from the krisvgithub account to the
droolsjbpmgithub organization
o no other changes for now
* repo guvnor (groupId org.drools or org.droolsjbpm.guvnor or
org.guvnor)
o guvnor-repository
+ renamed from drools-repository
o guvnor-repository-jcr-connector
+ renamed from drools-repository-jcr-connector
o guvnor-repository-jackrabbit-connector
+ renamed from drools-repository-jackrabbit-connector
o guvnor-repository-modeshape-connector
+ renamed from drools-repository-modeshape-connector
o knowledge-ide-common (TODO)
+ renamed from drools-ide-common
+ eats drools-factconstraint (esteban working on that)
o guvnor-api?
+ TODO needed?
o guvnor-gwtclient
+ extracted from drools-guvnor: all the GWT stuff
o guvnor-webapp
+ renamed from drools-guvnor
o guvnor-examples
+ renamed from drools-examples-brms
# currently disabled, might be removed and
rewritten from scratch
o guvnor-docs
+ renamed from drools-docs-guvnor
o guvnor-modules
+ moved modules (under drools-guvnor)
+ includes bulk-import-util
# TODO later: remove the module and get the
feature as a button in the GWT gui
* repo droolsjbpm-eclipse (groupId org.drools - might be changed
over time)
o org.drools.eclipse (might be changed over time)
o org.drools.eclipse.task (might be changed over time)
o org.guvnor.tools (might be changed over time)
o org.drools.updatesite (might be changed over time)
* repo droolsjbpm-integration (groupId org.drools or
org.drools.integration)
o drools-camel
o drools-camel-server
+ renamed from drools-server
o drools-pipeline
+ (deprecated)
o drools-seam
+ drools-seam2
# TODO do we want to keep this?
+ drools-seam3
o drools-spring
o drools-ant
o drools-maven-plugin
o osgi-bundles
o drools-rhq-plugin
o drools-simulator
o drools-grid
o drools-rhq-plugin
o knowledge-integration-docs
+ renamed from drools-docs-integration
* repo drools-planner (groupId org.drools.planner)
o drools-planner-core
o drools-planner-examples
o drools-planner-docs
+ renamed from drools-docs-planner
o drools-planner-assembly
* repo droolsjbpm-dist(groupId org.droolsjbpm)
o Assemblies? Or per repo?
+ Per repo, but make src etc here
o TODO later: uber documentation?
o install-stale
+ renamed from install because it’s been moved into jbpm.
Implications: a very disruptive change
* Difficult copying patches to 4.x, 5.0 and 5.1...
o But not impossible, as I 'll first all directories to the
new repo, before renaming them
+ so the old release branches/tags will still have the
old directory names
+ and git is suppose to be able to deal with directory
name changes of branches
* Some Maven GAV (groupId, artifactId’s) change
o Everything will be documented in the release notes
While we’re freezing anyway:
* Before the move:
o Simplify & stabilize build
+ Simplify javadocs generation
# keep groups if possible, but not required
* Before pushing the moved part into a new repo:
o [Guvnor] Remove all the generated GWT files from the history
+ because it smaller repo makes a faster clone.
+ $ git filter-branch --tree-filter
'~/removeGeneratedGwtScript.sh' --all
# TODO check removeGeneratedGwtScript.sh vs
https://github.com/droolsjbpm/droolsjbpm/blob/5.0.x/drools-guvnor/build.xml
# rm -f
src/main/webapp/org.drools.guvnor.Guvnor/**/*.gwt.rpc
# rm -f
src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.html
# rm -f
src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.js
# rm -f
src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.xml
* Before allowing others to touch the new repo:
o All line endings to \n (unix), except *.bat files
+ https://issues.jboss.org/browse/JBRULES-2855
o All \t (tabs) in *.java files replace by 4 spaces
+ all \t (tabs) in *.xml files replace by 2 spaces
o All copyright should start with /* and not /** because a
copyright is not a valid javadoc.
o Strip the @author from each *.java
+ It’s not accurate at all anymore (=bitrot).
# Actually, most of the time it’s the original
author, not the current guy who currently knows
what it does.
# Git history is much, much more accurate.
* Statistics generated by ohloh and github.
* Git can distinguish the author from the
committer
+ Credit is given on the team page and the blog.
# These pages are actually read by outsiders.
# Contact me to improve your entry on the team
page. Don’t be shy.
+ Motivation (must see video): How to get a healthy open
source project?
http://video.google.com/videoplay?docid=-4216011961522818645#
How will this change happen?
* I'll split-off drools-planner tomorrow 8-FEB-2011
o To flesh out the split-up process.
o I don't think anyone forked and changed these modules.
* I'll split-off droolsjbpm-eclipse Wednesday 9-FEB-2011
o I don't think anyone forked and changed these modules.
* I'll probably split-off guvnor Friday 11-FEB-2011
o *Get your guvnor fork changes merged into master by Thursday
10-FEB-2011.*
o Contact me if this date is a problem.
* Other splits-off will be announced later.
--
With kind regards,
Geoffrey De Smet
irc.codehaus.org #drools
15 years
JPAWorkingMemoryDbLogger.updateProcessLog uses hard coded query (likely hibernate specific)
by jschmied
in this function there is a hardcoded query string :
List<ProcessInstanceLog> result = getEntityManager().createQuery(
"from ProcessInstanceLog as log where log.processInstanceId = ? and log.end
is null")
.setParameter(1, processInstanceId).getResultList();
it gives the following error:
<openjpa-2.0.1-r422266:989424 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: "Encountered "from" at
character 1, but expected: ["DELETE", "SELECT", "UPDATE"]." while parsing
JPQL "from ProcessInstanceLog as log where log.processInstanceId = ? and
log.end is null". See nested stack trace for original parse error.
This should be a named query and put in orm.xml.
Thanks!
juergen
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/JPAWorkingMemoryDbLog...
Sent from the Drools - Dev mailing list archive at Nabble.com.
15 years, 1 month
drools-guvnor\modules
by Michael Anstis
Hi,
We're in the process of rationalising Guvnors code-base including the
removal of GWTEXT and came across use of GWTEXT's Grid in
drools-guvnor\modules\properties.
Anybody care to claim ownership? Otherwise we're probably delete it (if not
all drools-guvnor\modules) s we don't want to refactor stuff no longer
needed.
X-posted in case knowledge of the module has moved to the user list only.
With kind regards,
Mike
15 years, 1 month
