You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ioannis Canellos <io...@gmail.com> on 2013/11/29 10:59:01 UTC
Decoupling script builder from jclouds-core.
I would like to be able to use the jclouds-scriptbuilder outside of jclouds.
Currently jclouds script builder depends on jclouds-core, for the
following classes:
i) Credentials
ii) Nullable
iii) Maps2
Does it make sense to move login statements from script builder to
compute? That would eliminate (i).
Regarding (ii) the Nullable annotation is mostly used to let guice now
that we are ok with injecting null values, so inside the scriptbuilder
(chef statements) it only serves the purpose of documenting the code.
So it cab be just removed (if we decide to).
On (iii) its a single method used.
If the idea of moving the login statements to compute make sense then
(ii) and (iii) are really trivial to fix. wdyt?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Decoupling script builder from jclouds-core.
Posted by Ioannis Canellos <io...@gmail.com>.
Personally, I'd like the split to be at the maven module level.
However, this would result in breaking forward compatibility.
So, the PR suggests an alternative that could be even part of 1.7
without compromising compatibility.
Re: Decoupling script builder from jclouds-core.
Posted by Andrew Phillips <ap...@qrmedia.com>.
> So an other approach we could use before 2.0.0 is:
>
> i) Remove the @Nullable annotation from Chef specific functions inside
> script builder (they are only serve documentation purposeless anyway).
> ii) Dublicate transformEntries from Maps2 to script builder utils
> iii) Modify the OSGi metadata and make the packages that are using
> jclouds-core optional (luckily our current structure allows us to do
> that, because packages that directly refer to jclouds-core are
> isolated).
>
> How does this sounds instead?
I'm guessing this is #219 [1]? I'm OK with the code duplication, but
the "making some of the imports optional" seems to be like a bit of a
quick fix to allow "some of" this package to be imported.
No problems with a quick fix if it solves an immediate issue, but it
would be nice to see the splitting done at the Maven project level
too, at some point.
ap
[1] https://github.com/jclouds/jclouds/pull/219
Re: Decoupling script builder from jclouds-core.
Posted by Ioannis Canellos <io...@gmail.com>.
So I created a PR: https://github.com/jclouds/jclouds/pull/219
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Decoupling script builder from jclouds-core.
Posted by Ioannis Canellos <io...@gmail.com>.
Hmmm, there is no need to remove @Nullable if we are going to make
packages optional.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Decoupling script builder from jclouds-core.
Posted by Ioannis Canellos <io...@gmail.com>.
I think that what I had in mind will break both forward and backward
compatibility so it would only be feasible to jclouds 2.0.0 (in order
to respect semantic versioning).
So an other approach we could use before 2.0.0 is:
i) Remove the @Nullable annotation from Chef specific functions inside
script builder (they are only serve documentation purposeless anyway).
ii) Dublicate transformEntries from Maps2 to script builder utils
iii) Modify the OSGi metadata and make the packages that are using
jclouds-core optional (luckily our current structure allows us to do
that, because packages that directly refer to jclouds-core are
isolated).
Pros:
- Minimal amount of changes.
- Doesn't break forward compatibility.
- It will play well in all cases (including OSGi).
Cons:
- A tiny bit of code duplication.
How does this sounds instead?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Decoupling script builder from jclouds-core.
Posted by Ignasi Barrera <ig...@gmail.com>.
I also think decoupling it from jclouds-core is a good idea. However, as
Everett, I'm not sure about making it jclouds independent.
Decoupling it shouldn't introduce any incompatibility issues as long as we
keep the groupId and artifactId of the project.
These are the few things to take care of, that come to my mind:
* The jclouds-compute module depends on it to create the bootstrap scripts
(the "wrapInitScript" option in the RunScriptOptions is enabled by default
and very very useful). We want to make sure we don't break this and keep
jclouds-compute working without changes here.
* There is specific code to parse the license headers when joining several
script fragments into the final script, to remove the repeated ones. This
is a requirement to properly license the source code, but generate proper
scripts. This is very jclouds specific but shouldn't be lost.
* I'm pretty sure many people is using the scriptbuilder tools/recipes to
bootstrap the nodes they deploy. Let's try to break the minimum! :)
Having said this, I look forward to see that PR!
Ignasi
El 30/11/2013 19:21, "Everett Toews" <ev...@rackspace.com> escribió:
> I agree that decoupling script builder from jclouds-core is a good idea.
>
> I'm concerned about what, if any, backwards incompatible changes this
> would introduce to our users.
>
> Ioannis, before the PR, please give us an indication of any backwards
> incompatible changes this might cause. If there are considerable
> incompatibilities it would be best if you approached our users and gave
> them your plan and a chance to voice their opinions. Jeremy did this in
> this thread, New RegionScopedSwiftBlobStore in jclouds 1.7 [1]. So
> something like that would be appropriate.
>
> I'm not as sure about making it completely jclouds independent . It
> certainly needs to be decoupled as a first step and we can explore things
> after that.
>
> Thanks,
> Everett
>
> [1]
> http://www.mail-archive.com/user@jclouds.incubator.apache.org/msg00477.html
>
>
> On Nov 29, 2013, at 8:47 AM, Ioannis Canellos wrote:
>
> > I agree!
> >
> > I'll work an PR!
>
>
Re: Decoupling script builder from jclouds-core.
Posted by Everett Toews <ev...@RACKSPACE.COM>.
I agree that decoupling script builder from jclouds-core is a good idea.
I'm concerned about what, if any, backwards incompatible changes this would introduce to our users.
Ioannis, before the PR, please give us an indication of any backwards incompatible changes this might cause. If there are considerable incompatibilities it would be best if you approached our users and gave them your plan and a chance to voice their opinions. Jeremy did this in this thread, New RegionScopedSwiftBlobStore in jclouds 1.7 [1]. So something like that would be appropriate.
I'm not as sure about making it completely jclouds independent . It certainly needs to be decoupled as a first step and we can explore things after that.
Thanks,
Everett
[1] http://www.mail-archive.com/user@jclouds.incubator.apache.org/msg00477.html
On Nov 29, 2013, at 8:47 AM, Ioannis Canellos wrote:
> I agree!
>
> I'll work an PR!
Re: Decoupling script builder from jclouds-core.
Posted by Ioannis Canellos <io...@gmail.com>.
I agree!
I'll work an PR!
Re: Decoupling script builder from jclouds-core.
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Does it make sense to move login statements from script builder to
> compute? That would eliminate (i).
I don't know scriptbuilder too well, but I think if we really want to
decouple it we should take *all* hard-coded statements out of it and
make the script building "engine" a separate (potentially
jclouds-independent) module which is used by jclouds-scriptbuilder to
generate the relevant scripts.
In this way, we would not have to move stuff around *in jclouds* too much.
@iocanel: would a "scriptbuilder engine" be enough for you? How much
effort do you think it would be to pull something like that out? If
so, a PR would obviously be a great way to see how big the impact of
the change actually is ;-)
ap