hi andrew, Forgot to mention that i am only a consumer for blobstores as well. will look into your approach. Karaf seems to be a very heavyweight approach to just have a cli.
olaf > Am 09.04.2019 um 08:26 schrieb Andrew Gaul <[email protected]>: > > 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 >>> <[email protected]>: >>> >>> Hi JB, >>> >>> I think it make sense to move it as a Karaf subproject as we started the >>> Kloud initiative. >>> >>> regards, >>> >>> François Papon >>> [email protected] >>> >>>> 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é <[email protected]> >>>>>> 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é >>>>>> [email protected] >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >> > > -- > Andrew Gaul > http://gaul.org/
