jclouds/drivers/okhttp/pom.xml

73 lines
2.5 KiB
XML
Raw Normal View History

<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.jclouds</groupId>
<artifactId>jclouds-project</artifactId>
<version>2.6.0-SNAPSHOT</version>
<relativePath>../../project/pom.xml</relativePath>
</parent>
<groupId>org.apache.jclouds.driver</groupId>
<artifactId>jclouds-okhttp</artifactId>
<name>jclouds OkHttp Driver</name>
<description>OkHttp Driver</description>
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-03 16:55:29 -05:00
<properties>
<okio.version>3.4.0</okio.version>
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-03 16:55:29 -05:00
</properties>
<dependencies>
<dependency>
<groupId>org.apache.jclouds</groupId>
<artifactId>jclouds-core</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.apache.jclouds</groupId>
<artifactId>jclouds-core</artifactId>
<version>${project.version}</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
<version>${okhttp.version}</version>
</dependency>
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-03 16:55:29 -05:00
<dependency>
<groupId>com.squareup.okio</groupId>
<artifactId>okio</artifactId>
<version>${okio.version}</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>mockwebserver</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp-tls</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>