You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Gaul <ga...@apache.org> on 2019/04/08 05:12:49 UTC
remove jclouds-karaf and other maintenance burdens
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
--
Andrew Gaul
http://gaul.org/
Re: remove jclouds-karaf and other maintenance burdens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net> 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 <na...@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é <jb...@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 <ga...@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.papon@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
>>>>>>>>> fpapon@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é <
>>>> jb@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é
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Andrew Gaul
>>>>>>> http://gaul.org/
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: remove jclouds-karaf and other maintenance burdens
Posted by Ignasi Barrera <na...@apache.org>.
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é <jb...@nanthrax.net> 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 <na...@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é <jb...@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 <ga...@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.papon@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
> >>>>>>> fpapon@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é <
> >> jb@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é
> >>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Andrew Gaul
> >>>>> http://gaul.org/
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <na...@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é <jb...@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 <ga...@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.papon@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
>>>>>>> fpapon@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é <
>> jb@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é
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Andrew Gaul
>>>>> http://gaul.org/
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: remove jclouds-karaf and other maintenance burdens
Posted by Andrea Turli <an...@gmail.com>.
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 <na...@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é <jb...@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 <ga...@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.papon@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
> > >>>> fpapon@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é <
> jb@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é
> > >>>>>>> jbonofre@apache.org
> > >>>>>>> http://blog.nanthrax.net
> > >>>>>>> Talend - http://www.talend.com
> > >>>>>>>
> > >>>
> > >>
> > >> --
> > >> Andrew Gaul
> > >> http://gaul.org/
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Ignasi Barrera <na...@apache.org>.
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é <jb...@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 <ga...@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.papon@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
> >>>> fpapon@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é <jb...@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é
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>>>
> >>>
> >>
> >> --
> >> Andrew Gaul
> >> http://gaul.org/
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <ga...@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 <fr...@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
>>>> fpapon@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é <jb...@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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>
>>
>> --
>> Andrew Gaul
>> http://gaul.org/
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: remove jclouds-karaf and other maintenance burdens
Posted by Olaf Flebbe <of...@oflebbe.de>.
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 <ga...@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 <fr...@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
>>> fpapon@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é <jb...@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é
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>
>
> --
> Andrew Gaul
> http://gaul.org/
Re: remove jclouds-karaf and other maintenance burdens
Posted by Andrew Gaul <ga...@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 <fr...@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
> > fpapon@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é <jb...@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é
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
>
--
Andrew Gaul
http://gaul.org/
Re: remove jclouds-karaf and other maintenance burdens
Posted by Olaf Flebbe <of...@oflebbe.de>.
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 <fr...@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
> fpapon@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é <jb...@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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Francois Papon <fr...@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
fpapon@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é <jb...@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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: remove jclouds-karaf and other maintenance burdens
Posted by Ignasi Barrera <na...@apache.org>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: remove jclouds-karaf and other maintenance burdens
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com