Sure But for the moment my use case only covers rules using Java Dialect.
I don't know MVEL stuff, does it works like the Java dialect ? (ie parsing the rule, building some java code from it and then compile everything ?)
--G Le 29/10/2010 00:24, Michael Neale a écrit :
That wouldn't cover things like "Just in time" code generation in things like MVEL though.On Thu, Oct 28, 2010 at 7:55 PM, Leonardo Gomes <[email protected] <mailto:[email protected]>> wrote:It could be a starting point for this part: /maven plugin that precompiles the rule discovered in the module and simply place the/ / compiled classes in a given directory./ On Thu, Oct 28, 2010 at 10:12 AM, Guillaume Sauthier <[email protected] <mailto:[email protected]>> wrote: Thanks for the link Leonardo I did take a look at it, but it doesn't do what I want (extract the generated classes from the Package) :'( --G Le 28/10/2010 09:49, Leonardo Gomes a écrit :For the maven-plugin thing, have a look here: http://drools-java-rules-engine.46999.n3.nabble.com/maven-drools-plugin-to-compile-DRL-s-at-build-time-td725751.html Leo. On Thu, Oct 28, 2010 at 9:39 AM, Guillaume Sauthier <[email protected] <mailto:[email protected]>> wrote: Hi Edison To be more concrete, I would like to create first a maven plugin that precompiles the rule discovered in the module and simply place the compiled classes in a given directory. Currently, I may use the reflection trick to access what I want (the PackageStore), but if it could be part of an API, that would be better :) Does it seems weird ? Is a patch welcome for this problem ? --G Le 26/10/2010 09:49, Guillaume Sauthier a écrit : > Thanks for your answer Edson. > > The reason I have is that runtime generated stuff usually don't fit well > in an OSGi model. > > When you take a bundle, it has a statically defined set of "imported > packages". that means that when the bundle has been compiled, a list of > packages to be wired in at deployment time has been computed. This list > of packages if inferred from what the .class files (in the bundle) > requires to be executed (think of them as external dependencies). > > Now if we generate some classes at runtime in an OSGi environment, we > can see that generated classes can have different (or additional) > requirements in terms of java packages. So usually, with OSGi, that ends > up by adding a special header called DynamicImport-Package into the > MANIFEST, with the side effects of breaking modularity :-( > > This is what I want to avoid by having access to the generated classes > at the compilation phase: I can then use this bytecode (IOW giving it to > Bnd [1]) to complete the Import-Package MANIFEST header with the right > set of imported java packages. > > As a second issue, less important for the moment and more runtime > oriented this time, I would like to know if/how we can add a new kind of > Resource. > Once we have generated the bytecode in the compilation phase, we can > assume that all the stuff is already here in the bundle. Why can't we > use it ? > I've seen the PKG Resource type, but it's some kind of serialization of > a whole Package, couldn't it be possible to have a new Package type (or > way to create a Package) that can use the ClassLoader to get access to > the already present bundle's resources instead of using the byte[] from > the serialized Package ? > > WDYT? > > Thanks > --G > > [1]. http://www.aqute.biz/Code/Bnd > > Le 25/10/2010 21:26, Edson Tirelli a écrit : > >> Not exactly sure how helpful would it be to store the generated >> bytecodes in an osgi bundle. Anyway, there is no API right now to do >> that, but you can use reflection to achieve the same: >> >> PackageCompilationData data = pkg.getPackageCompilationData(); >> Field field = PackageCompilationData.class.getDeclaredField( "store" ); >> field.setAccessible( true ); >> Map<String, byte[]> store = (Map<String, byte[]>) field.get( data ); >> >> If you can justify the need for such an API, I guess we could be >> convinced to add one. >> >> Edson >> >> >> >> >> 2010/10/25 Guillaume Sauthier<[email protected] <mailto:[email protected]>>: >> >> >>> Hi team >>> >>> I've tried the IRC (without much success I admit), maybe here someone will >>> have some thoughts to share :) >>> >>> I'm looking for a way to "intercept" the classes being generated by the >>> drools compiler. >>> I've seen that the classes bytecode is stored deep in >>> PackageStore/JavaDialectRuntimeData, so deep that I cannot easily access it >>> :) >>> The objective is to be able to give theses classes to Bnd (I want to store >>> all of that in an OSGi bundle) so that appropriate Import-Packages can be >>> computed. That will avoid to have DynamicImport-Packages all around my >>> bundles :) >>> >>> Currently, what I get from the drools compiler is a >>> Collection<KnowledgePackage> but I have no API (or didn't find any) to >>> access (or know) the classes generated by the compiler. >>> >>> Any ideas ? >>> Thanks >>> --Guillaume >>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> >> >> >> > _______________________________________________ > rules-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ rules-dev mailing list [email protected] <mailto:[email protected]> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list [email protected] <mailto:[email protected]> https://lists.jboss.org/mailman/listinfo/rules-dev_______________________________________________ rules-dev mailing list [email protected] <mailto:[email protected]> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list [email protected] <mailto:[email protected]> https://lists.jboss.org/mailman/listinfo/rules-dev -- Michael D Neale home: www.michaelneale.net <http://www.michaelneale.net> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
<<attachment: guillaume_sauthier.vcf>>
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
