Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2

Thanks for the additional detail, from all.

I can give my +1 to this, under the following conditions:

Primarily, after re-reading
this seems more like a "works with" dependency, than an exempt pre-req. I do not think pervasive enough to qualify as an exempt pre-req.

The third party package must not be installed automatically by a touch point. That seems too heavy handed, and depending on many other packaging details, users may end up installing the bundles/features but not really want to use it or be aware of extra things being installed. (There are other ways to make it easy to install, such as from preferences, but even there, the non-EPL license must be explicitly presented to the user, if you implement that "easy to install" preference). [Mylyn uses that model, or used to, for some of its connectors, if you need an example to follow].

The functionality must be packaged as a feature, so easy for adopters or packages or users to leave out of their particular distribution or install, if desired.

I hope none of those are controversial, but just wanted to be explicit.

I has glad to read that it will work with Version 1.7.2 or higher, since in the past, we've sometimes "forced" users to downgrade some external package to use some part of Eclipse, which isn't nice.

Please comment, especially if anyone disagrees with the "works with" designation, since that's what I am voting "for".


From:        Roland Grunberg <rgrunber@xxxxxxxxxx>
To:        Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date:        10/14/2015 10:44 AM
Subject:        Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
Sent by:        tools-pmc-bounces@xxxxxxxxxxx

> > Is the "version" (1.7.2) a hard constraint? Or does that must mean 1.7.2 or
> > above?
> I think that one can't file CQ using "any" as version which would make sense
> in such cases where the tool is simply invoking another executable. So we
> can read that as 1.7.2 or above.

When the textbox requested a version it wasn't clear to me if I could say 'any'
so I went with 1.7.2 since that's what I've been using for testing, although
there are newer releases. It can be read as 1.7.2 or above, and if there were
enough demand to support earlier versions we could look into it.

> >
> > Also, you say "when \'vagrant\' isn\'t present, it
> > would be pretty useless." You mean one specific feature of "Linux tools",
> > right? Not the whole package?
> Linux Tools consist of multiple tools that are integrating underlying tools
> so if vagrant is missing only the vagrant feature will be useless. And it
> would not be entirely useless as we may use p2 touchpoint
> checkAndPromptNativePackage to make the plugin request installation of
> vagrant which would increase the chances to get the plugin working.

Yes, just the vagrant plugin functionality would be unusable. There are
currently just 2 plugins (org.eclipse.linuxtools.vagrant.core, and
org.eclipse.linuxtools.vagrant.ui) which will be contributing to this

We could definitely use the native installation touchpoint contributed not
that long ago into equinox.p2 to call the system native installer
(aptitude, yum/dnf, etc.) to attempt to install vagrant. This would be nice
to do in the future.

> >
> > Also, are there any alternatives? Other OS software that in theory someone
> > might want to use instead? If so, I just wanted to be sure there was at
> > least
> > some potential to be open or pluggable, even if in future.
> There is no plan to be pluggable or extendable or smth like this. The goal is
> to get the common case automated within the IDE.
> It might make sense to come up with common containers/vms/etc. basic
> management modules and widgets which can be used by plugins like docker,
> vagrant, name_yours to make adding new one (when it appears and this seems
> to happen quite often nowadays). But this is work for the future when the
> most common user scenario is covered and there are resources for such work.

In the future it would be great to pull out a common framework for both
containers, and vagrant since there are terms that map onto each other, and
since at least initially the UI for Vagrant tooling will be a subset of the one
used for Docker tooling.

> >
> > I just spent 30 seconds looking, but this post caught my eye:
> >

I have heard of higher-level wrappers around Vagrant such as oh-my-vagrant
( and I have considered using such
a tool but decided to go with just vagrant for now. In addition there is Otto
( although even the
language seems to suggest Vagrant won't be going away.

Roland Grunberg
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top