I think it makes sense to me as well. How would you migrate this? Deprecating the project in Gitbox/Github and promoting the new repo so that downstream projects can figure it out?
On Tue, Apr 9, 2019 at 5:29 PM Ignasi Barrera <[email protected]> wrote: > 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 > > >
