I've opened the following pull requests to workaround the issue: https://github.com/jclouds/jclouds-karaf/pull/86 https://github.com/jclouds/jclouds-cli/pull/35
I've done it in a way that there is only a workaround in the CLI, but keep karaf unchanged and OSGi friendly. The CLI just fallbacks to the regular ScriptEnginManager if none is defined for a karaf command. If you find the patch OK I'll merge the PRs and the OneAndOne tests one, and proceed with the RC3. Regarding the CLI deprecation, we'd better create a specific thread for that. I really think the jclouds-karaf project has a lot of value, as allows us to properly validate that we remain OSGi compatible. There are also downstream users that build products with jclouds and OSGI (for example the CloudSoft AMP [1]), so having a way to validate that jclouds can run in OSGi environments is something we should have. Deprecating the CLI is another topic, but taking into account that it is just one single main class, and does not introduce overhead (and it is pretty convenient to cleanup the providers for our live tests builds, in fact there is a build in Jenkins that runs the CLI to delete all nodes in a provider after the live tests), I don't have a strong opinion on deprecating it. So... Good to go for the patches and green light to start the RC3? [1] http://www.cloudsoft.io/amp-4 On 9 November 2016 at 18:06, Andrew Phillips <aphill...@qrmedia.com> wrote: > I have ambivalence about this. jclouds-cli consumes a lot of resources >> relative to its limited user base. >> > > Agreed. To me, this is definitely another datapoint pointing towards a > deprecation discussion for the CLI as a whole. I just would prefer not to > release a *broken* version. > > Regards > > ap >
