Community
Participate
Working Groups
A few version strings for the Java facet (5.0 and 6.0) are contrary to Sun's actual brand and version use. They were set that way based on incorrect interpretation of the branding change when Sun dropped the first segment in high-level product references. The issue is that there is version 1.5/1.6 and "Java 5"/"Java 6" brands, but there is no such thing as version "5.0" or version "6.0". We need to fix this mistake. This will also make us consistent with JDT. In order to assure backwards compatibility with projects created with prior versions of WTP, an aliasing system will be created such that anyone attempting to resolve "5.0"/"6.0" version will resolve the renamed "1.5"/"1.6" version. This change should be completely invisible to users and largely invisible to downstream plugins. The only way that this change could impact downstream plugins is if they are comparing the version string of the IProjectFacetVersion object returned by getVersion call to the value that was passed in (a very unlikely scenario) or if they are reading the project metadata file directly (also rather unlikely and not supported). Note that compatibility is only in one direction. If the user creates a project in Helios and then opens it in Galileo or earlier, they will get errors in the problems view regarding an unrecognized facet version. If this ends up being problematic for any adopter, we can issue a patch for Galileo that does reverse aliasing.
A similar change will be necessary for the Standard JRE Runtime Component, except that in this case there is no project compatibility issues as runtime component versions are not persisted.
More information about the aliasing system can be found in this bugzilla entry: Aliasing system is needed for facet id and facet version https://bugs.eclipse.org/bugs/show_bug.cgi?id=298974
> The only way that this change could impact downstream plugins is if > they are comparing the version string of the IProjectFacetVersion object > returned by getVersion call to the value that was passed in > (a very unlikely scenario) I don't agree with the assessment that this is an unlikely scenario. Let's say I have two code paths depending on whether a project is Java 5 or 1.4. To figure out which path to take, I do need to query the version of the Java facet installed in the particular project and then compare it to a string. As in: IFacetedProject facetedProject = ProjectFacetsManager.create(project); IProjectFacet javaFacet = ProjectFacetsManager.getProjectFacet("jst.java"); IProjectFacetVersion javaFacetVersion = facetedProject.getInstalledVersion(javaFacet); String javaVersion = javaFacetVersion.getVersionString(); if(javaVersion.equals("5.0")) { ... The proposed change will break this existing code.
In response to Comment #3, you are generally discouraged from doing these sort of comparisons already. Rather than comparing strings, you should be comparing object instances. The recommended practice is to stash IProjectFacet and IProjectFacetVersion objects in statics and compare against those. All WTP facets have a class to hold these statics. The one for the java facet is called JavaFacet. If I take your example code, it should be written as follows: IFacetedProject facetedProject = ProjectFacetsManager.create(project); IProjectFacetVersion javaFacetVersion = facetedProject.getInstalledVersion(JavaFacet.FACET); if(javaFacetVersion == JavaFacet.JAVA_50) { ... There is no way for the aliasing system to be able to cover you, if you are doing string comparisons like that.
(In reply to comment #4) > if(javaFacetVersion == JavaFacet.JAVA_50) { ... Does this mean you'll be creating a JavaFacet.JAVA_15 == JavaFacet.JAVA_50?
> Does this mean you'll be creating a JavaFacet.JAVA_15 == JavaFacet.JAVA_50? Indeed. Here is a snippet of the new code. public static final String ID = "java"; public static final IProjectFacet FACET = ProjectFacetsManager.getProjectFacet( ID ); public static final IProjectFacetVersion VERSION_1_3 = FACET.getVersion( "1.3" ); public static final IProjectFacetVersion VERSION_1_4 = FACET.getVersion( "1.4" ); public static final IProjectFacetVersion VERSION_1_5 = FACET.getVersion( "1.5" ); public static final IProjectFacetVersion VERSION_1_6 = FACET.getVersion( "1.6" ); public static final IProjectFacetVersion VERSION_1_7 = FACET.getVersion( "1.7" ); @Deprecated public static final IProjectFacetVersion JAVA_13 = VERSION_1_3; @Deprecated public static final IProjectFacetVersion JAVA_14 = VERSION_1_4; @Deprecated public static final IProjectFacetVersion JAVA_50 = VERSION_1_5; @Deprecated public static final IProjectFacetVersion JAVA_60 = VERSION_1_6;
(In reply to comment #4) > In response to Comment #3, you are generally discouraged from doing these sort > of comparisons already. Rather than comparing strings, you should be comparing > object instances. The recommended practice is to stash IProjectFacet and > IProjectFacetVersion objects in statics and compare against those. All WTP > facets have a class to hold these statics. The one for the java facet is called > JavaFacet. If I take your example code, it should be written as follows: > > IFacetedProject facetedProject = ProjectFacetsManager.create(project); > IProjectFacetVersion javaFacetVersion = > facetedProject.getInstalledVersion(JavaFacet.FACET); > if(javaFacetVersion == JavaFacet.JAVA_50) { ... > > There is no way for the aliasing system to be able to cover you, if you are > doing string comparisons like that. Yury's question I believe is a good one, and although these static's exists, don't we have instances where we are checking for versions < > a specific version? I'm pretty sure we have some code doing this - so we need to be very cautious moving forward here. And we have similar issues as the java facet rename with backwards compatibility.
> Yury's question I believe is a good one, and although these static's exists, > don't we have instances where we are checking for versions < > a specific > version? Two part answer for this. The issue is not whether or not one uses statics, but rather whether one does string comparison or goes through the API. Here is another way that Yury's code snippet could be written to avoid string comparison that doesn't use statics: IFacetedProject facetedProject = ProjectFacetsManager.create(project); IProjectFacet javaFacet = ProjectFacetsManager.getProjectFacet("jst.java"); IProjectFacetVersion javaFacetVersion = facetedProject.getInstalledVersion(javaFacet); String javaVersion = javaFacetVersion.getVersionString(); if(javaFacetVersion == javaFacet.getVersion("5.0")) { ... Regarding ordering comparisons on versions, the framework supports version comparisons via IProjectFacetVersion implementing Comparable. That facility is immune from this change. I am not aware of any code outside of the framework that parses the facet version strings to perform it's own comparison. > I'm pretty sure we have some code doing this - so we need to be very cautious > moving forward here. And we have similar issues as the java facet rename with > backwards compatibility. Yes. We do need to move carefully and make sure that there is sufficient time for people to test changes and report an issues.
Created attachment 155464 [details] Combined Patch v1 The attached patch contains combined work on this item as well as a few other related changes to the Java facet that have been announced. Feel free to review and give it a try. What I'd like to do is release these changes after this week's integration build as that will give these changes broader exposure and will let us flush out any problems sooner. I have tried project creation use cases and WAR import wizard. The framework unit tests all pass for me locally. I'd like to run Java EE unit tests locally, but it's been years since I've been able to achieve that feat. Will likely have to wait for build results on that. Let me know if there are other scenarios you'd like me to try.
I think that was a good discussion at status meeting today, and I learned something new (as always :) It is the "version number" issue that's the "bug", and the "jst" issue in bug 298905 is just "tagging along". And, further, I learned that this is a case where the meta data is also displayed to the end user in the UI!, and that is the root bug, so to speak. That if we didn't do that, the versions "internally" could be what ever we wanted (nearly) and then we could "look up" what to display in the UI. Right? So, just to throw out a wild idea I'm sure has been considered and rejected ... what if the metadata was left alone, so there would be good project compatibility from release to release, and we just fixed it so the string displayed to the end-user was divorced from the literal string in the metadata? It could (should) be "looked up", right? So, the UI display would be correct in Helios, but just leave it wrong in Galileo ... well, guess it the "display fix" could maybe be back ported there, if considered that important. Thanks for the discussion,
This is marked as an "enhancement". Is that right? It is a bug, right? (granted, normal or minor, not blocking or anything, but a "bug in UI", I'd call it?)
+1 to David's idea of having a display label for a version similar to display label for the facet. If <project-facet-version> element had a label attribute/child, similar to <project-facet>, then jst.java/6.0 can be shown as "Java/1.6", w/o changing any project metadata. Not so?
Honestly, I am not really interested in going in the direction of creating a general facility for separate labels for versions. It's not a good way of handling evolution of the product. This would create a whole new set of confusing effects as versions do not naturally have this concept. Which API works on what? The potential of ill impact of this is much broader than the aliasing system, which is only in effect when you resolve the object. This would also leave cruft and old bugs permanently embedded in project metadata effectively forever, even for new projects. Not a good situation. I think we need to learn how to rationally evolve project metadata. Being permanently stuck with old design decisions and old bugs is not a good strategy. I have never seen any product or project adopt such a strategy.
(In reply to comment #13) > I think we need to learn how to rationally evolve project metadata. Being > permanently stuck with old design decisions and old bugs is not a good > strategy. I have never seen any product or project adopt such a strategy. To be explicit, I agree with rationally evolving project metadata, I think that's possible, and I think that's been done before in Eclipse, but it appears the proposal here would break coexistence of existing function, which I'd not call rational evolution. So, you don't like my humble proposal to separate 'data' from 'labels', but I hope you all find something that's more "additive" ... that doesn't require previous, existing users to patch their code. That's not evolution of meta-data.
> but it appears the proposal here would break coexistence of existing function, > which I'd not call rational evolution I think it's quite fair to say that evolution is rational if new version can read previous version's artifacts, doesn't alter those artifacts unless a user performs an action requiring those artifacts to be re-written and for the rare case of users needing to go in the reverse direction, a patch is offered that will make the previous release compatible. This strategy allows for the product and artifacts to evolve without creating undue burden on users. It is also a strategy utilized effectively by many products and companies in the industry. It is completely irrelevant whether the function in question is new or old. Frankly, this distinction is lost on users. I've never seen a user who is able to reliably tell which function of a product corresponds to which version. For this reasons, most shops standardize on one version of the tool and migrate at the same time. Insisting that artifacts created by a new version are always readable by the old version is quite unreasonable and frankly has never been true with WTP. You can just look at evoluation of dependency management metadata in JavaEE component if you need examples. To my knowledge, we have never even bothered to issue patches to make prior versions compatible. This seems to suggest to me that reverse compatibility requirement is quite artificial and selectively applied. I think I am being quite reasonable here in offering to create patches to Galileo and Ganymede to assure compatibility with Helios. It is more than what has been done by others in similar situations.
I'm surprised to hear we broke project compatibility. (well, after WTP 1.5 at least, I know we did before that). Perhaps the principle I think might be missing, in the stated definition of evolution, is that a version should always be able to read the meta data it itself wrote. I'm not expecting "compatibility with future unknown meta data" ... but, to break what one version wrote, I think would leave you open to "dueling versions" ... someone with Helios changes uses the wizard, changes the metadata, someone on Galileo uses the wizard, changes it back, etc. Does that convince you any? I hope you can see my point, that I'm communicating well. As for how customers upgrade, sounds like we've had some different experiences. One of the differences might be that I've seen many cases of "Product A" and "Product B" interoperate on the same projects, but not on same schedule, so Product A2 comes out, and suddenly no longer works with "Product B". Or, Product B makes it look like Product A2 doesn't work. (And, then multiple that types "A0, B1, and Product C" and you can see how its more complicated than just A0, A1, A2, A3, etc.) But, I can't stress enough, it is not up to _me_, I certainly don't have complete insight here, and I'm not trying to state one view that must be ... perhaps Chuck will come back with an answer of "no problem" or "here's a tweak". Sounds like WTP Arch. Group, (if not all of Eclipse Architecture Council) could work on a common, well understood definition of "evolution"? Good luck, and thanks again.
I still haven't heard why a patch to Ganymede and Galileo isn't an acceptable solution for the rare case that this would come up in. It is an approach that is widely used in the industry and covers more scenarios than what you are proposing in Comment #16 as it would also allow projects created in Helios to be usable in prior releases. > Perhaps the principle I think might be missing, in the stated definition of > evolution, is that a version should always be able to read the meta data it > itself wrote. That is an unworkable principle as that implies you can never add anything to a metadata file. In fact, in context of facets, it implies you can never add new facets in a new version as the old version will not recognize them. Don't have to go very far to look for an example. Let's say I create a Java 6 project in Galileo and my co-worker moves it to Java 7 in Helios. We are kinda stuck if the requirement is that the project must remain functional in older version. As I stated already, the user will be hard-pressed to differentiate new functionality from the old, so the argument that it's ok as long as users don't use new functionality just doesn't hold much water. Backwards compatibility is expected. Forward compatibility is not. Users do understand that and do not expect us to see into the future.
(In reply to comment #17) > I still haven't heard why a patch to Ganymede and Galileo isn't an acceptable > solution for the rare case that this would come up in. My concern is just the cost-benefit trade-off is very negative. Great cost, little gain. That may be because my intuition is that it would not be rare, but common enough to require service releases. Service releases are always expensive, in a number of ways. And, my concern, is that there are many cases where its not just "product A version N migrates to product A version N+1". But there's a multiplicative effect by other products meant to "work with" the same projects that product A works with. In cases I know of, users of the some of those products have no idea they are "changing a projects meta-data" because its all done programatically, based on a high level user choice. But, again, this is just my intuition at this point. I think Chuck's investigation and evaluation will be more exact. My concern is magnified by the many meetings/discussion I've heard where adopters (and users) complain so loudly that migrating from one version to another of WTP (or, Eclipse) is very costly, and more costly than the benefits would appear to justify. So, I don't mind arguing they should still upgrade when its a pretty clear case of "we had to impose this cost to fix this bad bug" or "... provide this new features" but this change to meta-data doesn't seem to justify the cost.
I'm sure obvious to others, but can you post a screen capture that shows how this appears incorrect to end users? In the place I think I'm supposed to see it, it already says "Java" ... "5.0". I was expecting "JRE 5.0" or something. Or, are you saying it should be just "5" (with no decimal)? Or, are there other places I'm not seeing what you are concerned about? Thank you in advance for the extended explanation.
> My concern is just the cost-benefit trade-off is very negative. Great cost, > little gain. That may be because my intuition is that it would not be rare, but > common enough to require service releases. Service releases are always > expensive, in a number of ways. And, my concern, is that there are many cases > where its not just "product A version N migrates to product A version N+1". But > there's a multiplicative effect by other products meant to "work with" the same > projects that product A works with. In cases I know of, users of the some of > those products have no idea they are "changing a projects meta-data" because > its all done programatically, based on a high level user choice. I obviously don't share your opinion regarding the cost-benefit analysis and that's where the problem is with this discussion. The costs and benefits are in the eye of the beholder. For instance, for me (as the guy responsible for maintenance and evolution of the code in question and an Oracle employee), this is a critical problem that needs to be addressed and concurrently the users that I am responsible to do not care about forward compatibility as we have never trained them to expect it in our products. See how easily that analysis flips around? My point is that if we are going to talk about policy, then it must be in abstract terms. A policy that involves subjective analysis will only lead to a log jams and fun threads like this. As we currently lack a defined policy, I think that the approach that I am taking here is quite reasonable. At the same time, it would not be a bad idea to start the process to formalize metadata compatibility rules so that we can avoid discussions like this in the future. The rules must balance the needs of developers working on the project with those of users. > But, again, this is just my intuition at this point. I think Chuck's > investigation and evaluation will be more exact. Honestly, I am quite confused by these statements. Chuck's team is trying out the patch to look into the technical aspects of this change as to verify that I did not miss anything during my testing. > My concern is magnified by the many meetings/discussion I've heard where > adopters (and users) complain so loudly that migrating from one version to > another of WTP (or, Eclipse) is very costly, and more costly than the benefits > would appear to justify. So, I don't mind arguing they should still upgrade > when its a pretty clear case of "we had to impose this cost to fix this bad > bug" or "... provide this new features" but this change to meta-data doesn't > seem to justify the cost. I am also confused by this statement. Do you really think that the solution of not enough value in a release is to put more constraints on developers working on the project? To make it more difficult to work on the project? I tend to agree that innovation in the core of WTP has stalled, but I suspect that we will not agree on the cause of that stall.
There certainly is a subjective aspect to trade-offs made in software development ... which is one reason I like Open Development, so they can be discussed, weighed, alternatives considered ... as we are doing ... instead of unilateral decisions made without discussion or views of others being considered. As for Chuck's evaluation, I thought it was going to include some assessment of degree (risk, impact) and not just "yes or no technically accurate". Guess he'll say soon if I misunderstood that. So, while we are having a such a good discussion, suffer me two more questions. I think they'll at least make for good discussion, if not action. First, is it possible to make a change in Helios, similar to the patch you are suggesting for Galileo, that would allow your desired change to be made in the 2011 release. To me, that would be a better approach to this type of change to metadata. (That is, a desired change, that has no functional difference). Second, is it possible for us (in WTP) to provide versioning in our metadata? That would seem to address the general problem of metadata evolution better. Seems it would allow more flexibility in the "response" to an older version finding metadata from a newer version. On one end, we could simply provide a better message to the user (e.g. "This project has been created or modified by a more recent version of Eclipse, and can not be properly read by this version"). On the other end, it would at least leave open to possibility of more refined handling (e.g. if version xyz found, then handle with xzy process). If you (and/or others) think worth pursuing, that'd be a separate bug/enhancement request but wanted to ask in this context. It be cool if something generally constructive could be done for the future. I was trying to think of similar situations, such as Java Serialization and their UIDs, where there can be compatibility, but not always. I know we can't guarantee mixed version support, and appreciate the care and thoughtfulness you've put into this.
(In reply to comment #17) > I still haven't heard why a patch to Ganymede and Galileo isn't an acceptable > solution for the rare case that this would come up in. Would this make projects modified by patched versions of Ganymede and Galileo incompatible with unpatched versions of those releases?
> There certainly is a subjective aspect to trade-offs made in software > development ... which is one reason I like Open Development, so they can be > discussed, weighed, alternatives considered ... as we are doing ... instead > of unilateral decisions made without discussion or views of others being > considered. Nice way to twist what I was trying say. I wasn't suggesting that open discussions are bad. I was making a statement that metadata evolution rules that are based on evaluation of trade-offs will not work. The rules cannot say "this is ok if it's worth it" as that's a highly subjective evaluation that is not going to lead to consensus as by its nature the people involved in an open source project will have very different goals and priorities. > First, is it possible to make a change in Helios, similar to the patch you > are suggesting for Galileo, that would allow your desired change to be made > in the 2011 release. To me, that would be a better approach to this type of > change to metadata. (That is, a desired change, that has no functional > difference). Well, of course, that's certainly possible. It does mean delaying fixing this major brand-misuse issue by a whole year and also means that it will be next to impossible to support Java 7 in Helios (version 1.7 is most definitely not greater than 6.0). Very expensive compromise that ultimately buys us very little. It also suggests that in the future we should make a habit of planning and executing many changes like this across two years. That's a real good way to continue delivering value to end users and adopters. > Second, is it possible for us (in WTP) to provide versioning in our metadata? There are several issues with versioning metadata... 1. Whose version? Certainly not the framework's as nothing is changing from framework's perspective. When you have extensions contributing content to a metadata file, versioning of said file is not meaningful. 2. A dialog prompt is also problematic because all of the processing is happening in non-UI code and we do not want to break core/ui separation. Even if we create some kind of a hack using reflection to call out to UI from core framework, that still has a problem as the core framework api is being invoked by various people's wizards/actions/unit-tests/etc. They are unlikely to react kindly to a random dialog popping up and breaking something or confusing users.
> > I still haven't heard why a patch to Ganymede and Galileo isn't an > > acceptable solution for the rare case that this would come up in. > > Would this make projects modified by patched versions of Ganymede and Galileo > incompatible with unpatched versions of those releases? Not at all. The Ganymede/Galileo patch would be made to work in reverse of the changes made in Helios. It will have no effect if the project wasn't created or modified in Helios. For a project created/modified in Helios, the patch will make them fully functional in Ganymede/Galileo. If it then modified in Ganymede/Galileo, the metadata that is written out will look like original Ganymede/Galileo metadata that can be read even by unpatched versions.
Well, I was thinking of a problem marker, instead of a popup dialog. I think that is a pretty standard pattern in Eclipse. And, yes, I was thinking of the metatdata having its own version, explicitly set, by developers, as needed. Independent of bundle. But, that is a side issue. Not sure how much work would be involved. Back to history, I did find this old reference to this mixed-version project compatibility requirement: http://wiki.eclipse.org/Web_Tools_Platform_2.0_Plan#Compatibility_with_Other_WTP_Releases It seems in more recent versions of our plans, we've left the compatibility section blank!? I was greatly relieved to find that reference, since that meant I wasn't going crazy and just imaging this concern :) I think some of us have this customer requirement "ingrained" as a given ... obviously not everyone does. And, I'm not saying its fixed and can't change; just wanted to prove I wasn't making this up on a whim. :)
That's interesting. Quite troubling as I do not recall any discussion or agreement to these requirements. ===== As a counter-point, here is what Eclipse platform says about project/workspace compatibility: http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#compatibility Workspace Compatibility: Eclipse SDK 3.6 will be upwards workspace-compatible with earlier 3.x versions of the Eclipse SDK unless noted. This means that workspaces and projects created with Eclipse SDK 3.5 .. 3.0 can be successfully opened by Eclipse SDK 3.6 and upgraded to a 3.6 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.6 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.6 plug-in developers are responsible for ensuring that their plug-ins recognize metadata from earlier versions and process it appropriately. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 3.6 will be unusable with a product based on an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.6 will generally be unusable with earlier versions of Eclipse. ===== Somewhat pointless for WTP to strive for tighter restrictions on developers if the base platform doesn't do it...
Per our agreement at last week's team call, I have waiting through Tuesday of this week for technical comments on this patch from Chuck's team. Having received no comments, I proceeded to release these changes to 3.2 M5 code stream and fproj. With the change more easily accessible to a broader community, we move to the next phase of testing. Regarding compatibility patches for prior releases... If any adopter (or any other community member) requires such a patch, please make a formal request by opening a bug (one per code line). You can assign it to me directly.
I am still not sure I understand why this is critical and why internal facet version numbers should be shown to the user (instead of using labels). > It does mean delaying fixing this > major brand-misuse issue by a whole year and also means that it will be next to > impossible to support Java 7 in Helios (version 1.7 is most definitely not > greater than 6.0). Why should 1.7 be "greater" than 6.0 from user's point of view? What if the next Java version is called "Java X", without numbers? What would you use for Java facet's version? "1.8" as a next logic step? "X" as the new official version name? If you go with "X", would it be "greater" than "1.7" in user's perception? > Honestly, I am not really interested in going in the direction of creating a > general facility for separate labels for versions. It's not a good way of > handling evolution of the product. This would create a whole new set of > confusing effects as versions do not naturally have this concept. But of course they do. Let's take Windows, for example. Let's assume I have a facet that indicates what Windows version my project supports. I certainly want my user to see the familiar Windows version labels, such as 95, 98, NT, 2000, XP, Vista, 2003 and 7. At the same time, Windows also has internal version numbers, returned by its API. For example, NT would be 4.1, XP -- 5.1, Vista -- 6.0, 7 -- 6.1. Those internal version numbers follow the same number.number.number pattern Eclipse uses, go in increasing progression and as such present a very logical choice for the facet's version. I hope this demonstrates the importance of having labels for versions.
(In reply to comment #22) > (In reply to comment #17) > > I still haven't heard why a patch to Ganymede and Galileo isn't an acceptable > > solution for the rare case that this would come up in. > > Would this make projects modified by patched versions of Ganymede and Galileo > incompatible with unpatched versions of those releases? Nitin, you are correct - and this is my specific sticking point.. We will need to require users upgrade to the latest maintenance version of Ganymede to achieve backward compatibility. Konstantine - I do understand eclipse doesn't have a policy for backward compatibility... But our product does, and in many cases we take great care to make sure existing metadata (Not new function) can exists between 2 versions. This is not always easy, and in some cases does require patches in both streams, including your example of runtime classpath dependency support, which I have on a few occasions patched for Ganymede. To report on my testing.... I haven't seen any issues with your patch, our junit buckets run clean, and now that you have dropped this into the stream, we will have to wait on adopter issues such as Yuri's. If we are moving forward with this, it is very important we have a patch for Ganymede (3.0.5P) to allow the compatibility api into our latest maintenance release very soon. Can you open a bugzilla for this work?
> Nitin, you are correct - and this is my specific sticking point.. > We will need to require users upgrade to the latest maintenance version > of Ganymede to achieve backward compatibility. I am fairly certain that you misunderstood the question that Nitin was asking. I addressed Nitin's question Comment #24 and that scenario is definitely not an issue. I think the scenario that you are concerned about is different. > To report on my testing.... I haven't seen any issues with your patch, our > junit buckets run clean, Excellent! That's very good news. > If we are moving forward with this, it is very important we have a patch for > Ganymede (3.0.5P) to allow the compatibility api into our latest maintenance > release very soon. Can you open a bugzilla for this work? I'd like the party that has these compatibility requirements to open patch requests (one for each code line that is necessary). That keeps the origin of requirements clear and frankly I don't think that I understand your product's use cases sufficiently to be able to write a justification statement. I will be happy to work on these patch requests once they are created.
In response to Yury in Comment #28... The faceted project framework has no problem dealing with the Windows version scenario that you've described without resorting to the version label approach that you've described. The framework doesn't make any assumptions about version format or ordering characteristics. It only supplies a default implementation of a version comparator, but a facet author can write their own to order their facet versions however is desired. The described version label facility is orthogonal to what is being discussed here. The fact that you could use such a facility to partly paper over this bug and avoid some migration impact, does not make this a good approach. There is no requirement for this labeling facility in general use and aliasing system does a much better job of dealing with migration.
(In reply to comment #31) > The described version label facility is orthogonal to what is being discussed > here. Agreed. However, requiring a facet provider to write a version comparator if they have unusual version sequencing while we commonly separate IDs and version numbers from user-facing labels everywhere else in Eclipse strikes me as...odd. I can see the advantage of how it's currently approached, though.
(In reply to comment #31) > The described version label facility is orthogonal to what is being discussed > here. Disagree. But maybe because I am yet to see the explanation of why this is a bug, let alone critical. I see David Williams asked a few times for an explanation. I asked. But no answers? The way I see it, the bug could be that the end user sees version "6.0" where she is expected to see "6" or "1.6". This is purely a UI issue and should be addressed as such (see comments 11 and 12). Internal facet IDs and versions are of no interest to anybody but the facet owner and I don't see any legitimate reason to change IDs and versions of existing facets. Providing UI labels is a much cleaner solution, avoids all migration/compatibility issues and adds missing functionality.
(In reply to comment #31) > The framework doesn't make any assumptions about version > format or ordering characteristics. It only supplies a default implementation > of a version comparator, but a facet author can write their own to order their > facet versions however is desired. This is true. But earlier you said > It does mean delaying fixing this > major brand-misuse issue by a whole year and also means that it will be next to > impossible to support Java 7 in Helios (version 1.7 is most definitely not > greater than 6.0). These statements contradict each other. Why would it be impossible to support Java 7 in Helios? Why does it matter that "1.7" is not greater than "6.0"? As soon as you provide a proper comparator, "1.7" will be greater than "6.0". What's the problem?
> Disagree. But maybe because I am yet to see the explanation of why this is a > bug, let alone critical. I see David Williams asked a few times for an > explanation. I asked. But no answers? I've stated multiple times in this bug why this is serious issue. I also stated a pretty obvious observation that criticality is in eye of the beholder. You are of the opinion that this is a minor problem and we should paper over this via this label facility that we don't need otherwise. I disagree. Let's leave it that. > These statements contradict each other. > > Why would it be impossible to support Java 7 in Helios? Why does it matter > that "1.7" is not greater than "6.0"? As soon as you provide a proper > comparator, "1.7" will be greater than "6.0". What's the problem? They don't contradict. While the framework could cope with this situation, the user would still see "1.4, 5.0, 6.0, 1.7" version sequence and be confused. Unlike your Windows example, the users would not be naturally prepared for this as such referencing of Java version numbers is purely a bug. We are not talking about technical vs marketing versions here. Further, java is one of the core facets that is used extensively throughout many places in WTP. Some of those places may not be going through facet API for version comparisons and would be broken by this sequence. The risk of API-level problems would make it very difficult to support Java 7. Hence the statement that you are referring to.
(In reply to comment #35) > You > are of the opinion that this is a minor problem and we should paper over this > via this label facility that we don't need otherwise. You are of the opinion that we should paper over this via alias facility that we don't need otherwise. I am of the opinion that label facility not only solves this issue at hand but also has additional benefits beyond the problem being discussed in this bug. I am also of the opinion that IDs and version number of existing facets should not change. There is no benefit in those changes, only harm. > I disagree. Let's leave it that. Now that's not a productive way to discuss issues, is it. > Further, java is one of the core > facets that is used extensively throughout many places in WTP. Some of those > places may not be going through facet API for version comparisons and would be > broken by this sequence. With the proposed changes you do just that -- you break adopters who may not be going through facet API for version comparison! See comment #3. If there are places in WTP that do not go through facet API for version comparison, open bugs for them and fix the way they do version comparison. Do not "paper over this with a facility we don't need otherwise".
It's quite a long discussion already, but I'd like to share my opinion, too. I am quite anxious about the compatibility with older Eclipse releases. Imagine the common case where several developers work on common set of Java EE (WTP-based) projects, hosted in some SCM. If one of them upgrades his IDE to Helios, then this might cause problems to all developers who are still on Galileo or older IDEs. This could turn in a real supportability hell for some adopters. Providing compatibility as patches to older releases is possible solution, but it incurs additional costs to adopters and their customers - for testing and integration. For big adopters, this might be a really big cost overhead. And, Konstantin, do you really mean to patch each official older release? I mean not only the latest maintenance release of a release train, but *all* maintenance releases. You should not expect that all adopters always adopt the latest maintenance release. SAP is such an example. The only benefit I saw in the comments is just to comply to the Sun's freak versioning rules. I don't understand Sun's versioning system. I spent many hour in the past years to find the rational behind it... It's a non-sense. And it's Sun moral responsibility for the many hundred thousands of hours lost in the Java community in pointless discussions about "JDK 5.0" vs "JDK 1.5". If complying with Sun's versioning rules is so vital, I vote for the solution to change the UI representation of the version numbers. But let's not touch the internal IDs. I see no problem to display "Java 1.7" and have it as "jst.java:7.0" internally. Regarding software evolution mentioned several times. This change is as disruptive as exterminating the dinosaurs far ago in the history of our Nature. Yes, Life is still on Earth and Evolution is still on track, but who tells that dinosaurs were bad... My conclusion: this is a very high risk and expensive change, with no real benefit. No offense! I understand (and support) the desire of the Facets Framework project to evolve and be as clear as possible, but the risk of this change will be payed completely by the WTP project and its adopters. This is not fair! Being still on biological wave. Evolution is still possible by carrying few atavisms :-)
Guys, We are going in circles here. This discussion goes beyond this particular issue. The real question is can we get to the point where we can rationally evolve our metadata without each case blowing up into an extended "well, I think it's worth", "well, I don't think it's worth it", "well, I think you can hack around it this way", "well, I ...". Opinions are great, but at the end of the day the guy doing the work must pick an implementation strategy. I considered the option of papering over this problem with labels and do no think that it is the right approach. I am not going to repeat the whys as I have already stated them. I think platform's policy for metadata evolution that I quoted in Comment #26 is quite rational as it addresses the most important aspect of compatibility without putting very costly restrictions on developers that hamper progress. I have offered on this thread to go beyond what the platform team would do in a similar situation. My offer is a patch to Ganymede and Galileo lines if an adopter opens a request for such a patch. If an adopter needs a patch on even older releases, it should be possible for the adopter to take the Ganymede patch and back-port it further. I will assist by answering questions, but I will not do that work as I find it extremely hard to believe that Europa-Helios back-n-forth compatibility works right now regardless of this change.
Konstantin, I think that the root problem in this discussion is that it is not clear what the *issue* really is. At least it is not clear to me. What is the problem of the current "Java 5.0/6.0/7.0/X.0"? Every man on Earth who understands the term "Java" also understands which version we label. So, it is not an usability issue. If the issue is that we don't comply to some Sun rule, then how big is this issue and why? As I mentioned, I don't care about Sun's problem with versioning. They can decide to invent some new versioning tomorrow and I don't want to be affected in the same crazy way. What do we risk by not fixing our versions? You mentioned this is a very serious issue. Why? Is Sun going to sue the Eclipse Foundation or WTP adopters? It must be clear what the real issue is. Why it is not enough to fix only the UI representation? Why do we need to mess our internal ids? Again: what is the risk? I agree that metadata evolution is important, but this is the thing, which goes out of topic. Metadata evolution is another issue and another topic. Of course, if we had good solution for metadata evolution, then implementing the current change won't be an issue. But we don't have any acceptable solution for now. My understanding for the purpose of the Eclipse projects is to make their users and adopters happy, not just to blindly evolve a technology. Here we have a change that has a very high risk to some adopters and their users. Providing patches is just not enough, because this brings additional costs and does not guarantee that these patches will run smoothly immediately on already shipped software. This change needs to be justified - what is the benefit for these adopters? I see no benefit. So, to have this discussion productive we need to have two answers: 1) what is the real risk of not fixing these version numbers? 2) what is the benefit of fixing these version numbers?
I will not engage in this justification discussion. It is pointless as I already have stated and we have wasted enough time on this that could have been put to more productive use. We do not have a policy for metadata evolution. Absent an agreed-upon policy, we have historically fallen back on "what does the platform do". This change is fully compliant with that policy. Given that the change is compliant, there is absolutely no point in engaging in justification debates. One person's pointless change is another person's critical change. This is amplified in an open source environment where we have different companies with different needs and priorities. I understand that this might be viewed as pointless by IBM and SAP, but perhaps this is a touch more important to Oracle.
Konstantin, I am very disappointed by this answer... I don't understand why you avoid answering direct questions regarding the change. What does Oracle hides? Why this is changes is so important? This change is not just pointless for me (otherwise, I would be just neutral as with many other changes happening around). It is harmful and disruptive. The spirit of open source is that all players are gaining benefits from participating and one should not disregard the others. This change has a very high risk to brake adopters. It must be discussed and agreement must be done.
Why would you think that I am hiding something? I have stated everything there is to be stated in plain language repeatedly. We've been going in circles ever since. I understand that some do not think this is "justified". That's fine, but that is only relevant if I was requesting an exemption from the rules. I am not. Everything about this change is within the bounds of acceptable activities for a major release. To make this whole situation stink even more, IBM committers have been able to push out similar changes in prior releases without all this fuss. Debate and discussion and openness are all great things, but it is absolutely not appropriate for some participants to utilize blocking tactics to stall progress on the project because it might have an impact on a scenario that the platform team itself is saying is unsupported!
After thinking about this more, I need to object to this change, and agree with comment #37, as the potential business impact of requiring patches for our many adopter maintenance releases, and products is too large. Regardless of the reason's of this change, I do understand metadata does require modification, and has to evolve eventually, but when we plan for evolving, we should always try minimize any backward compatibility breakage. WTP's policy is out of date, and needs updating: http://wiki.eclipse.org/Web_Tools_Platform_2.0_Plan#Compatibility_with_Other_WTP_Releases And the platform has a few words on this as well: http://www.eclipse.org/eclipse/development/readme_eclipse_3.5.1.html#Interoperability%20with%20Previous%20Releases Until we can come up with a solution for evolving without patching previous releases, I vote for reverting these changes.
Chuck, WTP doesn't have a policy on metadata evolution. The quoted 2.0 document is not relevant in the context of 3.2 and I will even go as far as to challenge the validity of those statements in the 2.0 document as I do not recall any project-wide discussion, voting or agreement to a policy with such disruptive implications. Nor has that policy been followed, as I already stated. I scanned through the new link from the platform that you've added and it seems to me guidance to users about impacts to watch out for. I does not seem to be in conflict with their policy statement quoted earlier. In fact, it is good example that shows that not only the platform exercises their policy in practice by putting in changes that are not round-trip compatible with prior releases, but also that it would be foolish for WTP to try to enforce anything stricter as the base that we sit on doesn't make any such guarantees. We, as a project, must have ability to evolve metadata. Having a round-trip compatibility requirement does not allow for any metadata evolution and as such is not only not practical, but is deeply harmful to the project. This discussion is reminiscent of the discussions around the "adopter API usage scans" policy. I consider that policy one of the worst mistakes made by this project. Both the adopter usage scans and the call for round-trip compatibility for metadata on the surface seem like a great service to the community, but by failing to balance the need of community for stability against the need of the project to be able to move forward in a reasonable manner, they are both deeply flawed. The harm may not be felt immediately, but in the long-term the entire ecosystem of the project is harmed. Does anyone really think that adopters who the usage scans policy was trying to protect have ultimately benefited from having to live with critical API's in a permanent unfinished state? Short term benefit. Long term harm. Over the years, I've discussed the unique relationship that this project has with the adopter community with committers and leads of a number of prominent projects at Eclipse. The universal reaction is that of a shock. One of the leads went as far to say that WTP lacks a backbone. I can't say that I disagree with that sentiment. We cannot just be looking out for needs of adopters. We need to lookout for the needs of the project too. The terms got a little mixed up in the discussion. The changes here are fully backwards compatible with prior releases. Further, no metadata changes are made unless the user performs an action on facets in Helios. If the user pops into Helios to explore a bit and goes back to Galileo or Ganymede, no changes have been made. I view this careful approach as striking a good trade-off between minimizing the impact on users and having a reasonable ability to move forward. In fact, it goes beyond what's required by platform's compatibility statement. I suggest that we move forward. There is still time to add compatibility provisions to Galileo SR2, but if we spend more time debating this, then patching will be necessary even for Galileo.
(In reply to comment #44) Konstantine > > WTP doesn't have a policy on metadata evolution. The quoted 2.0 document is > > not relevant in the context of 3.2 I agree the policy wasn't properly specified for Helios > Nor has that policy been followed, as I already stated. I actually disagree with this, Our adopter products have had this backward compatibility requirements for many years, and since WTP 1.0, my team has been very careful in maintaining the existing metadata format. New features were always additive and thus ignored if shared with previous versions. > > I scanned through the new link from the platform that you've added and it seems > to me guidance to users about impacts to watch out for. I does not seem to be > in conflict with their policy statement quoted earlier. In fact, it is good > example that shows that not only the platform exercises their policy in > practice by putting in changes that are not round-trip compatible with prior > releases, but also that it would be foolish for WTP to try to enforce anything > stricter as the base that we sit on doesn't make any such guarantees. > The reason I added this link, and I should have been clear, was to show the amazing effort the platform has also made to maintain the existing format of legacy metadata. The one example given in all the platform metadata was the addition of nested resource linking (a new feature) that is ignore in previous releases. I don't consider that change even close to what is being proposed here, because it isn't changing the format of "existing" legacy metadata. Your change would be the equivalent of changing the resource link format so it would be completely broken in previous releases. Their example goes on to recommend best practices when sharing projects between versions, and to avoid creating links with the new feature. > We, as a project, must have ability to evolve metadata. Having a round-trip > compatibility requirement does not allow for any metadata evolution and as such > is not only not practical, but is deeply harmful to the project. > I completely agree, but we need to have a path that allows evolution AND compatibility. This is not unprecedented - a good example is the plugin/bundle evolution/compatibility layer in the platform, that allowed this type of transition We can still use your aliasing system, with the choice of compatibility to evolve replacing metadata. > The terms got a little mixed up in the discussion. The changes here are fully > backwards compatible with prior releases. Further, no metadata changes are made > unless the user performs an action on facets in Helios. If the user pops into > Helios to explore a bit and goes back to Galileo or Ganymede, no changes have > been made. I view this careful approach as striking a good trade-off between > minimizing the impact on users and having a reasonable ability to move forward. > In fact, it goes beyond what's required by platform's compatibility statement. New projects following equivalent scenarios will be unusable without patches in previous releases, and simply changing the runtime of a project has the same effect. I continue to object to this change, and would like this to be reverted until we agree on an evolution that doesn't break project co-existence scenarios without patches in older releases.
I'd like to see if we can come up with a reasonable compromise that allows us to move forward. I still view the round-trip compatibility requirements as deeply harmful, but I hate seeing all these negative reactions too. What if the code was altered such that old facet ids and versions are preserved in metadata if they were present before? This would basically allow someone to take a project created in say Ganymede, open it in Helios, manipulate facets and still have it working in Ganymede. They could, of course, break that compatibility by installing a facet that doesn't exist in Ganymede or switching to Java 7, which is not supported by Ganymede. New projects would carry new facet ids and versions.
> What if the code was altered such that old facet ids and versions are > preserved > in metadata if they were present before? This sounds like a reasonable compromise, conceptually. It allows projects that were working in version N-1 to continue working (without patches) even if someone with version N touches it. And that's the main goal, or use case, to support here. This allows large software shops to upgrade, but not require they all upgrade at the same time, with minimal disruption to their workflow of existing projects. With this compromise solution, projects created brand new with version N would not work with version N-1, but I think that is a fairly typical way that Eclipse Projects handle evolution, and would not interfere with users "investment" in all their existing projects. Since this week's I-build is the final I-build before we begin our Milestone build rampdown week, and since this issue is controversial and deserves adequate time for review, I do think the best way forward is to revert back to the way things were so the Milestone is stable and predictable, and then re-introduce your proposed change right after M5, and then to again request review and comments on the specific implementation, in plenty of time for M6. Thank you.
Created attachment 156671 [details] Patch with alias preservation additions This patch adds logic per compromise proposed in Comment #46 that will preserve existing facet id and version aliases in the facets metadata file even if metadata around them is updated and the file is saved in Helios.
Forgot to add in the previous comment that the new patch is additive to the first patch and the fix for the JUnit failure that was dropped last week. I don't have a patch preserved for the JUnit fix. It looks like the compromise is acceptable. I see David's +1 and I saw Kaloyan's +1 on the PMC mailing list. In the interest of moving forward and to give the maximum possible time for concerned adopters and random other parties to report any issues, I have released the new patch into 3.2 M5 stream.
