Closed maggu2810 closed 5 years ago
My current summary (regex - space - version constraint):
# GSON
com.google.gson.* [2.2.4;3.0.0)
# Jetty
org.eclipse.jetty.* [9.3.15;9.4.0)
# OSGi Service Platform Release 4 Core Specification Version 4.2
org.osgi.framework.* 1.5
org.osgi.service.packageadmin.* 1.2
# OSGi Service Platform Release 4 Service Compendium Version 4.2
org.osgi.service.cm.* 1.3
org.osgi.service.component.* 1.1
org.osgi.service.device.* 1.1
org.osgi.service.event.* 1.2
org.osgi.service.http.* 1.2
org.osgi.util.tracker.* 1.4
But if the packages are exported, they could be used by binding developers and so the version constraints should be known, too.
It would be terrible if binding developers would use all what is available in the target platform. In https://www.eclipse.org/smarthome/documentation/development/bindings/dependencies.html, we tried to define a very small set of packages that should be used. But ok, I see that this question is anyhow not the idea of this effort.
This list could be added (some time) to the official documentation (if desired), so e.g. solution providers could look up the dependencies that are necessary to setup a product.
I do not think that a single list makes sense here - we need it grouped into higher-level features, considering that ESH is pretty modular, i.e. most commercial solutions won't require EMF/Xtext etc. and we thus should not list those as a requirement. The sample-packaging is probably a good starting point for the "minimal requirements" for a solution.
We already have a place in the documentation, where information about 3rd party dependencies is maintained - if I get you right, you would want to move that to a more technical (package versioning) level in order to properly formulate the technical requirements?
Currently I am interested in a list that contains all version constraints with respect to all ESH bundles.
As written in the GSON issue some time ago, I don't think it make sense if ESH_bundle_1 and ESH_bundle_2 uses different version requirements for the same package.
So, after this list has been created it is very easy to filter the dependencies as we just need to have a look at the package imports used in the specific manifest. That will be done by a tool.
Currently I am using the list above also to pre-process the ESH bundles automatically to add that versions constraints to the import package statements in the manifest. Using that approach there is one central place that holds the version constraints and the OSGi runtime is able to consider that information for wiring the ESH bundles.
The situation improved a lot after dropping the manifest first approach and the migration to Bnd.
Currently I try to write a list that contains all the packages and versions contraints that are necessary to run Eclipse SmartHome. This list could be added (some time) to the official documentation (if desired), so e.g. solution providers could look up the dependencies that are necessary to setup a product. So it is not about which third party libraries could be used by a binding developer but which stuff if necessary at runtime.
I started to collect a list of all package imports. This list could contain more packages then necessary because libraries could be bundled, imported but also exported, too. But if the packages are exported, they could be used by binding developers and so the version constraints should be known, too.
That is the current list:
[9.3.15;9.4.0)
[2.2.4;3.0.0)
For all the other ones, I can lookup which version we are currently using (e.g. the target platform, Karaf features, ...), but I assume this is not the minimum one that is supported (e.g. our target platform does not use the minimum version of OSGi).
@kaikreuzer How to proceed?