Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI

Implementation in Sapphire’s CVS repo for anyone interested. The build system is Ant-based around old-school PDE build.

 

http://www.eclipse.org/sapphire/developers/CVS.php

 

- 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 10:25 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI

 

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

Back to the top