Hi Christiano, The droolsjbpm-integration/drools-osgi module is the place to be for adding others osgi tests to support Felix, Equinox, jboss-osgi, ...
Regards, Charles On Tue, Mar 26, 2013 at 2:12 PM, Geoffrey De Smet <ge0ffrey.s...@gmail.com>wrote: > > Op 26-03-13 13:58, Cristiano Gavião schreef: > > Geoffrey, > > 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). > > That project will let us to know the right manifest generation that will > be needed for all env. > > btw, where should I put this project ? > > As a module in here: > > https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi > > > > I added some comments below... > > regards, > > Cristiano > > On 26/03/13 08:54, Geoffrey De Smet wrote: > > Christiano, Charles, > > Your pull requests conflicted massively with each other :( > > I 've done my best to apply the best of both worlds. > Due to the conflict, changes might be lost. Sorry if that has happened. > Contradicting conflicts have been written below. > > Some notes on this approach and the current state: > > - *All common felix properties have been extracted to the > droolsjbpm-parent pom.* Individual modules should not define any of > these specifically. > - If you want to add/remove/change any of those, change them in the > parent pom only: > - > > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.xml > - These are currently in the parent pom: > - <extensions>true</extensions> > - <excludeDependencies>true</excludeDependencies> > - <_removeheaders>Ignore-Package</_removeheaders> > - What does this mean? Christiano wants to remove this. > - @charles are you ok with removing this? > - <_nouses>true</_nouses> > - What does this mean? Christiano wants this. > > 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: > http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/ > > > - > - <_snapshot>${osgi-version-qualifier}</_snapshot> > - Christiano: "To make eclipse happy" > - > > <Bundle-Version>${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.incrementalVersion}.${osgi.version.qualifier}</Bundle-Version> > - Christiano: "To make eclipse happy" > - There are not added (because less code is better > maintainable): > - <DynamicImport-Package>*</> has been removed everywhere, as per > Christiano's change > - @charles @christiano If you need it anyway, edit the > droolsjbpm-parent pom and supply a pull request > - <Bundle-ActivationPolicy>lazy</> has not been added > anywhere, as Charles didn't seem to need it > > That is good when using Declarative Services > and do not require you explicitly start and activate the bundle... > > > - > - @christiano @charles If you need it anyway, edit the > droolsjbpm-parent pom and supply a pull request > - Generally, christiano's imports/export statements survived. > (I found they to contain little or no dead imports/exports.) > - Some of Charles imports/export statement changes were added too. > - The original state of the imports/exports was mostly ignored as > they were totally out-of-date. > - 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. > - Some modules currently have singleton=true, others don't. This > seems to be the way you guys wanted: it's differs per module > - Pull Request to add/remove singleton as needed welcome > - Empty<Private-Package> have been removed everywhere > > > 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. > > > - <Require-Bundle> has been removed everywhere. > - This makes our build and release procedure far less complex (no > more separate osgi.version property). > - Don't add it back pls: I strongly prefer it stays dead. > > I've now spend a lot of time on drools OSGi, and I really need to focus on > optaplanner issues. > Edson has agreed to look into future osgi related pull requests for drools. > > > > _______________________________________________ > rules-dev mailing > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > > _______________________________________________ > rules-dev mailing > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
