<div dir="ltr">Hi Christiano,<div><br></div><div style>The droolsjbpm-integration/drools-osgi module is the place to be for adding others osgi tests to support Felix, Equinox, jboss-osgi, ...</div><div style><br></div><div style>
Regards,</div><div style><br></div><div style>Charles</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 26, 2013 at 2:12 PM, Geoffrey De Smet <span dir="ltr"><<a href="mailto:ge0ffrey.spam@gmail.com" target="_blank">ge0ffrey.spam@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div>Op 26-03-13 13:58, Cristiano Gavião
schreef:<br>
</div><div class="im">
<blockquote type="cite">
<div>Geoffrey,<br>
<br>
I started to play with a maven and pax-exam based
drools-osgi-test project were will be possible to run tests in
different osgi environments (equinox-juno, equinox-kepler,
felix, knoplerfish, jboss-osgi and karaf).<br>
<br>
That project will let us to know the right manifest generation
that will be needed for all env.<br>
<br>
btw, where should I put this project ?<br>
</div>
</blockquote></div>
As a module in here:<br>
<a href="https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi" target="_blank">https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi</a><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div> <br>
I added some comments below...<br>
<br>
regards,<br>
<br>
Cristiano<br>
<br>
On 26/03/13 08:54, Geoffrey De Smet wrote:<br>
</div>
<blockquote type="cite">
Christiano, Charles,<br>
<br>
Your pull requests conflicted massively with each other :(<br>
<br>
I 've done my best to apply the best of both worlds.<br>
Due to the conflict, changes might be lost. Sorry if that has
happened.<br>
Contradicting conflicts have been written below.<br>
<br>
Some notes on this approach and the current state:<br>
<ul>
<li><b>All common felix properties have been extracted to the
droolsjbpm-parent pom.</b> Individual modules should not
define any of these specifically.</li>
<ul>
<li>If you want to add/remove/change any of those, change
them in the parent pom only:</li>
<ul>
<li><a href="https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.xml" target="_blank">https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.xml</a><br>
</li>
</ul>
<li>These are currently in the parent pom:</li>
<ul>
<li><extensions>true</extensions></li>
<li><excludeDependencies>true</excludeDependencies><br>
</li>
<li><_removeheaders>Ignore-Package</_removeheaders></li>
<ul>
<li>What does this mean? Christiano wants to remove
this.</li>
<li>@charles are you ok with removing this?<br>
</li>
</ul>
<li><_nouses>true</_nouses></li>
<ul>
<li>What does this mean? Christiano wants this.<br>
</li>
</ul>
</ul>
</ul>
</ul>
</blockquote>
bnd adds a :uses for each exported package. I use
<_nouses> to help create the manifest, but I think it should
be removed once we mature the manifest. This is a good article for
the curious:
<a href="http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/" target="_blank">http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/</a><br>
<br>
<blockquote type="cite">
<ul>
<ul>
<ul>
<ul>
<li> <br>
</li>
</ul>
<li><_snapshot>${osgi-version-qualifier}</_snapshot></li>
<ul>
<li>Christiano: "To make eclipse happy"<br>
</li>
</ul>
<li><Bundle-Version>${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.incrementalVersion}.${osgi.version.qualifier}</Bundle-Version></li>
<ul>
<li>Christiano: "To make eclipse happy"</li>
</ul>
</ul>
</ul>
<ul>
<li>There are not added (because less code is better
maintainable):<br>
</li>
<ul>
<li><DynamicImport-Package>*</> has been
removed everywhere, as per Christiano's change</li>
<ul>
<li>@charles @christiano If you need it anyway, edit the
droolsjbpm-parent pom and supply a pull request<br>
</li>
</ul>
</ul>
</ul>
<ul>
<ul>
<li><Bundle-ActivationPolicy>lazy</> has not
been added anywhere, as Charles didn't seem to need it<br>
</li>
</ul>
</ul>
</ul>
</blockquote>
That is good when using Declarative
Services and do not require you explicitly start and activate the
bundle... <br>
<blockquote type="cite">
<ul>
<ul>
<ul>
<li> <br>
</li>
<ul>
<li>@christiano @charles If you need it anyway, edit the
droolsjbpm-parent pom and supply a pull request</li>
</ul>
</ul>
</ul>
<li>Generally, christiano's imports/export statements
survived. (I found they to contain little or no dead
imports/exports.)</li>
<ul>
<li>Some of Charles imports/export statement changes were
added too.</li>
<li>The original state of the imports/exports was mostly
ignored as they were totally out-of-date.</li>
</ul>
<li>The singleton discussion is lost to me. As Charles is
supplying the unit test in droolsjbpm, I believe he should
make the call which modules should be singleton and which
should not, taking Christiano's advice into consideration of
course.<br>
</li>
<ul>
<li>Some modules currently have singleton=true, others
don't. This seems to be the way you guys wanted: it's
differs per module</li>
<ul>
<li>Pull Request to add/remove singleton as needed welcome</li>
</ul>
</ul>
<li>Empty<Private-Package> have been removed everywhere</li>
</ul>
</blockquote>
<br>
That was used to trick BND and should be maintained in projects
that contains "impl" in the package name because that packages are
not exported.<br>
<br>
<blockquote type="cite">
<ul>
<li><Require-Bundle> has been removed everywhere.</li>
<ul>
<li>This makes our build and release procedure far less
complex (no more separate osgi.version property).</li>
<ul>
<li>Don't add it back pls: I strongly prefer it stays
dead.<br>
</li>
</ul>
</ul>
</ul>
<p>I've now spend a lot of time on drools OSGi, and I really
need to focus on optaplanner issues.<br>
Edson has agreed to look into future osgi related pull
requests for drools.<br>
</p>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Charles Moulliard</div>
<div>Apache Committer / Sr. Enterprise Architect (RedHat)</div><div>Twitter : @cmoulliard | Blog : <a href="http://cmoulliard.blogspot.com" target="_blank">http://cmoulliard.blogspot.com</a></div><div><br></div>
</div>