Re: [rules-dev] osgi pull request conflicts

[Geoffrey De Smet]

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 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