mailing lists pagelout
by Mark Proctor
I'm not sure the current mailing lists page changes was a step forward:
http://www.jboss.org/drools/lists.html
It's not immediate obvious what's on the page and someone wanting to
subscribe to "dev" would have to scroll down to find out how, without
even knowing they would need to scroll down. The embedded forum would
probably make them think that was the last entry on the page. I think we
should probably revert this back.
Mark
15 years, 1 month
github dev model
by Mark Proctor
We've been monitoring github over the last few weeks. Github now makes
it trivial for people to work in their own forks and submit pull
requests. We have found that from time to time people don't rebase
properly or check their commits after a push, and thus end up
overwritting other people's work. We are thinking of trialing the
leuitenant model for a while, where just core people are responsible for
accepting and applying pull requests. With git's distributedd model,
this should hopefully work out well.
So from this point on, unless you are a core developer responsible for a
specific module, can I ask that you submit pull requests for future work?
thanks
Mark
15 years, 1 month
Tips for building - tip 1: run "mvn dependency:tree" on the modules you lead
by Geoffrey De Smet
Hi guys,
We should actively notify/teach each other about tips and tricks.
There's a lot we can learn from each other.
I'll start with a build tip:
The problem
========
- How bloated is the dependency tree of my module? This affects the
download zip size, but also the minimal jars needed to run.
- Are there dead dependency left in my module?
The solution
========
- First thing to understand is that it has to reviewed module by module
(focus on end-user modules such as drools-compiler, drools-camel-server,
guvnor-webapp, ...).
- Use the command *mvn dependency:tree*
Example
=====
Here's the output on drools-compiler.
I've annotated a couple of possible incidents which might or might not
be a problem.
It's hard to tell without someone with extensive drools-compiler
experience looking further into it.
drools-compiler [master] $ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building Drools :: Compiler 5.3.0-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.2:tree (default-cli) @
drools-compiler ---
[INFO] org.drools:drools-compiler:jar:5.3.0-SNAPSHOT
[INFO] +- org.drools:drools-core:jar:5.3.0-SNAPSHOT:compile
[INFO] | \- org.drools:knowledge-api:jar:5.3.0-SNAPSHOT:compile
[INFO] +- org.drools:drools-core:test-jar:tests:5.3.0-SNAPSHOT:test
[INFO] +- org.apache.felix:org.osgi.core:jar:1.4.0:provided
[INFO] +- org.apache.felix:org.osgi.compendium:jar:1.4.0:provided
[INFO] +- org.antlr:*antlr-runtime:jar:3.3*:compile
[INFO] +- org.antlr:*antlr:jar:3.3*:compile
*Incident* 1: maybe org.antlr:antlr-runtime:jar:3.3 is a subset of
org.antlr:antlr-runtime:jar:3.3 ? (antlr is wierd IIRC - so this is
probably not in this case)
[INFO] +- org.antlr:stringtemplate:jar:3.2.1:compile
[INFO] +- antlr:*antlr:jar:2.7.7*:compile
*Incident* 2: maybe antlr:antlr:jar:2.7.7 is a subset of
org.antlr:antlr-runtime:jar:3.3 ? (antlr is wierd IIRC - so this is
probably not in this case)
In general, dependencies with a non-namespaced groupId need to be
upgraded if possible.
[INFO] +- org.antlr:gunit:jar:3.3:test
[INFO] +- org.eclipse.jdt.core.compiler:ecj:jar:3.5.1:compile
[INFO] +- janino:janino:jar:2.5.15:compile
Note that janino is optional (output doesn't show that :( ) - no
problem here
[INFO] +- org.mvel:mvel2:jar:2.1-SNAPSHOT:compile
[INFO] +- com.thoughtworks.xstream:xstream:jar:1.3.1:test
[INFO] | \- xpp3:xpp3_min:jar:1.1.4c:test
[INFO] +- org.mortbay.*jetty*:jetty-embedded:jar:6.1.15:test
*Incident* 3: Wierd that drools-compiler would need jetty to test something?
[INFO] | +- org.mortbay.jetty:jetty:jar:6.1.15:test
[INFO] | | +- org.mortbay.jetty:jetty-util:jar:6.1.15:test
[INFO] | | \- org.mortbay.jetty:servlet-api:jar:2.5-20081211:test
[INFO] | \- javax.servlet.jsp:jsp-api:jar:2.1:test
[INFO] +- org.opensymphony.quartz:quartz:jar:1.6.1:test
[INFO] +- com.sun.xml.bind:jaxb-xjc:jar:2.2.1.1:provided
[INFO] +- com.sun.xml.bind:jaxb-impl:jar:2.2.1.1:provided
[INFO] +- javax.xml.bind:jaxb-api:jar:2.2.1:provided
[INFO] +- javax.xml.stream:stax-api:jar:1.0-2:provided
[INFO] +- javax.activation:activation:jar:1.1:provided
[INFO] +- net.java.dev.*glazedlists*:glazedlists_java15:jar:1.8.0:test
*Incident* 4: Wierd that drools-compiler would need a swing framework to
test something?
[INFO] +- junit:junit:jar:4.8.1:test
[INFO] \- org.mockito:mockito-all:jar:1.8.2:test
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1.951s
[INFO] Finished at: Wed May 11 15:09:09 CEST 2011
[INFO] Final Memory: 10M/309M
[INFO]
------------------------------------------------------------------------
Here's another example showing another type of incident:
drools-camel-server [master] $ mvn dependency:tree
...
[INFO] +- org.drools:drools-grid-impl:jar:5.3.0-SNAPSHOT:compile
[INFO] | +- org.apache.mina:mina-core:jar:2.0.1:compile (version
managed from 2.0.0-M6)
[INFO] | \- com.hazelcast:hazelcast:jar:1.8.5:compile
...
[INFO] +- org.apache.camel:camel-cxf:jar:2.4.0:compile
[INFO] | \- org.apache.cxf:*cxf-rt-frontend-jaxrs*:jar:2.2.9:compile
[INFO] | +- org.apache.cxf:cxf-common-utilities:jar:2.2.9:compile
[INFO] | +- org.apache.cxf:cxf-rt-transports-http:jar:2.2.9:compile
[INFO] | +- org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.9:compile
[INFO] | +- jaxen:jaxen:jar:1.1.1:compile
[INFO] | \- org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
...
[INFO] +- org.apache.cxf:*cxf-bundle-jaxrs*:jar:2.2.9:compile
*Incident* A: This cxf-bundle-jaxrs is an uber jar. */Uber jars (as
dependencies) are evil./*
An uber jar extracts the classes from other jars and zips them
(=aggregate) in itself.
This effectively kills maven's ability to only have 1 class of
something in your classpath.
It turns your classpath into box of chocolates: /you never know
what version of class file you'll get/.
Also, it bloats the classpath with things you don't need (like
jetty in this case)
and those cause havoc if you deploy it to some app servers.
[INFO] | +- aopalliance:aopalliance:jar:1.0:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
[INFO] | +- wsdl4j:wsdl4j:jar:1.6.2:compile
[INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
[INFO] | +- org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
[INFO] | +- org.apache.neethi:neethi:jar:2.0.4:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
[INFO] | +- org.springframework:spring-web:jar:2.5.6:compile
[INFO] | +- org.mortbay.jetty:*jetty*:jar:6.1.21:compile
[INFO] | +- org.mortbay.jetty:jetty-util:jar:6.1.21:compile
[INFO] | +- javax.ws.rs:jsr311-api:jar:1.0:compile
[INFO] | +- org.apache.abdera:abdera-core:jar:1.0:compile
[INFO] | +- org.apache.abdera:abdera-i18n:jar:1.0:compile
[INFO] | +- commons-codec:commons-codec:jar:1.3:compile
[INFO] | +- org.apache.abdera:abdera-parser:jar:1.0:compile
[INFO] | +- org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7:compile
[INFO] | +- org.apache.ws.commons.axiom:axiom-api:jar:1.2.7:compile
[INFO] | +- org.apache.abdera:abdera-extensions-json:jar:1.0:compile
[INFO] | \- org.apache.abdera:abdera-extensions-main:jar:1.0:compile
...
Also, if you're trying to solve such things on master, try upgrading the
dependencies first (not on a release branch - upgrading is risky!):
many issues in the poms tend to be identified and fixed in newer versions.
--
With kind regards,
Geoffrey De Smet
15 years, 1 month
Re: [rules-dev] please attach to JBRULES-3030
by Michael Anstis
Anybody know of the "hotline" to which Wolfgang refers?
He is having problems using JIRA on FF3.0.19 :(
Thanks,
On 13 May 2011 10:36, Wolfgang Laun <...(a)gmail.com> wrote:
> Hi,
>
> as this is a "blocking" issue, a regression from 3.1.1, I rely on your kind
> offer. Maybe you can also fill in that this is reported against 5.2.x. The
> lists weren't working there, either.
>
> There is some Red Hat hotline where one can deposit problems with the
> general infrastructure. Do you have the mail address?
>
> Thanks
> Wolfgang
>
>
15 years, 1 month
xdrl fixes/enhancements
by Pierre
Mark, All,
AFAIK, xdrl is used for systems to exchange rules (perhaps for storing too). This, as opposed to human use, for which XML can be quite awkward to say the least. This to say that putting readability as a major factor might make us miss the main point.
For humans<expr>status == state</expr> is nicer. However, for systems interaction it's pretty terrible. It's some form of half use of XML where the expression itself can only be validated or transformed with considerable efforts (e.g. regex) when xml tags would allow using standard XML tools (e.g. XPATH). I've got examples of this in the rule translation console: http://yieldrif.appspot.com/ (shameless plug!).
Let's have a look at other XML rule descriptions (please note that I don't imply that these are 100% valid expressions in their respective languages):
JessML
<pattern>
<name>Order</name>
<binding>o</binding>
<slot>
<name>total</name>
<test>
<type>eq</type>
<conjunction>and</conjunction>
<value type='VARIABLE'>__synth0</value>
</test>
<test>
<type>eq</type>
<conjunction>and</conjunction>
<funcall>
<name>></name>
<value type='VARIABLE'>__synth0</value>
<value type='INTEGER'>100</value>
</funcall>
</test>
</slot>
</pattern>
RIF-PRD
<formula>
<name>Order</name>
<formula>
<Equal>
<left>
<Var>total</Var>
</left>
<right>
<Var>-var-__synth2</Var>
</right>
</Equal>
<Equal>
<left>
<Var>total</Var>
</left>
<right>
<Expr>
<op>
<Const type="http://www.w3.org/2007/rif#iri">http://www.w3.org/2007/rif-builtin-predicate#numeric-greater-than</Const>
</op>
<args ordered="yes">
<Var>-var-__synth2</Var>
<Var>100</Var>
</args>
</Expr>
</right>
</Equal>
</formula>
</formula>
I hope this helps,
Pierre
------------------------------
Message: 6
Date: Tue, 10 May 2011 09:11:24 +0100
From: Mark Proctor<mproctor(a)codehaus.org>
Subject: Re: [rules-dev] xdrl fixes/enhancements
To:rules-dev@lists.jboss.org
Message-ID:<4DC8F32C.7080205(a)codehaus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/05/2011 09:07, Mark Proctor wrote:
> > On 10/05/2011 08:10, Veit Guna wrote:
>> >> Hi.
>> >>
>> >> Any chance that this could be reviewed and maybe integrated into the
>> >> release?
>> >>
>> >> https://jira.jboss.org/browse/JBRULES-2672
> > I'm in two minds on this. Edson and I are thinking of changing the xml
> > parser to just be:
> > <Pattern object-type="xxxx">
> > <expr>......</expr>
> > <expr>......</expr>
> > <expr>......</expr>
> > </Pattern>
> >
> > With any valid expression allwed in expr, i.e. any combinatino of ||,
> > &&, method calls, +, - etc. Which follows what we've done with free-form
> > drl.
> > Our current approach to normalising expressions in XMl isn't working too
> > well, and the more we extropolate that the worse it gets:
> > <dro:pattern object-type="String">
> > <dro:and-constraint-connective>
> > <dro:field-constraint field-name="this">
> > <dro:literal-restriction evaluator="!=" value="null"/>
> > </dro:field-constraint>
> > <dro:field-constraint field-name="this.toLowerCase">
> > <dro:literal-restriction evaluator="==" value="true"/>
> > </dro:field-constraint>
> > </dro:and-constraint-connective>
> > <dro:from>
> > <dro:expression>fctv_17263.getHeaderValues("X-My-Header");
> > </dro:expression>
> > </dro:from>
> > </dro:pattern>
> >
> > But I do recognise that you patch might give a lifeline to existing XML
> > users....
I should add that I ripped out most of the handler validation
parent/peer stuff already. This was necessary to get the new compiler
working, and<expr> actually already works, see DumperTest.
<lhs>
<forall>
<pattern object-type="State">
<field-binding field-name="state" identifier="state" />
</pattern>
<pattern object-type="Person">
<expr>
status == state
</expr>
<field-binding field-name="likes" identifier="likes" />
</pattern>
</forall>
</lhs>
Mark
> > Mark
> >
>> >> _______________________________________________
>> >> rules-dev mailing list
>> >> rules-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>
>> >>
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
15 years, 1 month
docbook - ensuring images fit correctly in PDF
by Michael Anstis
If you've ever struggled to get an image to scale correctly in the PDF form
of our documentation I "discovered" "scalefit" this afternoon.
Set it to "1" on your imagedata and it'll fit perfectly in HTML and PDF :)
<mediaobject>
<imageobject>
<imagedata fileref="whatever.png" format="PNG" scalefit="1" >
</imagedata>
</imageobject>
</mediaobject
15 years, 1 month
PackageDescr.getFactTemplates()
by Michael Anstis
Hi,
Does anybody know where the captioned has moved to?
The Eclipse plugin used this to help with auto-completion.
It was removed from PackageDescr in drools-compiler in commit
c5378c39fb501d1f4518f0670b0656de5ea506ce on 23rd March 2011 (by Edson)
The consuming code (org.drools.eclipse.editors.DRLRuleEditor) in the Eclipse
plugin was removed in commit b81ab95c483d924ed597e988183a9db0252e384d on
28th March (by Edson), but other dependant code in the Eclipse plugin now
throws a NPE as "templates" have not been initialised.
Currently DRL auto-complete within the Eclipse plugin does not work and
throws a silent NPE and users are blissfully unaware.
With kind regards,
Mike
15 years, 1 month
Drools persistence + OpenJPA
by Filipon
Hi all!
Does anyone have tested the persistence on jbmp5 with OpenJPA? I'm having
some trouble with it, specifically with the way OpenJpa persist the data.
For example, some information miss on my ProcessInstanceInfo table because
the @PreUpdate function of this class is never raised if I choose OpenJPA as
ma JPA Provider. With Hibernate I don't have this problem (even if I have
some others)
Thanks!
--
View this message in context: http://drools.46999.n3.nabble.com/Drools-persistence-OpenJPA-tp2920345p29...
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.
15 years, 1 month
