I think moving jclouds-karaf and the cli to the Karaf project makes a lot of sense.
On Tue, Apr 9, 2019, 00:58 Jean-Baptiste Onofré <[email protected]> wrote: > Hi, > > FYI, you can run karaf-shell without the whole karaf container and > without OSGi. > > I can also provide a static karaf distribution with a very light > approach (I blogged about that recently). > > Regards > JB > > On 09/04/2019 08:29, Olaf Flebbe wrote: > > 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/ > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
