I totally agree with Andrew's point, but we need to be careful when deprecating this. There are projects that rely on our OSGi support (take Apache Brooklyn IIRC as an example), and we don't want to leave them orphan, at least with a clear direction and position from jclouds.
The only real reason we have jclouds-karaf today is as a validator to make sure we remain OSGi compatible, but we are paying a price that is too high for that. The jclouds community has no expertise there (at least the active community), and whilst the Karaf community has been willing to help, results are not materializing. Engagement with the Karaf community started in June 2018 (almost a year ago), and we are still at a point where we have not been able to see anything but promises of commitment that never get to actual results. Don't take this statement wrong: I'm not blaming the Karaf community and I hugely appreciate their willingness to help. I'm just exposing the facts that outline the issue we have: we cannot depend on something we don't have the expertise on, even more when that dependency is not part of the core of the value jclouds provides. So I agree with Gaul and I think we should remove jclouds-karaf and the jclouds-cli and properly communicate that to downstream users of those projects. I don't see a clear and realistic path to keeping those projects in a sustainable way, so I think this would be a good move for the project. Ignasi On Sun, 7 Apr 2019 at 22:22, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Andrew, > > about jclouds-karaf, can you please leave as is ? I'm working on it, and > I should have the PR ready soon. > > Regards > JB > > On 08/04/2019 07:12, Andrew Gaul wrote: > > jclouds has stalled on upgrading our Guava dependency[1] due to our > > Karaf dependency. Our team lacks the background and volunteers lack the > > time to resolve this despite over a year of discussion. I propose > > removing jclouds-karaf and jclouds-cli from the build and posting > > notices in the README and user mailing lists. When a volunteer can > > resolve this we can reintegrate this support. > > > > Some background on why this is important: our Guava dependency has > > repeated annoyed users it used to have an aggressive deprecation policy > > and jclouds depended on @Beta APIs. Newer versions of Guava depend on > > Java 8 but our Karaf version seems to have an incompatibility. Attempts > > to upgrade it have failed. > > > > As a matter of strategy, I think jclouds should narrow its focus since > > many of the more active developers, including me, now split our time > > with other projects. We should consider removing some of the labs > > providers and other incomplete efforts to reduce the maintenance burden. > > As a concrete suggestion, I would like to remove the jdbc labs provider. > > > > [1] https://issues.apache.org/jira/projects/JCLOUDS/issues/JCLOUDS-1333 > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
