Mic,
I agree. We need an API for assembling all that.
One thing that is not yet clear to me is "how self contained or not
the assets are?". So, if they are not totally self contained (ex: facts
used in a rule and its correstponding imports are in separate assets in
the attached example), who will be responsible for handling
dependencies? At which moment will we run the "validation" to know if
the assets are consistents?
Would it be good to schedule a VoIP call to discuss this design?
[]s
Edson
Michael Neale wrote:
Kris - find attached - its not complete, but it will give you a start
- very simple.
Edson - I don't think the assembly of these file assets into a binary
package should be done in an IDE specific way - as we will want to do
the same from:
a) the repo
b) just an api or a directory?
c) a list of Reader objects, combined with each "asset type"
I am thinking
c) is the most generic - so we have an "assembly" api - of which the
current olde stuff is a simple subset:
eg: PackageAssembler.loadFrom(PackageConfig conf, RuleSource[] inputs)
....loadFrom(RuleSource ...) (for accumulating)
RuleSource is basically a Reader, plus some meta data to tell it if it
is a brl, or function, or rule, or dsl, or decision table, or whatever !
Then to satisfy a and b, and the IDE - we just have different adapters
to produce the RuleSource objects ?
Not sure if this should augment PackageBuilder or not - currently
package builder is kind of lower level, but I guess this could be part
of it (but is this API bloat? )
Basically it would feed the PackageBuilder api, so its really a front
end of sorts.
Thoughts ?
Mostly this package assembler would NOT be called directly by users -
but by tools (eg ant, IDE, repo deployer) that users use, whereas the
PackageBuilder is designed for use as it is now.
Michael.
On 3/7/07, *Kris Verlaenen* <kris.verlaenen(a)gmail.com
<mailto:kris.verlaenen@gmail.com>> wrote:
Sure, seems doable. Could you upload a zip containing a larger
example maybe? I was thinking about some rule files (one for each
rule, syntax exactly like current drl?), which implicitly refer to
stuff that is defined in the package file (imports, globals, anything
else), functions (also in a separate file I assume), etc.
So something to test the builder with: if I'm able to parse that set
of files, the builder would be supporting all important features :)
Kris
On 3/6/07, Michael Neale <michael.neale(a)gmail.com
<mailto:michael.neale@gmail.com>> wrote:
> Kris, I updated this JIRA:
>
>
http://jira.jboss.com/jira/browse/JBRULES-568
>
> Can you take a look, tell me if it makes sense, and if its
doable. Probably
> could be split into 2 if you like (one for DroolsBuilder, one
for the GUI).
> This is critical for BRMS integration, BUT, it is useful even
without a BRMS
> (eg this GUI coudl provide a hook to fire of the ant task to
compile the
> rules into a deployable binary package).
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @