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
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...
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