Hi, I would do the following:
1. Vote on jclouds and karaf dev mailing lists for the donation 2. Setup a new karaf-jclouds repo with infra 3. Do the change for the code move (changing parent, etc) 4. Deprecated the "old" repo adding a README to mention the new one If you agree, I will start those actions. Regards JB On 09/04/2019 21:39, Andrea Turli wrote: > 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 <n...@apache.org> 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é <j...@nanthrax.net> 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 <g...@apache.org>: >>>>> >>>>> 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/ >>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
