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]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
