To achieve this, you will need to understand how the mvn bundle plugin works, how BND tool works, and how the mvn plugin interprets its configuration in the pom.xml file to add the correct OSGi-specific meta-data to the MANIFEST.mf file bundled with the jar file.

Omkar Marne - Can you take over working on this for now while Irvin Naylor completes the OSGi on-boarding task?

Maven bundle plugin is nothing but a wrapper for the BND tool, described here: https://bnd.bndtools.org/. It's main job is to translate the dependencies listed in the pom.xml file and the imports listed in the actual java code into new code that gets added to the MANIFEST.mf file in a jar file. When a jar file is loaded into the OSGi framework, the framework literally reads this MANIFEST.mf file and uses the information there to determine if the bundle can properly load and start, or not.

Therefore you need to try different configurations in the pom.xml, build the jar, and then look at the manifest file in the jar to make sure it is correct.

Sure, assigned it to myself.

I tried adding the dependencies and modifying the existing dependencies in Pom.xml file with the version 9.1.10 specified in the manifest file but the build failed because there is no 9.1.10 version in the maven repository. I think somehow I need to add the 9.1.10 version in the maven repository first and then build the jar file.

Read this: https://semver.org/ and understand the meaning of "semantic versioning."
Also review OSGi method for specifying dependencies. This is NOT the same thing as specifying dependencies in a pom.xml file.

pom.xml: contains instructions for building an artifact, using external libraries, called "dependencies"

manifest.mf: is a file that is packaged with a jar file that can contain OSGi-specific metadata

The maven bundle plugins uses pom.xml to accept parameters and add OSGi-specific metadata to the manifest.mf file

(Behind of the scenes, mvn's "compile" and maybe "package" plugins are creating the manifest.mf. The mvn bundle plugin adds to that process.)

My findings
The version of packages needed for import are all generated in the manifest file by the apache felix plugin using the below code of the pom.xml

<configuration>
                     <instructions>
                         <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                         <Import-Package>*</Import-Package>
                         <Export-Package/>
                         <Bundle-Description>${bundleDescription}</Bundle-Description>
                         <Service-Component>*</Service-Component>
                     </instructions>
                 </configuration>

The * in the Import packages indicate to use possible version range ditermined by the plugin. This can be overwritten by explicitly mentioning the version. I am currently in the process of finding the most valid macro expression which will pick the version from the dependency version and a hardcoded value as a higher micro version.

Refrence: https://davidvaleri.wordpress.com/2011/04/07/secrets-of-the-felix-bundle-plug-in-macros-revealed/

[~aloraine] There are 2 sets of packages listed in the import packages, one with package name org.lorainelab.igb and the other with com.affymetrix.* Do we need to change the versions of both to be [9.1.8, 10) in the manifest file?

I would recommend changing the POM to specify the same version for all platform bundles. The version used should be the highest version of platform bundles listed.
However, it would be useful to stick with the versions specified by the developer as this would expose any problems or incorrect assumptions baked in to the App Store or the App Manager component within IGB.

Please note that "Import-Package" is meant to use a particular syntax for specifying versions and ranges of versions. So in this case, you can use the proper syntax to specify "version 9.1.8 and higher" those bundles that require it.

You can also specify an upper limit. However, it is unclear if the upper limit can be specified because those higher versions do not exist yet. It is very possible that the App, as written, will work perfectly well with those versions.

The version of the app with the change now doesn't list as installable in the manager on 9.1.6 but appears in 9.1.8

Please Review: https://bitbucket.org/chesterdias/quickload-saver-chester-local/branch/IGBF-2785#diff

Omkar Marne and Irvin Naylor: Please perform functional and code review.

For functional review, confirm that the fix is working as follows:

• Pull the branch from Chester (see above)
• Push the branch to your fork
• Build the branch in bitbucket pipelines
• Confirm that the newly built App can be installed using App Manager GUI and used in 9.1.8
• Check the functionality and watch the logs for any possible exceptions that may occur
• Confirm that the App cannot be installed in 9.1.6
• Download and unpack the jar file; check that MANIFEST file and confirm it contains the proper text in import packages fields

For each of the above, describe what you observed. State whether the test has passed or failed.

Please add additional tests as you see fit.

New manifest file.

Old manifest file.

Change in the pom.xml

Code review Description.

Please refer : https://docs.google.com/document/d/1Jkot1-5W5g6wvYTDhw7NcZIThic_8x47Wo0irX46zcc/edit#heading=h.3fq7y5jrjfrx

Google doc above observes that the MANIFESTs from jars built before and after the proposed change are identical, but the proper installation behavior is only observed for the jar build using the new code.

I do not see how that is possible. Please investigate more carefully. Note that when you install or upgrade an App, the App's bundle is downloaded and saved to the user's local bundle cache. When you un-install an App, the bundle is deleted.

Also, investigate other meta-data assets provided in the jar.

Dr. Loraine you were right, we were comparing the same manifest files. I have attached the snapshots again. Micro versions in the manifest files have changed. After code change in pom.xml, manifest is taking the micro versions from pom.xml.

The app bundle is getting added and deleted when we install and uninstall the app. Also the repository.xml file has got updated with the updated micro versions.

Please check the code review and additional snapshots attached.

https://docs.google.com/document/d/1Jkot1-5W5g6wvYTDhw7NcZIThic_8x47Wo0irX46zcc/edit#

Ticket is ready for pull request and assigned to Chester Dias

PR: https://bitbucket.org/lorainelab/quickload-saver/pull-requests/2/igbf-2785-added-manifest-versioning

PR is merged and App is ready for testing from Downloads folder of https://bitbucket.org/lorainelab/quickload-saver/downloads/.

Can confirm, App does indeed work as intended on 9.1.8 master, output of Homosapeins 2013 is sent to correct contents.txt file