The "expose them in core first, later in api" is a good thing. +1 there.
I was talking about a different aspect:
once we move it to api, sooner or later, the AbstractResource trick
could prevent binary backwards incompatibility on the api module if
users have a custom Resource implementation.
For example, this could heighten the change that jbpm 5.2 (which would
requires drools 5.4) would work with drools 5.5 too (if the later adds a
method on the Resource interface and jbpm implements it).
Op 12-09-11 10:18, Esteban Aliverti schreef:
Ok, I will move these attributes to drools-core (InternalResource).
Later, we can think about move them to drools-api.
Geoffrey, I like your idea, but I think that is not the "drools way"
:). What Mark wants is to always add new stuff in core and later, when
it is stable enough, publish it through drool-api. I agree with this,
but when the improvements are only useful for api users (name and
description are not used in drools-core in any way) I find this a
little bit cumbersome. The feature is never going to be used if it is
no exposed. Users must always cast Resource to InternalResource if
they want to use this (And I see a lot of these casts even inside
drools-core).
But, as a general solution, I'm not against the implementation of new
features in core first and the exposure on api later.
Best Regards,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Esteban Aliverti
- Developer @ http://www.plugtree.com <http://www.plugtree.com>
- Blog @ http://ilesteban.wordpress.com
On Mon, Sep 12, 2011 at 9:04 AM, Geoffrey De Smet
<ge0ffrey.s...@gmail.com <mailto:ge0ffrey.s...@gmail.com>> wrote:
We could use Abstract* class trick (the Collections api does it
and I use it a lot in Planner):
drools-api has:
interface Resource
abstract class AbstractResource implement Resource
And the javadoc on interface Resource clearly states that they
should extend AbstractResource when implementing a custom
Resource. Same for the reference manual.
(Similar to interface List and class AbstractList)
Then if any new method is added, the AbstractResource
implementation should try to provide a reasonable default that
works (but is possibly not as efficient as a specific implementation).
As a result, any custom Resource that extend AbstractResource
needed be changed immediately (but might want to in time to
implement a more efficient implementation).
And, more importantly, we don't break binary backwards
compatibility on *api (unless they implemented Resource directly)
so less chance of "impossible to fix" if you have a project with a
dependency A and B
where A and B themselves depend on different drools versions,
as you can just use the "highest version" between those 2
dependencies.
Op 12-09-11 07:51, Mark Proctor schreef:
On 12/09/2011 06:36, Esteban Aliverti wrote:
Ok, I thought #droolsdev was ok too. Sorry about that.
The idea to have a 'name' and a 'description' attribute in
<Resource> elements inside a change-set is to tag them or to add
them some human-friendly information so you can refer to it not
using the URL or the name of the asset (could be duplicated in
different packages), but with a name and a description.
These changes are 100% end-users oriented, that is why I put
those attributes in API. End users applications (like Guvnor)
could take advantages on these new attributes.
You can add them to the xml, and have that set them on the
InternalResource. We can migrate to public apis over time, I just
want people to take a much more conservative outlook on -api changes.
Mark
So, a change-set now could look like this (the new attributes
are not mandatory):
<change-set>
<add>
<resource *name="Loan Rules" description="Rules about loans"*
type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
<resource *name="Risk Rules" description="Rules about Risk
evaluation"* type="DRL"
source="http://someHost:1234/someOtherDRLResource.drl"/>
</add>
</change-set>
These attributes can also be used in Spring's configuration:
<drools:kbase id="kbase1" node="node1">
<drools:resources>
<resource *name="Loan Rules" description="Rules about loans"*
type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
<resource *name="Risk Rules" description="Rules about Risk
evaluation"* type="DRL"
source="http://someHost:1234/someOtherDRLResource.drl"/>
</drools:resources>
</drools:kbase>
WDYT?
Best Regards,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Esteban Aliverti
- Developer @ http://www.plugtree.com <http://www.plugtree.com>
- Blog @ http://ilesteban.wordpress.com
On Mon, Sep 12, 2011 at 6:25 AM, Mark Proctor
<mproc...@codehaus.org <mailto:mproc...@codehaus.org>> wrote:
Shoudn't name and description be on InternalResource, not on
Resource?
I think it's time to put a restriction on changes to "-api".
Feel free
to change core/compiler etc, but if you want to change -api
we'll need
to propose it here.
Mark
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
