[rules-dev] Re: design thoughts: package configuration and asset loading API

[Edson Tirelli]

    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 at gmail.com 
> <mailto:kris.verlaenen at 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 at gmail.com
>     <mailto:michael.neale at 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 @ www.jboss.com