ossgang / ossgang-commons

Apache License 2.0
4 stars 0 forks source link

OSGi support #48

Closed LajosCseppento closed 4 years ago

LajosCseppento commented 4 years ago

I have added OSGi support - this basically means extra entries in MANIFEST.MF. As the project has no external dependencies, it is straightforward and the Bnd Gradle Plugin takes care of everything with minimal configuration.

However, I could not test whether the version is properly applied (I suppose it comes from the CI server). To check it, someone needs to build the JAR and look in MANIFEST.MF.

The manifest generated on my machine looks like this:

Manifest-Version: 1.0
Bnd-LastModified: 1589904947042
Bundle-ManifestVersion: 2
Bundle-Name: ossgang-commons
Bundle-SymbolicName: ossgang-commons
Bundle-Vendor: CERN
Bundle-Version: 0.0.0
Created-By: 1.8.0_252 (AdoptOpenJDK)
Export-Package: org.ossgang.commons.awaitables;version="0.0.0",org.oss
 gang.commons.awaitables.exceptions;version="0.0.0",org.ossgang.common
 s.collections;version="0.0.0",org.ossgang.commons.mapbackeds;version=
 "0.0.0",org.ossgang.commons.monads;version="0.0.0",org.ossgang.common
 s.observables;uses:="org.ossgang.commons.monads,org.ossgang.commons.o
 bservables.operators.connectors";version="0.0.0",org.ossgang.commons.
 observables.exceptions;version="0.0.0",org.ossgang.commons.observable
 s.operators;uses:="org.ossgang.commons.monads,org.ossgang.commons.obs
 ervables";version="0.0.0",org.ossgang.commons.observables.operators.b
 uffer;uses:="org.ossgang.commons.observables,org.ossgang.commons.prop
 erties";version="0.0.0",org.ossgang.commons.observables.operators.con
 nectors;uses:="org.ossgang.commons.observables,org.ossgang.commons.pr
 operties";version="0.0.0",org.ossgang.commons.observables.testing;use
 s:="org.ossgang.commons.observables";version="0.0.0",org.ossgang.comm
 ons.observables.weak;uses:="org.ossgang.commons.observables";version=
 "0.0.0",org.ossgang.commons.properties;uses:="org.ossgang.commons.obs
 ervables";version="0.0.0",org.ossgang.commons.utils;uses:="org.ossgan
 g.commons.monads";version="0.0.0"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-4.3.1.201911131708

For a released version, it shall contain the real version instead of "0.0.0" at all places. According to docs and my former experience, this should work out of the box.

codecov-commenter commented 4 years ago

Codecov Report

Merging #48 into master will increase coverage by 0.12%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff              @@
##             master      #48      +/-   ##
============================================
+ Coverage     73.69%   73.82%   +0.12%     
- Complexity      285      286       +1     
============================================
  Files            44       44              
  Lines           806      806              
  Branches         62       62              
============================================
+ Hits            594      595       +1     
  Misses          183      183              
+ Partials         29       28       -1     
Impacted Files Coverage Δ Complexity Δ
...gang/commons/observables/testing/TestObserver.java 100.00% <0.00%> (+2.70%) 18.00% <0.00%> (+1.00%)

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update b8a38a2...c43cf25. Read the comment docs.

andreacalia commented 4 years ago

Hi @LajosCseppento , thanks for the proposal. I have a question regarding the versioning.. we have the versioning decoupled from the code itself and the concept is expressed through git tags. You create a tag (release in github) and this triggers travis ci to build it and release it extracting the version from the tag name.

Here you can have a look at our scripts [1]. We want to improve them at some point because I'm sure there is a better way to do it.. anyway how this bnb plugin expects a version? Via project property?

[1] https://github.com/ossgang/gradle-scripts

LajosCseppento commented 4 years ago

Hi @LajosCseppento , thanks for the proposal. I have a question regarding the versioning.. we have the versioning decoupled from the code itself and the concept is expressed through git tags. You create a tag (release in github) and this triggers travis ci to build it and release it extracting the version from the tag name.

Here you can have a look at our scripts [1]. We want to improve them at some point because I'm sure there is a better way to do it.. anyway how this bnb plugin expects a version? Via project property?

[1] https://github.com/ossgang/gradle-scripts

It should use Gradle project.version. DId an update for that.

LajosCseppento commented 4 years ago

Hi @LajosCseppento , thanks for the proposal. I have a question regarding the versioning.. we have the versioning decoupled from the code itself and the concept is expressed through git tags. You create a tag (release in github) and this triggers travis ci to build it and release it extracting the version from the tag name.

Here you can have a look at our scripts [1]. We want to improve them at some point because I'm sure there is a better way to do it.. anyway how this bnb plugin expects a version? Via project property?

[1] https://github.com/ossgang/gradle-scripts

I created a release/tag on my fork, which is not picked up by your CI (might be normal). I also cannot push the tag. I prpose that to create a release/RC on the source repo (where I have no access). Could you please help me with it?