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