John,
Comments below.
On 23/09/2011 11:03 AM, John Arthorne wrote:
I know we've had this
debate before, but
I just wanted to jump in and say I think build-time substitution
of version
ranges is a bad idea.
I don't disagree. Unfortunately I think unverified version ranges
is also a bad idea in some regards: I'd be willing to bet that there
are countless examples of stale lower bounds. The vanishingly small
EMF team is just not in a position to manage this manually for 150
plugins and features we maintain.
Clearly we lack tools
that can accurately determine
the correct range depending on our actual API usage of our
required bundles/packages.
In an ideal world we could generate *correct* ranges using
tools.
Yes, and we would test them to verify correctness.
Without
that, we have two options: 1) maintain ranges manually and risk
that they
are sometimes too wide
Yes, and therefore meaningless.
2) generate range at
build-time and only allow consumers
to use the versions that we built against. I think this second
option is
far too limiting. It is almost certainly disallowing
configurations that
actually work fine.
Every time we set an upper bound, we make this decision on that end
of the scale. For example, we assumed EMF would be broken for 4.x
but when the e4 team wanted to use EMF they found this to be
limiting. And of course EMF wasn't and isn't broken with 4.x. So
even in this case, is it better to let people install something that
ultimately doesn't work, or let them install something only if we're
very/quite/somewhat sure it works?
As component producers I think we
should
err on the side of being permissive rather than adding an
arbitrary limitation
here. Perhaps a company wants to take for example a part of EMF
Juno and
run it with a project from Indigo that is no longer in the
release train.
Yes, for example, folks at itemis really want EMF's core runtime to
work with Eclipse 3.5. I experimented with that and it does indeed
almost work...
But I interpret this to mean we should build and test against 3.5
and them hopefully test with 3.6, 3.7, 3.8 and 4.x...
They can do all their own testing to prove to themselves that
this combination
works, but the build-time substituted version range won't allow
it. This
seems equivalent to, for example, disallowing your plugin
running on anything
but Windows 7 because that is the platform where you compiled
and did all
your testing (I will kindly disallow my users running on Linux
because
I haven't tested it myself and maybe it won't work).
I think if we did what Konstantin described we'd get close to the
ideal along with the strong assurance that it really does work
without the manual maintenance effort.
Anyway, this probably isn't the
place
to rehash this debate - I just wanted to counterbalance the
"build-time
range substitution is ideal" viewpoint with the flip side of the
argument...
Yes, there are definitely trade-offs. Another nice thing about not
having ranges in the source repo is you can extract the source and
try it without having to change dozens or hundreds of numbers that
restrict your ability to even try. Anyway, it's a thorny issue and
the life is generally far from ideal...
John
Konstantin,
That sounds totally ideal!
Regards,
Ed
On 23/09/2011 9:34 AM, Konstantin Komissarchik wrote:
In case this helps…
In Sapphire, we also
use
automatic insertion of version ranges into dependencies based on
targets
used at build, but we define multiple targets for the build to
work with.
At the high level,
the build
takes three parameters:
1. List of targets.
Currently
“galileo,galileo-sr1,galileo-sr2,indigo,indigo-sr1,juno-38,juno-42”.
2. Oldest supported
target.
Currently “galileo”.
3. Recommended
target. Currently
“juno-42”.
The main build runs
against
the recommended target. A partial build is repeated against all
other targets
to check for problems that could be caught at compile time (such
as use
of API newer than the oldest target).
When it comes to
inserting
dependency version ranges, the min comes from versions found in
the oldest
supported target. The max comes from versions found in the
recommended
target plus an offset.
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Merks
Sent: Friday, September 23, 2011 9:20 AM
To: cross-project-issues-dev@xxxxxxxxxxx;
Eclipse Modelling Framework
Subject: Re: [cross-project-issues-dev] Strange dependency
of EMF Edit
UI
Kenn,
No, this definitely isn't a good thing. We must tolerate and
even
support 3.x so we must build and test against that. If we don't
do
that, we've basically made this decision for a large fraction
(majority)
of the release train which I don't feel is appropriate. The
platform
team has made it clear that 4.x must be compatible with 3.x so
anything
in EMF we discover (or downstream clients discover) doesn't work
with 4.x
will be something the e4 team needs to address. We need to
change
this as soon as possible...
Hopefully we'll be able to upgrade our builds so that the build
is done
and tested against 3.x and then retested against 4.x, but that's
a longer
term goal..
Regards,
Ed
On 23/09/2011 9:05 AM, Kenn Hussey wrote:
Michael,
The dependency versions for
EMF
are determined at build time based on the target it is built
against. Since
we built EMF 2.8 M2 against Eclipse 4.2 (given that the Juno
train is being
based on 4.x), the dependency versions are based on 4.2... We
could switch
back to building against 3.x but then we'd have less confidence
that things
work properly in 4.x...
Kenn
On Fri, Sep 23, 2011 at
10:16 AM,
Wenz, Michael <michael.wenz@xxxxxxx>
wrote:
Hi,
while switching the EMF
version
we use from 2.7 to 2.8 I noticed a strange dependency within
org.eclipse.emf.edit.ui:
the EMF 2.8 version has a plugin dependency to
org.eclipse.ui.workbench[3.102.0,4.0.0).
The real problem appears
when we
try to build against the Eclipse 3.8 milestones update site for
M2: there
is only org.eclipse.ui.workbench in version 3.8.0 available
which causes
an unresolved plugin error. The Eclipse 4.2 milestones update
site for
M2 contains two versions of org.eclipse.ui.workbench (versions
3.8.0 and
3.102.0).
Any thoughts? It appears at
least
strange to me. What is the purpose behind?
Michael
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing
list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|