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

There are two separate questions:

 

1. Whether automated dependency version range management is beneficial.

2. Whether Eclipse projects should strive to be generous in the range of allowed target platforms.

 

John, I see you arguing that #1 implies artificially excluding older platforms, but I have to disagree. I favor #2 as you can see from the range of supported targets for Sapphire. I also believe that it is in fact easier to be reliably generous with allowed target platforms if you use an automated dependency version range management system. The most common source of unintended breakage of support for older platforms is adding a dependency and accepting the default min version given by PDE. Since day-to-day development will utilize the most current platform to ensure best possible behavior in the next release train, the min version will be higher than it should be. Such problem simply doesn’t exist with an automated system.

- Konstantin

 

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Friday, September 23, 2011 12:41 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI

 

I understand that manual version range management is not practical for anyone. I also agree there are some potentially serious pitfalls to having a version range that is too wide. In fact the errors are much worse than "failing to install for no good reason". What happens in this case is that the install succeeds, but random runtime errors can happen as the bundle invokes a method that does not exist, references a class that isn't there, etc. I think there is a big difference between a commercial product and an open source component though. In a commercial application you absolutely want to nail down a precise range that has been carefully tested. You don't want your end users in a situation where they are running a configuration you haven't tested and cannot support. I know IBM products based on Eclipse do the exact same thing, and I completely agree with that. I also know there are commercial products that take configurations of open source components that we as producers never expected, tested, or built against. They do their own testing, and they are on the hook for supporting that if it goes wrong. In Eclipse we only test and support the configuration that we build in the release train, but we have no idea what configurations of components downstream products and distros might want. As individual open source components we lack the "complete picture" that products have, so we need to be wary of imposing extra constraints where they aren't strictly needed.

John


"Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

09/23/2011 02:51 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To

"'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>

cc

Subject

Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI

 




Not that I really wish to re-open this debate, but I want to make sure that people understand why projects and companies are moving towards automatic version range substitution.
 
The debate reduces down to arguing over what’s ideal vs. practical.
 
If I imagine an ideal developer with mental capacity and inclination to track what versions of what plugin has what change that they depend on and to always maintain version ranges accurately as changes to code are made, then clearly manual maintenance of every single version range produces best possible description of what a plugin is actually compatible with. In reality, I’ve never seen this happen with any degree of consistency. In common usage, the min version range is set based on what was in the target platform at the time the dependency was added and is never changed again. This is a very frequent source of bugs as dev target is frequently the latest platform. The max is ignored until the build breaks or an adopter/customer reports that they cannot install in certain configurations.
 
The reality of manual management of version dependency ranges is that “failed to install for no good reason” scenarios are far more likely than under automatic management. The system that we use for Sapphire was originally implemented for BEA/Oracle’s Eclipse-based product when we got fed-up with constantly having to fix bugs in version ranges. Since implementing the automated system, this category of bugs has disappeared entirely and what we ship precisely aligns with what we publicly say we support.
 
Of course, how you manage the oldest supported target is dependent on your project’s or product’s needs. For our commercial product, we are relatively conservative as we are on the hook for commercial support. For Sapphire, we’ve maintained Galileo GA as our oldest supported target. It is entirely possible for an Eclipse project to be very generous with what’s allowed as the min using an automated system. In fact it is easier to be sure of your generosity, if you are using an automated system.
 
In either an open source project or a commercial product, at some point there is a discussion and agreement on a policy for what a given release will support. Since introduction of the release train, these policies are typically described at the level of release train names. The difference between the automated system and the manual one is that with the automated system, you encode the policy in the build and your are done, while with the manual system you pray that combined actions of many developers don’t violate the policy.
 
Hope that helps set this matter in perspective.
 
- Konstantin
 
 
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent:
Friday, September 23, 2011 11:03 AM
To:
Cross project issues
Subject:
Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI

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


John

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>

 

To

cross-project-issues-dev@xxxxxxxxxxx

cc

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