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


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


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 “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
Friday, September 23, 2011 9:20 AM
cross-project-issues-dev@xxxxxxxxxxx; Eclipse Modelling Framework
Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI


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


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> wrote:
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?

cross-project-issues-dev mailing list


cross-project-issues-dev mailing list

cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top