Closed LajosCseppento closed 4 years ago
Merging #48 into master will increase coverage by
0.12%
. The diff coverage isn/a
.
@@ 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.
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?
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?
It should use Gradle project.version. DId an update for that.
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?
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?
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:
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.