[bnd-maven-plugin] Default (bundle) Export-Package version when building via Gitlab CI

GENERAL
1

Hello everyone,

I have a weird problem.

When building projects in a multi-module setup with bnd-maven-plugin where my project structure is like this:
maven-master/
– .gitlab-ci.yml
– pom.xml // packaging pom
– maven_module_and_git_submodule/
---- pom.xml // packaging pom
---- actual_project_1/
------ bnd.bnd // Export-Package : exported_package_1,\
----------------------- exported_package_2
------ pom.xml // packaging jar, version e.g. 24.8.0
------ src/main/java/
-------- actual_project_1.exported_package_1/
---------- package-info.java // containing @org.osgi.annotation.versioning.Version(“1.0.0”)
---------- // other sources
-------- actual_project_1.exported_package_2/
---------- packageinfo // containing version 1.0.0
---------- // other sources

locally, this builds fine so the resulting manifests contain
Export-Package: exported_package_1;version=“1.0.0”,exported_package_2;version=“1.0.0”.

But if I download an artifact built by Gitlab CI from its own package registry, which I’m using to deploy into, the manifest contains
Export-Package: exported_package_1;version=“24.8.0”,exported_package_2;version=“24.8.0”

Here is my .gitlab-ci.yml:

stages:
  - test
  - deploy

variables:
  MAVEN_OPTS: >-
    -Dhttps.protocols=TLSv1.2
    -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
    -Dorg.slf4j.simpleLogger.showDateTime=true
    -Djava.awt.headless=true

  MAVEN_CLI_OPTS: >-
    --batch-mode
    --errors
    --fail-at-end
    --show-version
    --no-transfer-progress
    -DinstallAtEnd=true
    -DdeployAtEnd=true
    
  GIT_SUBMODULE_STRATEGY: recursive
  GIT_SUBMODULE_FORCE_HTTPS: "true"
  GIT_SUBMODULE_DEPTH: 1

image: maven:3-eclipse-temurin-17

cache:
  paths:
    - .m2/repository

.verify:
  stage: test
  script:
    - 'mvn clean'
    - 'mvn validate'
    - 'mvn $MAVEN_CLI_OPTS clean verify -U --settings ci_settings.xml'

.trustCert:
  before_script:
    - 'keytool -trustcacerts -cacerts -storepass REDACTED -importcert -alias REDACTED -file $REDACTED --noprompt'

verify:jdk17:
  extends:
    - .trustCert
    - .verify

deploy:jdk17:
  cache: []
  stage: deploy
  extends: 
    - .trustCert
  script:
    - if [ ! -f ci_settings.xml ]; then
        echo "CI settings missing\! If deploying to GitLab Maven Repository, please see https://docs.gitlab.com/ee/user/packages/maven_repository/index.html#create-maven-packages-with-gitlab-cicd for instructions.";
      fi
    - 'mvn validate'
    - 'mvn $MAVEN_CLI_OPTS install --settings ci_settings.xml'
    - 'mvn $MAVEN_CLI_OPTS deploy --settings ci_settings.xml'
  only:
    variables:
      - $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Is there anything specific for Gitlab CI to be configured with bnd-maven-plugin to work as expected wrt Export-Package versions?

2

Sounds strange and I can’t think of anything specific to the maven-bnd-plugin that might cause such behavior, besides maybe an older version of bnd.

Can your run the rebuild locally with using a new local m2 repo? I have the feeling, that there is somewhere a pom in your local m2, that has a different config than the one pulled on gitlab.

1 Like
3

As you expected, my problem arises from locally cached artifacts.
Locally Deleting the old artifacts and building again yields new artifacts with their bundle versions as package versions for Export-Package.

Semi-related:
What I’m currently doing is, that I’m (once again, this time maven-based as we internally decided against using bndtools since we don’t want to depend on a single IDE in future if we can also avoid that) converting PDE projects to maven projects to get rid of manual Manifest maintenance and automatedly test in CI, yadda yadda.
I had one project, where I forgot to update the Export-Package header after adding the backslashes on line ends, so the versions were still set. And these versions were built into the resulting manifest, which is totally fine for me.
It also seems, that once -nodefaultversion: true is set, version information from packageinfo files is not evaluated anymore, while it still is getting evaluated from package-info.java including the @org.osgi.annotation.versioning.Version annotation.

Now comes my alltogether different question from the original post, I hope it’s ok to ask this in here as well as it is more of a general bnd question: Since this means, that with org.osgi:osgi.annotation:8.1.0 I’m gonna include an extra dependency just to set Export-Package versions that could seemingly also be set in the Export-Package header in all the bnd.bnd files of each project directly, sparing me an extra dependency and managing all export-related metadata in a single spot: What -other than the recommendation on bnd.bndtools.org- remains a good reason to set Export-Package versions in a package-info.java or packageinfo file? Or is this something only really relevant for and within bndtools workspaces?