|
All,
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
Docker installed.
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
all.
I can give my +1 to this, under
the
following conditions:
Primarily, after re-reading
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
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".
Thanks,
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
functionality.
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:
> > http://stackoverflow.com/questions/7280875/a-better-alternative-to-vagrant
I have heard of higher-level wrappers around Vagrant such as
oh-my-vagrant
(https://github.com/purpleidea/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
(https://www.ottoproject.io/intro/vagrant-successor.html)
although even the
language seems to suggest Vagrant won't be going away.
Cheers,
--
Roland Grunberg
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
|
