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. 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. Without
that, we have two options: 1) maintain ranges manually and risk that they
are sometimes too wide 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.
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.
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).
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...
Ed Merks <ed.merks@xxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
09/23/2011 01:24 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Re: [cross-project-issues-dev] Strange
dependency of EMF Edit UI
That sounds totally ideal!
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
2. Oldest supported target.
3. Recommended target. Currently
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.
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
On 23/09/2011 9:05 AM, Kenn Hussey wrote:
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...
On Fri, Sep 23, 2011 at 10:16 AM,
Wenz, Michael <michael.wenz@xxxxxxx>
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
Any thoughts? It appears at least
strange to me. What is the purpose behind?