Re: remove jclouds-karaf and other maintenance burdens
Good point about the repo, as they already have on apache/jclouds-karaf, we can keep as it is and I will update the parent, etc. Regards JB On 10/04/2019 06:36, Ignasi Barrera wrote: > Yes, both communities should vote on that. > Regarding the repo, both jclouds-karaf and jclouds-cli are in the Apache > org, so strictly speaking it should be just a matter of infra updating the > PMC and permissions for those repos (unless you want to host them as > subfolders of an existing repo). If you want to keep the repo, then > migration is even easier for users. Home remains the same; it just changes > the team that actually manages it. > > Let's clarify the approach before starting a formal vote? > > On Tue, 9 Apr 2019 at 21:10, Jean-Baptiste Onofré wrote: > >> 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 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é >> 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 : >>> >>> 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
Re: remove jclouds-karaf and other maintenance burdens
Yes, both communities should vote on that. Regarding the repo, both jclouds-karaf and jclouds-cli are in the Apache org, so strictly speaking it should be just a matter of infra updating the PMC and permissions for those repos (unless you want to host them as subfolders of an existing repo). If you want to keep the repo, then migration is even easier for users. Home remains the same; it just changes the team that actually manages it. Let's clarify the approach before starting a formal vote? On Tue, 9 Apr 2019 at 21:10, Jean-Baptiste Onofré wrote: > 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 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é > 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 : > > > > 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
Re: remove jclouds-karaf and other maintenance burdens
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 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é 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 : > > 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
Re: remove jclouds-karaf and other maintenance burdens
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 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é 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 : > > >> > > >> 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
Re: remove jclouds-karaf and other maintenance burdens
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é 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 : > >> > >> 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é > 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
Re: remove jclouds-karaf and other maintenance burdens
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 : >> >> 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 : 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é >>> 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.
Re: remove jclouds-karaf and other maintenance burdens
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 : > > 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 >>> : >>> >>> 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é >> 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. >>> >>>
Re: remove jclouds-karaf and other maintenance burdens
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 > > : > > > > 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é > 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/
Re: remove jclouds-karaf and other maintenance burdens
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 : > > 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é 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
Re: remove jclouds-karaf and other maintenance burdens
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é 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 >>>
Re: remove jclouds-karaf and other maintenance burdens
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é 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 >> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: remove jclouds-karaf and other maintenance burdens
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é 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 >
Re: remove jclouds-karaf and other maintenance burdens
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
