I agree we should strongly prefer not to use mvel snapshot's if we
can avoid it (which we can't for this release :( ).
Op 07-05-11 18:31, Antoine Toulme schreef:
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.
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