The determination of whether something is an exempt pre-req is
within the purview of the EMO. In the past the approach that we
have consistently taken with LinuxTools is that if a component is
referencing a particular runtime (e.g. Docker, LTTng, ...) then it
can be reasonably described as an exempt pre-req. The idea being
that if someone wants to use Docker tools, they probably have
At least that's how we've done it so far.
Hope that helps.
On 14/10/2015 11:33 AM, David M Williams wrote:
Thanks for the
additional detail, from
I can give my +1 to this, under
Primarily, after re-reading
this seems more like a "works
dependency, than an exempt pre-req. I do not think pervasive
qualify as an exempt pre-req.
The third party package must not
installed automatically by a touch point. That seems too heavy
and depending on many other packaging details, users may end up
the bundles/features but not really want to use it or be aware
things being installed. (There are other ways to make it easy to
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
if you need an example to follow].
The functionality must be
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
but just wanted to be explicit.
I has glad to read that it will
with Version 1.7.2 or higher, since in the past, we've sometimes
users to downgrade some external package to use some part of
Please comment, especially if
disagrees with the "works with" designation, since that's what
I am voting "for".
Tools PMC mailing list
10/14/2015 10:44 AM
[CQ 10263] vagrant Version: 1.7.2
> > 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
would make sense
> in such cases where the tool is simply invoking another
> 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
so I went with 1.7.2 since that's what I've been using for
there are newer releases. It can be read as 1.7.2 or above,
and if there
enough demand to support earlier versions we could look into
> > Also, you say "when \'vagrant\' isn\'t present, it
> > would be pretty useless." You mean one specific
of "Linux tools",
> > right? Not the whole package?
> Linux Tools consist of multiple tools that are
> so if vagrant is missing only the vagrant feature will be
> would not be entirely useless as we may use p2 touchpoint
> checkAndPromptNativePackage to make the plugin request
> vagrant which would increase the chances to get the
Yes, just the vagrant plugin functionality would be unusable.
currently just 2 plugins (org.eclipse.linuxtools.vagrant.core,
org.eclipse.linuxtools.vagrant.ui) which will be contributing
We could definitely use the native installation touchpoint
that long ago into equinox.p2 to call the system native
(aptitude, yum/dnf, etc.) to attempt to install vagrant. This
to do in the future.
> > Also, are there any alternatives? Other OS software
that in theory
> > might want to use instead? If so, I just wanted to
be sure there
> > least
> > some potential to be open or pluggable, even if in
> There is no plan to be pluggable or extendable or smth
The goal is
> to get the common case automated within the IDE.
> It might make sense to come up with common
> 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
> to happen quite often nowadays). But this is work for the
> most common user scenario is covered and there are
resources for such
In the future it would be great to pull out a common framework
containers, and vagrant since there are terms that map onto
since at least initially the UI for Vagrant tooling will be a
used for Docker tooling.
> > I just spent 30 seconds looking, but this post
caught my eye:
> > http://stackoverflow.com/questions/7280875/a-better-alternative-to-vagrant
I have heard of higher-level wrappers around Vagrant such as
and I have considered using such
a tool but decided to go with just vagrant for now. In
addition there is
although even the
language seems to suggest Vagrant won't be going away.
tools-pmc mailing list
To change your delivery options, retrieve your password, or
from this list, visit
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit