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 <guillaume.sauthier@ow2.org> 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<guillaume.sauthier@ow2.org>:
>>
>>
>>> 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
>>> rules-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev