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.
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):
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.