I agree with you.... Blueprint and CDI has this advantage over DS.
But I think I never had the necessity to inject beans in many years of
development with OSGi. Injecting simple components and services fitted well
all my needs. :) And the best from DS is that it is smart, small and fast.
As Blueprint, CDI and DS uses xml we can provide all. But I don't know If
there is a way to choose only one at runtime... I mean, what could happen
in a system where we have both Blueprint and DS active?
2013/3/28 Charles Moulliard <ch007m(a)gmail.com>
There is nevertheless one advantage of Aries Blueprint over
Declarative
Service which is :
"Unlike Declarative Services, Blueprint can inject not only OSGi
services, but also managed beans, i.e. plain old Java objects. Managed
beans are local to the current component and cannot be injected into other
components. Each Blueprint-enabled bundle has its own Blueprint context
with managed beans and OSGi service references. The contexts of different
bundles can interact by injecting services published by another bundle."
On Wed, Mar 27, 2013 at 8:26 PM, Charles Moulliard <ch007m(a)gmail.com>wrote:
> Great !
>
>
> On Wed, Mar 27, 2013 at 7:04 PM, Cristiano Gavião <cvgaviao(a)gmail.com>wrote:
>
>> Hi Charles,
>>
>> Step one (installation of bundles and its dependencies) seems to be ok
>> ;)
>>
>> [INFO] drools-osgi-enviroment-tests ...................... SUCCESS
>> [6.559s]
>> [INFO] drools-osgi-enviroment-tests-common ............... SUCCESS
>> [15.887s]
>> [INFO] drools-osgi-enviroment-tests-equinox-juno ......... SUCCESS
>> [20.176s]
>> [INFO] drools-osgi-enviroment-tests-equinox-kepler ....... SUCCESS
>> [17.581s]
>> [INFO] drools-osgi-enviroment-tests-felix ................ SUCCESS
>> [15.874s]
>> [INFO] drools-osgi-enviroment-tests-jbosgi ............... SUCCESS
>> [39.769s]
>> [INFO] drools-osgi-enviroment-tests-knoplerfish .......... SUCCESS
>> [14.839s]
>> [INFO]
>> ------------------------------------------------------------------------
>>
>> next step is to reuse the existent tests-jars
>>
>> cheers,
>>
>>
>> Cristiano
>>
>>
>>
>> 2013/3/27 Charles Moulliard <ch007m(a)gmail.com>
>>
>>> I think that those packages have been added since JDK 1.7 xxx. Reason
>>> why you should deploy the following bundles :
>>>
>>>
>>>
https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o...
>>>
>>> with these versions
>>>
>>>
>>>
https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o...
>>>
>>>
>>> and more specifically 2.2.1 for jaxb-x
>>>
>>>
>>> On Wed, Mar 27, 2013 at 4:32 PM, Cristiano Gavião
<cvgaviao(a)gmail.com>wrote:
>>>
>>>> The packages that I'm aware of until now is:
>>>> - org.apache.poi.openxml4j.exceptions
>>>> - org.apache.poi.ss.usermodel (note that poi.jar exports this too)
>>>>
>>>> I'm getting another problem with servicemix bundles related to
>>>> com.sun.tools.xjc. it seems that there is no bundle exporting
>>>> com.sun.source.tree that is being required:
>>>>
>>>> ERROR: Bundle org.drools.decisiontables [38] Error starting
>>>> mvn:org.drools/drools-decisiontables/6.0.0-SNAPSHOT
>>>> (org.osgi.framework.BundleException: Unresolved constraint in bundle
>>>> org.drools.decisiontables [38]: Unable to resolve 38.0: missing
requirement
>>>> [38.0] osgi.wiring.package;
>>>> (osgi.wiring.package=org.drools.compiler.compiler) [caused by: Unable to
>>>> resolve 29.0: missing requirement [29.0] osgi.wiring.package;
>>>> (osgi.wiring.package=org.drools.core) [caused by: Unable to resolve
30.0:
>>>> missing requirement [30.0] osgi.wiring.package;
>>>> (osgi.wiring.package=com.sun.tools.xjc) [caused by: Unable to resolve
32.0:
>>>> missing requirement [32.0] osgi.wiring.package;
>>>> (osgi.wiring.package=com.sun.source.tree)]]])
>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>>>> org.drools.decisiontables [38]: Unable to resolve 38.0: missing
requirement
>>>> [38.0] osgi.wiring.package;
>>>> (osgi.wiring.package=org.drools.compiler.compiler) [caused by: Unable to
>>>> resolve 29.0: missing requirement [29.0] osgi.wiring.package;
>>>> (osgi.wiring.package=org.drools.core) [caused by: Unable to resolve
30.0:
>>>> missing requirement [30.0] osgi.wiring.package;
>>>> (osgi.wiring.package=com.sun.tools.xjc) [caused by: Unable to resolve
32.0:
>>>> missing requirement [32.0] osgi.wiring.package;
>>>> (osgi.wiring.package=com.sun.source.tree)]]]
>>>>
>>>> I'm using this deps:
>>>>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix.bundles</groupId>
>>>>
>>>>
<artifactId>org.apache.servicemix.bundles.jaxb-xjc</artifactId>
>>>> <version>2.2.6_1</version>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix.bundles</groupId>
>>>>
>>>>
<artifactId>org.apache.servicemix.bundles.jaxb-impl</artifactId>
>>>> <version>2.2.6_1</version>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix.specs</groupId>
>>>>
>>>>
<artifactId>org.apache.servicemix.specs.jaxb-api-2.2</artifactId>
>>>> <version>2.2.0</version>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix.specs</groupId>
>>>>
>>>>
<artifactId>org.apache.servicemix.specs.activation-api-1.1</artifactId>
>>>> <version>2.2.0</version>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix.specs</groupId>
>>>>
>>>>
<artifactId>org.apache.servicemix.specs.stax-api-1.2</artifactId>
>>>> <version>2.2.0</version>
>>>> </dependency>
>>>>
>>>>
>>>> 2013/3/27 Charles Moulliard <ch007m(a)gmail.com>
>>>>
>>>>> Can you please provide me the list of packages to be exported and I
>>>>> will include also poi-ooxml ?
>>>>>
>>>>>
>>>>> On Wed, Mar 27, 2013 at 3:03 PM, Cristiano Gavião
<cvgaviao(a)gmail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/3/27 Charles Moulliard <ch007m(a)gmail.com>
>>>>>>
>>>>>>> 1) For Karaf project, we mostly use activator or Aries
Blueprint (
>>>>>>>
http://aries.apache.org/modules/blueprint.html). Declarative
>>>>>>> Service is rather new top of karaf (
>>>>>>>
http://sully6768.blogspot.be/2012/09/scr-components-with-karaf.html
>>>>>>> )
>>>>>>>
>>>>>>
>>>>>> As a consumer you can still using both blueprint or
BundleContext.getService()
>>>>>> to reference the services.
>>>>>>
>>>>>> What I found good in both Blueprint and DS is that they ensure
the
>>>>>> component/services lifecycle and we could still use Configuration
Admin
>>>>>> with them.
>>>>>>
>>>>>> The problem with blueprint is that is not default installed in
most
>>>>>> distributions while DS is.
>>>>>> Is DS installed by default in Karaf?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2) For poi-ooxml, we should use the ServiceMix bundle (
>>>>>>>
http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.se...)
>>>>>>> until they provide a OSGI bundle of POI.
>>>>>>>
>>>>>>
>>>>>> Unfortunately this bundle don't export the package needed. it
wraps
>>>>>> the poi.jar but not poi-ooxml.
org.apache.poi.ss.usermodel.Workbook.class :(
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 27, 2013 at 1:53 PM, Cristiano Gavião <
>>>>>>> cvgaviao(a)gmail.com> wrote:
>>>>>>>
>>>>>>>> I won't change that code for while... It is still be
there until
>>>>>>>> you decide to move it to the new one. ;)
>>>>>>>>
>>>>>>>> Btw, I have two questions:
>>>>>>>>
>>>>>>>> 1)what do you think about to use Declarative Services to
register
>>>>>>>> the services instead do it manually at activator ?
>>>>>>>>
>>>>>>>> 2) how are you dealing with poi-ooxml dependency in
>>>>>>>> drools-decisiontables? there is no osgified jar for
it...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/3/27 Charles Moulliard <ch007m(a)gmail.com>
>>>>>>>>
>>>>>>>>> Hi Christiano,
>>>>>>>>>
>>>>>>>>> I prefer that first we finalize the OSGI bundles
>>>>>>>>> (drools-decisiontables, drools-jpa, drools-jbpm, ...)
before changing
>>>>>>>>> pax-exam code which is working and also used by
Apache Camel/Karaf projects
>>>>>>>>> ;-)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Charles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 27, 2013 at 1:44 PM, Cristiano Gavião
<
>>>>>>>>> cvgaviao(a)gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I already look at it. The problem is that this
tests are using
>>>>>>>>>> an old version (2.x) of pax-exam and using a
karaf specific api too.
>>>>>>>>>> That version will be dropped by karaf team soon.
see [1] and [2].
>>>>>>>>>>
>>>>>>>>>> Btw, Pax-exam was improved a lot in version 3.x.
>>>>>>>>>>
>>>>>>>>>> [1] -
>>>>>>>>>>
http://karaf.922171.n3.nabble.com/Discuss-Karaf-and-Pax-Exam-3-x-td402807...
>>>>>>>>>> [2] -
https://ops4j1.jira.com/browse/PAXEXAM-503
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Cristiano
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2013/3/27 Charles Moulliard
<ch007m(a)gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Christiano,
>>>>>>>>>>>
>>>>>>>>>>> Can you please have a look here as there is
already a pax-exam
>>>>>>>>>>> test for karaf (
>>>>>>>>>>>
https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-o...)
>>>>>>>>>>> ?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Charles
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 26, 2013 at 11:11 AM, Cristiano
Gavião <
>>>>>>>>>>> cvgaviao(a)gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'm creating a pax-exam project
where I will run some test
>>>>>>>>>>>> on top of equinox and felix.
>>>>>>>>>>>>
>>>>>>>>>>>> After I commit and push it maybe you
could add karaf stuffs.
>>>>>>>>>>>> so it could help us to identify the
reason of the error you are talking
>>>>>>>>>>>> about...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 25/03/13 14:19, Charles Moulliard
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> There was another error when using
singleton := true.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Mar 25, 2013 at 6:15 PM,
Cristiano Gavião <
>>>>>>>>>>>> cvgaviao(a)gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> well, I never seen any error related
to singleton attribute
>>>>>>>>>>>>> at Felix or Equinox.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The error you have reported seems to
be related to what is
>>>>>>>>>>>>> being done (and not being undone)
inside the activator...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2013/3/25 Charles Moulliard
<ch007m(a)gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not at all but using singleton :=
true option generates
>>>>>>>>>>>>>> error when we do a stop, update
start on Apache Karaf.
>>>>>>>>>>>>>> We never used that property to
generate all the bundles that
>>>>>>>>>>>>>> we have in the project Karaf,
ServiceMix, Geronimo, ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 25, 2013 at 4:34 PM,
Cristiano Gavião <
>>>>>>>>>>>>>> cvgaviao(a)gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Charles,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I saw that you removed
singleton:=true in your commit. This
>>>>>>>>>>>>>>> is because do you plan to
have more than one version of drools/jbpm running
>>>>>>>>>>>>>>> at same time?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cristiano
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2013/3/25 Cristiano Gavião
<cvgaviao(a)gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Charles,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I already changed the
manifest generation of kie and other
>>>>>>>>>>>>>>>> drools modules. I created
some pull requests for such changes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Next thing that I planned
to do this week(Wed) was to
>>>>>>>>>>>>>>>> review each Activator, I
think we could improve it...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cristiano
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 25/03/13 04:52,
Charles Moulliard wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The
org.kie.api.osgi.Activator class of kie
>>>>>>>>>>>>>>>> project needs the class
ServiceRegistryImpl (& Interface ServiceRegistry of
>>>>>>>>>>>>>>>> kie internal) to register
an OSGI Service (Interface)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
this.serviceRegistry = bc.registerService(
>>>>>>>>>>>>>>>>
ServiceRegistry.class.getName(),
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
ServiceRegistryImpl.getInstance(),
>>>>>>>>>>>>>>>>
new
>>>>>>>>>>>>>>>> Hashtable() );
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> but the maven module kie
api does not have a dependency
>>>>>>>>>>>>>>>> with kie internal as the
class ServiceRegistry & ServiceRegistryImpl are
>>>>>>>>>>>>>>>> part of the module kie
internal & package org.kie.internal.utils
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Questions :
>>>>>>>>>>>>>>>> - What are the plans
regarding to the Activator of Kie api
>>>>>>>>>>>>>>>> bundle - what does it
want to do ?
>>>>>>>>>>>>>>>> - Can we add the missing
dependency in kie api project ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Charles Moulliard
>>>>>>>>>>>>>>>> Apache Committer / Sr.
Enterprise Architect (RedHat)
>>>>>>>>>>>>>>>> Twitter : @cmoulliard |
Blog :
>>>>>>>>>>>>>>>>
http://cmoulliard.blogspot.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>> rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> "Tudo vale a pena se a
alma não é pequena..."
>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>> rules-dev mailing list
>>>>>>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Charles Moulliard
>>>>>>>>>>>>>> Apache Committer / Sr. Enterprise
Architect (RedHat)
>>>>>>>>>>>>>> Twitter : @cmoulliard | Blog :
>>>>>>>>>>>>>>
http://cmoulliard.blogspot.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>> rules-dev mailing list
>>>>>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>> rules-dev mailing list
>>>>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Charles Moulliard
>>>>>>>>>>>> Apache Committer / Sr. Enterprise
Architect (RedHat)
>>>>>>>>>>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>> rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>> rules-dev mailing list
>>>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Charles Moulliard
>>>>>>>>>>> Apache Committer / Sr. Enterprise Architect
(RedHat)
>>>>>>>>>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>> rules-dev mailing list
>>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> "Tudo vale a pena se a alma não é
pequena..."
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> rules-dev mailing list
>>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Charles Moulliard
>>>>>>>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>>>>>>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> rules-dev mailing list
>>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> "Tudo vale a pena se a alma não é pequena..."
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rules-dev mailing list
>>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Charles Moulliard
>>>>>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>>>>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> rules-dev mailing list
>>>>>>> rules-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "Tudo vale a pena se a alma não é pequena..."
>>>>>>
>>>>>> _______________________________________________
>>>>>> rules-dev mailing list
>>>>>> rules-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Charles Moulliard
>>>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> rules-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "Tudo vale a pena se a alma não é pequena..."
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>>
>> --
>> "Tudo vale a pena se a alma não é pequena..."
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
>
>
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog :
http://cmoulliard.blogspot.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev