jclouds

Commit Graph

Author	SHA1	Message	Date
gurkerl83	57f6bbc43a	Remove explicit OSGi import range of okio dep All OkHttp components get shipped with any OSGi metadata. Tracking the progress of that issue from version 5 onwards, OkHttp finally provides OSGi support. Because JClouds OkHttp dependencies got renewed from 2.2.0 to the latest 3 (3.14.9), the respective bundles from Apache Servicemix got used in a deployment scenario. On the other hand, the problem with Servicemix is that there is no full match of published OkHttp dependencies to the respective bundle equivalent. https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.okhttp My test shows that none of the version 3 bundles work because of a missing package dependency "javax.annotation.meta". Sure higher version of 9 strips the javax.annotation module entirely, but the meta package is not there in JDK 8 either. As you can see from the link above, only two versions of 3.14 got published in the service mix; it is not clear to which version the bundle equivalents relate. From my understanding, it is much more important to use identical versions of OkHttp dependencies used in JClouds. To utilize the original OKHttp libraries, consumer projects have to ensure those libraries get loaded using OSGi helper tools such as the wrap protocol provided by Apache Karaf or similar. To reduce OSGi noise, I removed the OSGi import range of okio dependency entirely. A declaration like that does not make sense; otherwise, a set of Okhttp ranges must also be defined. Note: The wildcard (*) declaration provides a way out, which allows any version of a package used in JClouds but itself does not give any OSGi metadata. Hopefully, I do not confuse you too much.	2021-02-12 18:57:46 +09:00
gurkerl83	85666982ae	Add OSGi version ranges, guice, okio In the present feature, the two properties - guava.osgi.import and - okhttp.version have not been attached to the build process (Bnd plugin), but have been recorded as comments only. Before the resolution method is considered, the problem of Guava and its close coupling with Guice must be examined. The Guice project possesses, differently to GSON no explicit configuration, how its dependencies are regarded in an OSGi execution environment. Guice / Guava - 4.1.0 / 19.0 - 4.2.0 / [23.6,24) - 4.2.1 / [25.1,26) - 4.2.3 / [27.1,28) => used - 5.0.0.BETA-1 / [27.1,28) The version of Guice built into JClouds is 4.2.3. Increasing to this version number was not the subject of the current branch. To avoid backward compatibility problems between Guice and Guava (e.g. Guice 4.2.3 -> Guava 24) this means that the version of Guava integrated in JClouds must be at least version 27.1. Guice puts this in its dependencies. In my opinion, consumers (JClouds, as well as consumers of JClouds) should take this minimum barrier into account. Resolution To understand the resolution, please consider the following previously unmerged feature. https://github.com/apache/jclouds/pull/86 In order to add a Guava verison range to the bundles rolled out by JClouds, the following import rule is added in the BND Configuration of the Project Module. Import Package: \ com.google.common.;version="[27.1,30.1.0)", \ okio.;version="[1.2.0,1.3)", \ * In the output of each JClouds module that uses Guava (and there are some) the configuration to the range version is observed. The bnd built into the JClouds project modules acts as a base of other bnd configurations, and should also apply in the Lab and Co repositories. Adjusted artefacts only become valid when a release is available or the build of these repositories is triggered again. Output - Core Module Import package: com.google.common.base;version="[27.1,30.1.0)", com.google.common.cache;version="[27.1,30.1.0)", com.google.common.collect;version="[27.1,30.1.0)", ... com.google.gson;version="[2.8,3)", ... Output - Blobstore Module Import package: com.google.common.base;version="[27.1,30.1.0)", com.google.common.collect;version="[27.1,30.1.0)", com.google.common.hash;version="[27.1,30.1.0)", ... com.google.inject;version="[1.4,2)", ... Oki version range The okhttp dependency requires okio version 1.2. The ok* libraries respectively the dependencies used in these libraries do not have OSGi instructions. For this reason, the previously integrated configuration is used. Local tests show that the import directive can also be set globally, see above. An explicit specification in the bnd file of the JClouds okHTTP module is not useful because this JClouds module also uses Guava. Output - OkHTTP Module Import package: com.google.common.base;version="[27.1,30.1.0)", com.google.common.collect;version="[27.1,30.1.0)", okio;version="[1.2.0,1.3)", com.google.inject;version="[1.4,2)", ... Note: In the following feature, the version of the "ok" framework has been significantly increased. Extensive adjustments are also performed. At this point, it should be noted that the import policy in the okio will probably have to be removed again because standalone OSGi metadata may be provided.	2021-01-31 22:03:59 +09:00
gurkerl83	8ac994c2b5	Integrate GSON library in Clouds Core Bundle Final In the last commit (last section of squashed commit), the GSON library was integrated into the JClouds core module using maven-bundle plugins include resource instruction. Building OSGi instruction variables from the respective modules show a weakness when resources such as script builder shell scripts are required to be integrated into the bundle but not provide a dedicated variable declaration for the resource section. The following commit demonstrates a change in strategy in declaration and integration of OSGi metadata. - Replace old bundle-plugin with newest bnd-plugin (bundle-plugin uses bnd-plugin internally) - Move OSGi metadata declarations from a maven variable passing strategy into dedicated bnd.bnd files + Cleaner pom files, no bundle packaging + Intellisense / Autocomplete support for .bnd files in terms of package exports etc. For demonstration, the overall OSGi adjustments are limited to project, core, script builder, compute, blob store, and load balancer because most custom OSGi metadata is defined here. Note: Other modules are currently disabled from build because some feedback is needed first. Make GSON integration work. To understand the changes, see the core modules' bnd file. GSON internal packages also define a version. Both already exported and new export declarations are fused. The global JClouds core module exports defined the entire set of GSON packages available. Some minor modifications were made in the module project; replace maven jar plugin with a minified version of the declaration, outsourced in projects bnd file.	2020-10-26 19:58:41 +09:00

Author

SHA1

Message

Date

gurkerl83

57f6bbc43a

Remove explicit OSGi import range of okio dep

All OkHttp components get shipped with any OSGi metadata. Tracking the progress of that issue from version 5 onwards, OkHttp finally provides OSGi support. Because JClouds OkHttp dependencies got renewed from 2.2.0 to the latest 3 (3.14.9), the respective bundles from Apache Servicemix got used in a deployment scenario. On the other hand, the problem with Servicemix is that there is no full match of published OkHttp dependencies to the respective bundle equivalent.

https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.okhttp

My test shows that none of the version 3 bundles work because of a missing package dependency "javax.annotation.meta". Sure higher version of 9 strips the javax.annotation module entirely, but the meta package is not there in JDK 8 either. As you can see from the link above, only two versions of 3.14 got published in the service mix; it is not clear to which version the bundle equivalents relate. From my understanding, it is much more important to use identical versions of OkHttp dependencies used in JClouds.

To utilize the original OKHttp libraries, consumer projects have to ensure those libraries get loaded using OSGi helper tools such as the wrap protocol provided by Apache Karaf or similar.

To reduce OSGi noise, I removed the OSGi import range of okio dependency entirely. A declaration like that does not make sense; otherwise, a set of Okhttp ranges must also be defined.

Note: The wildcard (*) declaration provides a way out, which allows any version of a package used in JClouds but itself does not give any OSGi metadata. Hopefully, I do not confuse you too much.

2021-02-12 18:57:46 +09:00

gurkerl83

85666982ae

Add OSGi version ranges, guice, okio

In the present feature, the two properties
- guava.osgi.import and
- okhttp.version
have not been attached to the build process (Bnd plugin), but have been recorded as comments only.

Before the resolution method is considered, the problem of Guava and its close coupling with Guice must be examined.

The Guice project possesses, differently to GSON no explicit configuration, how its dependencies are regarded in an OSGi execution environment.

Guice / Guava
- 4.1.0 / 19.0
- 4.2.0 /  [23.6,24)
- 4.2.1 / [25.1,26)
- 4.2.3 / [27.1,28) => used
- 5.0.0.BETA-1 / [27.1,28)

The version of Guice built into JClouds is 4.2.3. Increasing to this version number was not the subject of the current branch.

To avoid backward compatibility problems between Guice and Guava (e.g. Guice 4.2.3 -> Guava 24) this means that the version of Guava integrated in JClouds must be at least version 27.1. Guice puts this in its dependencies.

In my opinion, consumers (JClouds, as well as consumers of JClouds) should take this minimum barrier into account.

Resolution
To understand the resolution, please consider the following previously unmerged feature.
https://github.com/apache/jclouds/pull/86

In order to add a Guava verison range to the bundles rolled out by JClouds, the following import rule is added in the BND Configuration of the Project Module.

Import Package: \
    com.google.common.*;version="[27.1,30.1.0)", \
    okio.*;version="[1.2.0,1.3)", \
    *

In the output of each JClouds module that uses Guava (and there are some) the configuration to the range version is observed. The bnd built into the JClouds project modules acts as a base of other bnd configurations, and should also apply in the Lab and Co repositories. Adjusted artefacts only become valid when a release is available or the build of these repositories is triggered again.

Output - Core Module

Import package:
   com.google.common.base;version="[27.1,30.1.0)",
   com.google.common.cache;version="[27.1,30.1.0)",
   com.google.common.collect;version="[27.1,30.1.0)",
   ...
   com.google.gson;version="[2.8,3)",
   ...

Output - Blobstore Module

Import package:
   com.google.common.base;version="[27.1,30.1.0)",
   com.google.common.collect;version="[27.1,30.1.0)",
   com.google.common.hash;version="[27.1,30.1.0)",
   ...
   com.google.inject;version="[1.4,2)",
   ...

Oki version range
The okhttp dependency requires okio version 1.2. The ok* libraries respectively the dependencies used in these libraries do not have OSGi instructions. For this reason, the previously integrated configuration is used.

Local tests show that the import directive can also be set globally, see above. An explicit specification in the bnd file of the JClouds okHTTP module is not useful because this JClouds module also uses Guava.

Output - OkHTTP Module

Import package:
   com.google.common.base;version="[27.1,30.1.0)",
   com.google.common.collect;version="[27.1,30.1.0)",
   okio;version="[1.2.0,1.3)",
   com.google.inject;version="[1.4,2)",
   ...

Note:
In the following feature, the version of the "ok" framework has been significantly increased.  Extensive adjustments are also performed.

At this point, it should be noted that the import policy in the okio will probably have to be removed again because standalone OSGi metadata may be provided.

2021-01-31 22:03:59 +09:00

gurkerl83

8ac994c2b5

Integrate GSON library in Clouds Core Bundle Final

In the last commit (last section of squashed commit), the GSON library was integrated into the JClouds core module using maven-bundle plugins include resource instruction. Building OSGi instruction variables from the respective modules show a weakness when resources such as script builder shell scripts are required to be integrated into the bundle but not provide a dedicated variable declaration for the resource section.

The following commit demonstrates a change in strategy in declaration and integration of OSGi metadata.

- Replace old bundle-plugin with newest bnd-plugin (bundle-plugin uses bnd-plugin internally)
- Move OSGi metadata declarations from a maven variable passing strategy into dedicated bnd.bnd files
+ Cleaner pom files, no bundle packaging
+ Intellisense / Autocomplete support for .bnd files in terms of package exports etc.

For demonstration, the overall OSGi adjustments are limited to project, core, script builder, compute, blob store, and load balancer because most custom OSGi metadata is defined here.

Note: Other modules are currently disabled from build because some feedback is needed first.

Make GSON integration work.
To understand the changes, see the core modules' bnd file. GSON internal packages also define a version. Both already exported and new export declarations are fused. The global JClouds core module exports defined the entire set of GSON packages available.

Some minor modifications were made in the module project; replace maven jar plugin with a minified version of the declaration, outsourced in projects bnd file.

2020-10-26 19:58:41 +09:00

3 Commits