Ok. In that case, I think I can prepare release 0.2.6 for a vote. Unless, 
there’s something else?


> On Jul 1, 2021, at 11:10 AM, Robert Munteanu <[email protected]> wrote:
> 
> Hi Cris,
> 
> If parallel versions don't cause any problems I would suggest that we
> keep metrics-core 4 as a bundle, allowing deployers to update to new
> versions if needed.
> 
> Thanks,
> Robert
> 
> On Thu, 2021-07-01 at 10:27 -0400, Cris Rockwell wrote:
>> Hi Robert 
>> 
>> OpenSAML has Metrics 4.1.18 as a dependency [1]. 
>> Sling uses metrics-core 3.2.6 which was released in 2017. 
>> Since then, only v4 has active development according to the releases
>> in Central [3].
>> 
>> So I think Sling should probably update to the newer version if
>> possible. 
>> Until then the SAML bundle could either embed metrics-core v4.1.18+
>> or it could require parallel versions. 
>> Which is better in your opinion?
>> 
>> Cris
>> 
>> [1]
>> https://git.shibboleth.net/view/?p=java-parent-project.git;a=blob;f=pom.xml;h=d87758e21f1cf63222959a9ca7631585128f8573;hb=HEAD
>> [2]
>> https://github.com/apache/sling-org-apache-sling-starter/blob/96b8df17cd09f7b72ba6794f25d75a524f7e1215/src/main/features/base.json
>> [3]
>> https://mvnrepository.com/artifact/io.dropwizard.metrics/metrics-core
>> 
>> 
>>> On Jul 1, 2021, at 9:05 AM, Robert Munteanu <[email protected]>
>>> wrote:
>>> 
>>> On Tue, 2021-06-29 at 18:48 -0400, Cris Rockwell wrote:
>>>> Hi Robert
>>>> 
>>>>> Why are there version ranges used in the pom?
>>>> I was using Maven bracket notation for version ranges that I had
>>>> actually tested. But I see it’s not needed, and removed the
>>>> bracket
>>>> range on the versions. Now it builds without downloading any
>>>> SNAPSHOTS.
>>>> 
>>>> 
>>>>> checker-qual-2.11.1.jar
>>>>> error_prone_annotations-2.3.4.jar 
>>>>> failureaccess-1.0.1.jar
>>>> 
>>>> These are dependencies of Google Guava, which is also an embedded
>>>> dependency. If I didn't embed Guava, the deps above wouldn’t be
>>>> needed.
>>>> Sling comes with Guava v15. But OpenSAML libraries currently
>>>> require
>>>> 30.1.1-jre. Having a recent version of Guava installed as a
>>>> bundle
>>>> could help a lot. But having both versions as bundles doesn’t
>>>> seem to
>>>> work. I am getting the error below...
>>> 
>>> As Julian mentioned, embedding Guava is the only safe solution
>>> right
>>> now. And thank you for looking into the additional dependencies and
>>> making sure they can be used as OSGi bundles, this will make
>>> deployments simpler.
>>> 
>>>> 
>>>> Import-Package: com.codahale.metrics; version="[4.1, 5)",
>>>> com.google.common.base; version="[30.1, 31)",
>>>> com.google.common.collect; version="[30.1, 31)",
>>>> com.google.common.escape; version="[30.1, 31)",
>>>> com.google.common.io <http://com.google.common.io/> 
>>>> <http://com.google.common.io/ <http://com.google.common.io/>>;
>>>> version="[30.1, 31)", com.google.common.net <http://com.google.common.net/>
>>>> <http://com.google.common.net/ <http://com.google.common.net/>>; 
>>>> version="[30.1, 31)",
>>>> 
>>>>> metrics-core-4.1.9.jar
>>>> 
>>>> Upgrading metrics-core past v3 causes a lot of problems with many
>>>> Sling bundles. I counted ~40 bundles that went from Active to
>>>> Installed state. But when installed with parallel versions  (v3
>>>> and
>>>> v4) everything seems fine.
>>> 
>>>> 
>>> Is the metrics bundle something you're consuming or required by a
>>> dependency? Ideally we would be working with whatever is supported
>>> by
>>> the current Sling Starter / commons.metrics bundle.
>>> 
>>> Thanks,
>>> Robert

Reply via email to