Agree that a CLI provides value but the Karaf-based CLI is a maintenance burden. I recommend moving to a more lightweight approach that I demonstrate here:
https://github.com/gaul/blobstore-cli This has the advantage of starting much faster for interactive tasks. I only have interest in blobstore so I cannot implement all the compute functionality. However, jclouds could accept contributions for this! On Tue, Apr 09, 2019 at 08:13:36AM +0200, Olaf Flebbe wrote: > 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 > >>>> > -- Andrew Gaul http://gaul.org/
