I agree we should strongly prefer not to use mvel snapshot's if we
can avoid it (which we can't for this release :( ).
We'd need to do some preliminary testing agains the snapshot anyway,
before we can push a release. Otherwise you are releasing for every
single issue you find in MVEL.
Mark
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