hi, in my day job my group is a consumer of jclouds and jclouds-cli:
regarding jclouds jar : Pretty much need to update the gson dependency because of conflicts with other major frameworks in our application. Regarding cli : i have to admit that the source is pretty neat . As a consumer i can live with getting that from a different apache project and even with having an not so upfront jclouds implementation for it now, since it just works for us as is rifht now. regards, olaf > Am 09.04.2019 um 07:46 schrieb Francois Papon <francois.pa...@openobject.fr>: > > Hi JB, > > I think it make sense to move it as a Karaf subproject as we started the > Kloud initiative. > > regards, > > François Papon > fpa...@apache.org > >> Le 09/04/2019 à 09:24, Jean-Baptiste Onofré a écrit : >> Up to you guys. >> >> An alternative would be to move jclouds-karaf as karaf subproject (like >> decanter, cave, etc). >> >> Thoughts ? >> >> Regards >> JB >> >>> On 08/04/2019 22:56, Ignasi Barrera wrote: >>> I totally agree with Andrew's point, but we need to be careful when >>> deprecating this. There are projects that rely on our OSGi support (take >>> Apache Brooklyn IIRC as an example), and we don't want to leave them >>> orphan, at least with a clear direction and position from jclouds. >>> >>> The only real reason we have jclouds-karaf today is as a validator to make >>> sure we remain OSGi compatible, but we are paying a price that is too high >>> for that. The jclouds community has no expertise there (at least the active >>> community), and whilst the Karaf community has been willing to help, >>> results are not materializing. Engagement with the Karaf community started >>> in June 2018 (almost a year ago), and we are still at a point where we have >>> not been able to see anything but promises of commitment that never get to >>> actual results. >>> >>> Don't take this statement wrong: I'm not blaming the Karaf community and I >>> hugely appreciate their willingness to help. I'm just exposing the facts >>> that outline the issue we have: we cannot depend on something we don't have >>> the expertise on, even more when that dependency is not part of the core of >>> the value jclouds provides. >>> >>> >>> So I agree with Gaul and I think we should remove jclouds-karaf and the >>> jclouds-cli and properly communicate that to downstream users of those >>> projects. I don't see a clear and realistic path to keeping those projects >>> in a sustainable way, so I think this would be a good move for the project. >>> >>> Ignasi >>> >>> >>>> On Sun, 7 Apr 2019 at 22:22, Jean-Baptiste Onofré <j...@nanthrax.net> >>>> wrote: >>>> >>>> Hi Andrew, >>>> >>>> about jclouds-karaf, can you please leave as is ? I'm working on it, and >>>> I should have the PR ready soon. >>>> >>>> Regards >>>> JB >>>> >>>>> On 08/04/2019 07:12, Andrew Gaul wrote: >>>>> jclouds has stalled on upgrading our Guava dependency[1] due to our >>>>> Karaf dependency. Our team lacks the background and volunteers lack the >>>>> time to resolve this despite over a year of discussion. I propose >>>>> removing jclouds-karaf and jclouds-cli from the build and posting >>>>> notices in the README and user mailing lists. When a volunteer can >>>>> resolve this we can reintegrate this support. >>>>> >>>>> Some background on why this is important: our Guava dependency has >>>>> repeated annoyed users it used to have an aggressive deprecation policy >>>>> and jclouds depended on @Beta APIs. Newer versions of Guava depend on >>>>> Java 8 but our Karaf version seems to have an incompatibility. Attempts >>>>> to upgrade it have failed. >>>>> >>>>> As a matter of strategy, I think jclouds should narrow its focus since >>>>> many of the more active developers, including me, now split our time >>>>> with other projects. We should consider removing some of the labs >>>>> providers and other incomplete efforts to reduce the maintenance burden. >>>>> As a concrete suggestion, I would like to remove the jdbc labs provider. >>>>> >>>>> [1] https://issues.apache.org/jira/projects/JCLOUDS/issues/JCLOUDS-1333 >>>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>>
