testDynamicFunction JUnit test fails
by Déry, Nicolas
Hello Conan, this is cyruscode.
in response to your request yesterday, heres the description of the problem..
the testDynamicFunction test fails in org.drools.integrationTests.ReteTest package
ive joined the stackTrace... and for that One test.. i don't get any console output...
but i join the console output of all the tests of the drools-compiler
have a nice day.
Nicolas Déry
Ingénieur logiciel stagiaire / Software engineer trainee
Kronos Incorporated
e: ndery(a)kronos.com
p: +1 (514) 345-0580 x 253
f: +1 (514) 345-0533
www.kronos.com
Une expertise reconnue pour optimiser votre capital humain et votre performance en affairesMC
Experts at Improving the Performance of People and Business(tm)
19 years
quick design questions to mull over - regarding the repo
by Michael Neale
BUT this also applies to the file structure for "packages" in a file
system/IDE (forget monolothic DRL for a moment - but instead imagine a
folder which is a rule package containing lots of rules).
(in no particular order);
Q1: Should DSL "language configurations" be stored as an "asset" inside a
package (ie a file, perhaps multiple ones of them?) - or are they an
attribute of a package?
Q2: The object model: should this be stored as an attribute of a package -
or just another asset of which there can be muliple ones uploaded (as a jar,
for instance).
This is needed for validation/tooling. Obviously in the IDE the classes will
be on the classpath, but in the repo they have to be stored somewhere.
Note versioning works well in all scenarios (subtle differences between a
package attribute and asset for versioning, but ignore them for now).
I have opinions, but wanted some discussion (attachment screenshot shows the
package managment screen).
19 years, 1 month
repo "schema" changes - FYI
by Michael Neale
>From time to time, I am changing/cleaning up the "node types" that the
repository uses while in development.
This may mean if you are playing with it you will need to blow away your
repo and let it create it (not bothering with migrations as I am still
cleaning it up).
I don't expect there to be many changes once it is finished. JCR lends
itself to pretty generic hierarchies, and it is resilient to additions of
properties etc.
As a happy co-incidence. the "CND" format used by Jackrabbit looks like
becoming the standard for "JCR2" (JSR-283 I think?) content repos - which
means it will be even easier to migrate between different vendors for the
database/rules repository.
Michael.
19 years, 1 month
Questions about DSL in 3.2
by Edson Tirelli
All,
I will reintegrate/implement DSL support in drools-compiler, as we
discussed before, as a pre-processor. I have some questions I would like
to have your opinion about:
Q1: Is there any reason for the DSL parser to be line based?
Q2: I will make keywords configurable, so you can say "regra" for
instance (in portuguese) instead of "rule", ok?
Q3: Peter: I'm thinking in copy/port the DSL tree that you created into
drools-compiler... I think we can leverage it to help create a better
parser for the DSL, ok?
Q4: do we need everything to be expandable in the DSL? or should we
simply passthrough anything that is not expandable directly as a chunk
to the DRL? Example:
DSL:
=====
...
regra ABC
se
...
entao
System.out.println( "BLABLA" );
fim
...
====
Ok, I know that no business user will ever write
System.out.println(), but it is just just an example. And the keywords
are in portuguese for you guys to understand it better... ;)
Thanks for the feeback.
[]s
Edson
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
19 years, 1 month
package and deployment versioning for repo (design thoughts)
by Michael Neale
Hi All.
Been working on package versioning etc, and it was really confusing me and
doing my head in.
Basically, it is possible to version the package as a whole (basically
"baseline") it - but this is really confusing from a users point of view.
each asset (rule) is also individually versioned - so this extra layer is
confusing (I can't quite work it out myself - NOT a good sign).
So - what I propose is the following:
a) the ability to "status change" all the assets in a package in one hit
b) changes to package "meta data" such as description are not versioned
per-se
c) for deployment, you "copy" (ie take a snapshot of) a package to a
deployment "area":
eg say we have a package foo.bar
we then take foo.bar, set the status to "PROD" and then copy it to
/deployments/foo.bar/DeploymentLabel eg Date...
so when we look at deployments, we see a list of packages, and under them
a list of deployment/snapshots (which mean whatever you want them to).
Simple - not unlike how SVN branches work. Of course, this deployment
copying is completely optional. Many people will simply be happy with
package level statuses, and individual versioning.
Versioning of the "parent" package is quite confusing (eg looking through
the history of package versions - it isn't easy of obvious to see what they
are for or restore them anyway - AND it has no parallel with SVN or other
file based version that I am aware of - perhaps in the future I will
resurrect it one day??).
Please share your thoughts, this is the parth I am going down for now. Its
taken me too long to get to this point ;)
Damn this is a lot of work, but it has to be, as we don't want the end users
to be sweating this stuff, it has to Just Work !
Michael.
19 years, 1 month
