[rules-dev] TypeDeclaration plugin heirarchy

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