[rules-dev] osgi pull request conflicts

[Cristiano Gavião]

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 ?

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.
>       o 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
>       o 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"
>       o 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.)
>       o Some of Charles imports/export statement changes were added too.
>       o 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.
>       o 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.
>       o 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20130326/ec2af6f2/attachment-0001.html