name
by Mark Proctor
So it's over a year since we changed the name from Drools to JBoss
Rules. Personally I really dislike <Vendor Name> + <Generic Name> naming
schemes; especially so for Open Source projects. It's not the vendor
prefix I dislike, as that adds weight in corporate brand recognition,
but the generic postfix - leaving you no choice but to refer to the
project by the full name "JBoss Rules" in all communication and
throughout that communication; which I find tiresome. Where as ideally,
say in a presentation, you introduce the project as JBoss + <Strong
Name> first and then further references in your presentation can just
use the shortened <Strong name>; emails on the mailing list, being more
casual, can just drop to the shortened <Strong Name> straight away. It's
not just a lazyiness of having to use two words, but I feel it makes it
generally easier on the ears and eyes. With 4.0 coming up we have taken
the next steps into the world of Declarative programming, so was
thinking of JBoss DRules or JBoss D-Rules or JBoss drules - allowing the
DRules to be used standalone to refer to the project in more casual
communication. Anyone have any thoughts on a year of the "JBoss Rules" name?
Mark
17 years, 6 months
Re: [rules-dev] name
by Dou Hu
ILog JRules works pretty well. Why not JBoss Drools? Problem with JBoss Rules is we cannot just say "Rules" since it's to generic.
From: Mark Proctor[mailto:mproctor@codehaus.org]
Sent: Thursday, June 7, 2007 11:46 PM -07:00
To: Rules Dev List [rules-dev(a)lists.jboss.org]
Subject: [rules-dev] name
So it's over a year since we changed the name from Drools to JBoss
Rules. Personally I really dislike <Vendor Name> + <Generic Name> naming
schemes; especially so for Open Source projects. It's not the vendor
prefix I dislike, as that adds weight in corporate brand recognition,
but the generic postfix - leaving you no choice but to refer to the
project by the full name "JBoss Rules" in all communication and
throughout that communication; which I find tiresome. Where as ideally,
say in a presentation, you introduce the project as JBoss + <Strong
Name> first and then further references in your presentation can just
use the shortened <Strong name>; emails on the mailing list, being more
casual, can just drop to the shortened <Strong Name> straight away. It's
not just a lazyiness of having to use two words, but I feel it makes it
generally easier on the ears and eyes. With 4.0 coming up we have taken
the next steps into the world of Declarative programming, so was
thinking of JBoss DRules or JBoss D-Rules or JBoss drules - allowing the
DRules to be used standalone to refer to the project in more casual
communication. Anyone have any thoughts on a year of the "JBoss Rules" name?
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
17 years, 6 months
Who is in charge of Rules Management System development?
by Andrew Kinard
Hello all,
I'm new to this list, but I've been using JBoss Rules (Drools) for
about 2 years. I'm interested in alpha/beta testing the JBoss
Business Rules Management System in whatever form it currently has.
Who is in charge of development for this portion of the JBoss Rules
project? Can I get a copy of the current development release?
Regards,
Andrew Kinard
Cisco Systems, Inc.
17 years, 6 months
checked in ROM changes for BRMS
by Michael Neale
That means that deep nesting of constraints that span fields can be done on
the web GUI.
I also had to break some compatability with the last milestone, but it is a
milestone, so that can happen.
17 years, 6 months
Possible Bug: Nodes of inherited types with drools.getActivation().remove()
by Arjun Dhar
Hi,
I'm noticing very strange behaviour on JBoss Rules 4. (Havnt confirmed on 3).
Setup:
-------
1. CreateClasses
Class ChildA1 --<Extends>--> A --<Extends>--> Base
Class ChildA2 --<Extends>--> A --<Extends>--> Base
(Base has some attribute which is obviously inherited by A1 & A2)
2. Make a collection of such objects (ChildA1, ChildA2 & A)
I make a JDK 1.5 style "List<Base>", and put A1 & A2 into that.
{I was experimenting in measuring performance differce between inherited/Child
Node types Vs using attributes on A}
3. Later I take this list and assert into a StaelessSession.
The Bug(s): ( So I think :o) ), n please dont say its a feature... kidding!
---------------------
Rule USE CASE - I:
rule "Test A with attrib 1"
salience 150
no-loop true
when
a1: A(attrib=="type 1")
then
...
drools.getActivation().remove();
end
rule "Test A with attrib 2"
salience 150
no-loop true
when
a1: A(attrib=="type 2")
then
...
drools.getActivation().remove();
end
Note: There was another rule that called "modify()" to modify the state of
another attirbute, which would cause the rule fire over the object again, so I
used "drools.getActivation().remove(); " to ensure that once a rule fired for
an object(activation) it would not fire for that Fact again.
The Bug --> Even if I had two instances of A, one with attrib="type 1" and the
other with attrib = "type 2", only one would fire intermittanly for repeated
input requests.
This would not happen if I did not use "drools.getActivation().remove(); " but
I need to or else rules fire over the same object. But if i use it then a rule
gets deactivated without firing.
:o(
Please Help! (I'm sure if this Case is solved or explained I'll take on the
rest)
17 years, 7 months
Jboss snapshot repo
by Geoffrey De Smet
I took a quick look at seam and richfaces, and it looks like it might be
interesting to add this to the <repositorie> entry in the parent pom:
<repository>
<id>jboss-snapshots</id>
<url>http://snapshots.jboss.com/maven2/</url>
</repository>
--
With kind regards,
Geoffrey De Smet
17 years, 7 months
