We really only care about jBPM, and as of now, we
build it against M2. M2 was depending on mvel snapshot, so it
started breaking when new snapshots were introduced.
I am not a big believer in snapshots for coordinating complex
products like Drools with many moving pieces. I voiced this to
Mark in the past, and I need to discuss this with you when we
have time.
Mike did an API change to fix the MVEL performance issues and
releases a snapshot for us to try. I then had to update Drools and
jBPM to work against this new api. There was an issue with jBPM's
pom that meant it wasn't seeing the latest MVEL snapshot and thus
wouldn't compile. Kris is aware and fixing, if not fixed already.
Just hope it doesn't complicate things as the mvel
snapshots change API regularly and our snapshots are
adjusted regularly to cope with those API changes.
Op 07-05-11 09:10, Antoine Toulme schreef:
It is by no means going to
help in any way for you to release. This is just
meant for us to be able to build and run Drools
while you guys figure out a solution.
This
nights mvel snapshot fixes jbpm (the one
from 3-MAY doesn't afaik).
Does that release (it's not a snapshot)
include those latest changes?
Not that I 've not been tempted (or
pressured from Mark) to try to release
mvel myself to move away from the
snapshot,
but without tag of the source code in git,
without a "yes, this revision is ok" from
Mike (the mvel lead), etc
this isn't the kind of dependency we want
to include in the final release and
support for 5 to 7 years.
Op 06-05-11 20:04, Antoine Toulme schreef:
We pushed out
this snapshot with a version for
now:
Looks like
MVEL lib is
screwed up on
master. Tried
to run test
scenario
Good Credit
History Only,
it failed with
following
errors:
Unable to
rebuild the
rulebase.
org.drools.rule.MVELDialectRuntimeData;
local class
incompatible:
stream
classdesc
serialVersionUID
=
8808844570772337501,
local class
serialVersionUID
=
2609855281272796208