Kris - find attached - its not complete, but it will give you a start - very simple.<br><br>Edson - I don&#39;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:
<br><br>a) the repo<br>b) just an api or a directory? <br>c) a list of Reader objects, combined with each &quot;asset type&quot; <br><br>I am thinking <br>c) is the most generic - so we have an &quot;assembly&quot; api - of which the current olde stuff is a simple subset:
<br>eg: PackageAssembler.loadFrom(PackageConfig conf, RuleSource[] inputs)<br>&nbsp;&nbsp;&nbsp; ....loadFrom(RuleSource ...) (for accumulating) <br><br>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 ! 
<br>Then to satisfy a and b, and the IDE - we just have different adapters to produce the RuleSource objects ? <br><br>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? )
<br>Basically it would feed the PackageBuilder api, so its really a front end of sorts.<br><br>Thoughts ?<br><br>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.
<br><br>Michael.<br><br><div><span class="gmail_quote">On 3/7/07, <b class="gmail_sendername">Kris Verlaenen</b> &lt;<a href="mailto:kris.verlaenen@gmail.com">kris.verlaenen@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sure, seems doable.&nbsp;&nbsp;Could you upload a zip containing a larger<br>example maybe?&nbsp;&nbsp;I was thinking about some rule files (one for each<br>rule, syntax exactly like current drl?), which implicitly refer to<br>stuff that is defined in the package file (imports, globals, anything
<br>else), functions (also in a separate file I assume), etc.<br><br>So something to test the builder with: if I&#39;m able to parse that set<br>of files, the builder would be supporting all important features :)<br><br>Kris
<br><br>On 3/6/07, Michael Neale &lt;<a href="mailto:michael.neale@gmail.com">michael.neale@gmail.com</a>&gt; wrote:<br>&gt; Kris, I updated this JIRA:<br>&gt;<br>&gt; <a href="http://jira.jboss.com/jira/browse/JBRULES-568">
http://jira.jboss.com/jira/browse/JBRULES-568</a><br>&gt;<br>&gt; Can you take a look, tell me if it makes sense, and if its doable. Probably<br>&gt; could be split into 2 if you like (one for DroolsBuilder, one for the GUI).
<br>&gt; This is critical for BRMS integration, BUT, it is useful even without a BRMS<br>&gt; (eg this GUI coudl provide a hook to fire of the ant task to compile the<br>&gt; rules into a deployable binary package).<br>&gt;
<br></blockquote></div><br>