[rules-dev] TypeDeclaration plugin heirarchy

[Stephen Kestle]

This is a follow up to my reply to 
http://article.gmane.org/gmane.comp.java.drools.user/12319 :)

What I would like are some changes to PackageBuilder (line numbers at 
r21562):

Remove/change lines 632-641 as they call 
pkgRegistry.getPackage().getFactTemplate, where fact templates are 
compiled into the package after 393, which is after 381->551->570->634.  
Ok, so perhaps it is possible, if you define your templates in another 
package...

Change TypeDeclaration.Format to a class, instead of an enum.  We want 
our own type.  At line 632, insert something like the following:

final String format = 
ObjectUtils.defaultIfNull(typeDescr.getMetaAttribute( 
TypeDeclaration.ATTR_FORMAT).toLowerCase(), "pojo"); //ATTR_FORMAT="format"
TypeFactory factory = packageDesc.getTypeFactory(format);  //where 
packages have a typeFactory declaration of a class that implements 
TypeFactory (which has a getFormat() for registration purposes)
TypeDeclaration type = factory.create(typeDescr);

lines 643-674 get moved into PojoTypeFactory.create();

Something needs to be done to TypeDeclaration to allow non-class based 
implementations.  After all, it makes no sense (to me) to call a method 
that then just refers to a map of name-values.

However, drools uses java object types/classes heavily for rules 
optimisations - and type references.  Is this unavoidable?  Was this the 
fundamental problem with templates - that one could not be composed 
inside another because the type could not be referenced (by a class)?


Also, I'm looking for a way to do partial compilation... I want to 
create a description with fundamental declarations and imports for our 
product to simplify the text ones, but I can't figure out how to merge - 
is it just a case of declaring my core package, and then "adding" the 
same one from the file?

Cheers

Stephen