[releng] Rename all features in MDT OCL 3.0.0 #458
Comments
|
By Ed Willink on Oct 30, 2009 15:26 The three edit plugins are now available. |
|
By Alexander Igdalov on Nov 04, 2009 05:50 P2 installer doesn't only fail on features with clashing names but it also doesn't work with plugins that have clashing names. Thus, plugins have to be renamed as well. |
|
By Ed Willink on Nov 04, 2009 06:23 I do not not want to change plugin names for 3.0.0. I'm not keen on changing plugin names for 1.4.0; almost a contradiction. If we have different names it will be really easy for users to get in to trouble mixing and matching two different OCLs at once, and much harder for them to upgrade. I do not want to spend a year explaining installation problems on the newsgroup. There must be a way of ensuring that p2 cannot see both sets of names (at once). |
|
By Alexander Igdalov on Nov 04, 2009 06:39 In reply to comment #3)
Me too. But we have to make 3.0.0 and 1.4.0 somehow co-exist in Helios.
Yes, that's why the least bad option is doing it for 3.0.0.
Well, I don't think there will be painful complications if we just convert org.eclipse.ocl_XYZ.jar into org.eclipse.ocl3_XYZ.jar having all the package structure and classes unchanged.
I don't understand it. |
|
By Ed Willink on Nov 04, 2009 07:12 For people doing it right, using oclSomething rather than ocl is just a big nuisance. Every single import must be changed. [Whether 'Something' is '3' or '2_1' or '2_3' or ... is a different difficult and hopefully unnecessary discussion.] The problem is when people do it wrong, and that has been me all too often. When strange things happen on plugin loader class-paths, it can make for a very very bad day. My concern is that part of some users plugin will get the 'ocl' while another will get the 'oclSomething' and it will all build fine but give a magic undebuggable class version error when the code tries to run. If we cannot make 1.4.0 and 3.0.0 coexist, then we have to consider which of 1.4.0 or 3.0.0 to abandon. |
|
By Alexander Igdalov on Nov 04, 2009 08:01 (In reply to comment #5)
Ed, Changing the plugin name and version rather than the version only must produce less errors. I remember class version errors when there were different versions of the same plugin installed - but when the names do not clash, there is less chance for this.
From a user's viewpoint, class imports do not have to be changed. Just the manifest/feature.xml information on required bundles. But this info would be changed anyway - to update the version range. Now this would require to change the names as well.
I hope we can. It turned out to be hard but this is possible. |
|
By Alexander Igdalov on Nov 04, 2009 08:36 I am now committing changes related to this bugzilla into the repository since there is no other way to marry them with the build procedure. In case we decide to roll them back - I will do it. |
|
By Ed Willink on Nov 04, 2009 08:50 Alex: Your proposed change affects the fundamental project structure. At the time you decided to commit, you had one committer unhappy, and no comment from others. This topic needs agreement from at least a majority, and a reasonable opportunity for all to comment. This is our project, not just yours. You must consult. If you need to do experimental things with CVS, please use a branch. The following reply hit a mid-air collision +1. You're right; imports don't change. With multiple candidates for the same "ocl3" seems right. It's clearly our number. 2.1 or 2.3 are unstable targets. But suppose OCL 3.0 introduced generics (e.g Unsigned<24>), then we would I think I prefer "ocl2". To support the feature reorganisation, we may need to partition o.e.ocl into However as above, the team must be given an opportunity to comment. My +1 to the principle of a name change is not adequate. The spelling of the name change requires further discussion. |
|
By Alexander Igdalov on Nov 04, 2009 09:23 (In reply to comment #8)
I agree. As I have mentioned I will roll back my changes if we decide to change names in a different way or do something else. It is also true that experiments should be done in branches. But setting up the releng for another branch is a new headache.
Well, we can call it "ocl2". I don't care much about it.
Did I get it right that you agree that we have to change the names somehow? But you disagree that it should be changed to "ocl3"? |
|
By Ed Willink on Nov 04, 2009 09:47 Yes, I agree that we need to change the plug-in names. I prefer "ocl2" to "ocl3" but recognise the problems you mention. I would like to hear from at least one of Adolfo or Laurent before proceeding with changes in HEAD. |
|
By Alexander Igdalov on Nov 04, 2009 10:04 (In reply to comment #10)
Great.
As I have said I don't care much about it. But just to add pros to "ocl3": According to your naming principle, we will have: org.eclipse.ocl2_3.x.y_jar for MDT OCL 3.0.0 (OMG OCL 2.1) Alternatively, we can choose the naming convention below: org.eclipse.ocl3_3.x.y_jar for MDT OCL 3.0.0 (OMG OCL 2.1) The latter seems to be less confusing to me. What do you think? |
|
By Laurent Goubet on Nov 04, 2009 10:19 Hi Ed, Alex, Slowly getting back on touch with the bugs... This seems like the most critical one. I also agree with the fact we need to change names. As for the naming scheme, I'd also rather we use "2" as the base number instead of 3; to both align with the base version number of our current OCL target and avoir confusing people. If we make ocl3 ... then we'll have to justify why we never had an ocl2 :). |
|
By Alexander Igdalov on Nov 04, 2009 10:56 (In reply to comment #12)
Hi Laurent, The idea of having something from the lang spec version in our plugin names seems nice. However, what if we have OMG OCL 2.2 as the next spec following 2.1? If it is incompaticle with 2.1 (in the same fashion as 2.1 is incompatible with 2.0) then we will have to release MDT OCL 4.0.0 as an implementation of OCL 2.2. What will be the base number in 4.0.0 then? Cheers,
|
|
By Ed Willink on Nov 04, 2009 10:59 Another mid-air collision!. is perhaps more confusing, or perhaps less because it stresses the org.eclipse.ocl3_3.x.y_jar for MDT OCL 3.x.y (OMG OCL 2.z) is just redundant. The 2 in ocl2 matching OCL 2.z is good now, but could be bad if Laurent's not skipping a number argument has merit. We seem to have a number of weak arguments, perhaps more for ocl2 than ocl3. |
|
By Alexander Igdalov on Nov 04, 2009 11:34 (In reply to comment #8)
It seems I didn't carefully read this. The moment I started renaming plugins was between comment #2 and comment #3. Thus, I was not committing my changes in spite of your opinion but at that time I didn't know you would write comment #3. Once again sorry,
|
|
By Alexander Igdalov on Nov 04, 2009 15:30 Hi all, We've got results! I have eventually created an MDT OCL 3.0.0 build that can be successfully installed into the same target platform with 1.4.0. However, I found that the build was unstable (e.g. some tests failed) due to plugin renaming. The reason is that the plugin sources have some indirect dependencies on bundle names. As an example, there is an extension point called "org.eclipse.ocl.environments" which is responsible for creating instances of EnvironmentFactory. The extension point must be renamed so that environment factories from 1.4 do not interfere with those in 3.0. Since the changes turned out to be more complex than initially expected I rolled them back. Together with the releng we will have to modify not only the manifest.mf and feature.xml files but also some of the *.java and plugin.xml ones. Next week I will come up with a new patch fixing the indirect dependencies. Regarding the plugin naming, I don't mind any of "ocl2" and "ocl2a" to be used as a pattern. As I see it, Ed and Laurent's preference is "ocl2". In case there won't be other ideas I will switch to it in the next patch. |
|
By Alexander Igdalov on Nov 04, 2009 15:51 Created This patch uses "ocl2" naming. It must be accompanied with another patch fixing indirect name clashing between 2.0 and 1.4 versions. |
|
By Ed Willink on Nov 04, 2009 17:13 My thinking evolved as I wrote. My preference is ocl2a then ocl2 then ocl3. The change in extension point id is nasty. It requires users to recode in ways that are poorly supported by refactoring/diagnostics. Fortunately there is only one extension point. Does anyone use it? It's use may be subject to revision if/when child environments are migrated from QVTd. To avoid this happening again can we introduce an o.e.ocl.extensions plugin that declares just extension points and schemas, so that the same plugin is used by all OCL variants? |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 05, 2009 13:31 Hi Team, Jsut a point of view about the discussion: I think that we shouldn't worry about the confusion which may produce the number after ocl. The name of the feature will solve any confusion about which OMG specification will be targeting an specific OCL feature. I think that the natural increment in the feature ID would be ocl2, whose version would be 3.0.0.qualifier and whose name would be Object Constraint Language 2.1 or something like that. A possilbe org.eclipse.ocl3 feature's id, could have a 4.0.0.qualifier version and could have the Object Constraint Language 2.2 name. BTW, if we stepped on OCL 3.0.0 feature's version why now it's unclear stepping on org.eclipse.ocl3 feature's id. In any case, as occured with my opinion about project's version, I think that the natural increment should be org.eclipse.ocl2 P.S: I don't have any problem about org.eclipse.ocl2a neither, just an extra/unnecessary vowel, though. It's not relevant or cofusing to me if the feature's names clearly states the OMG specification which it's implementing. Cheers, |
|
By Nicolas Rouquette on Nov 05, 2009 20:31 Having parity between the version info of the spec and the name of the feature is a good idea. Instead of limiting this parity to the major version, I suggest including both major and minor version numbers. org.eclipse.ocl20 => OMG OCL 2.0 |
|
By Ed Willink on Nov 06, 2009 01:51 Nicolas: I would agree completely if OCL 2.0, or 2.1 or 2.2 was implementable. Sadly there is the odd contradiction and ambiguity to worry about. We already implement some of the issues being ballotted for OCL 2.3. I think that OMG numbering policy requires that 2.1 and 2.2 are revisions of 2.0, so that OCL 2.1 could be defined as OCL 2.1 == OCL 2.0 + {resolved Issues}. This was my thinking behind 2a (and 2b etc). We could define ocl2a == OCL 2.0 + {resolved Issues} + {submitted Issues} + {known deviations} pending submission of a deviation as an Issue resolution, and approval of the rtesolution of a submitted Issue. Thus "closure" is currently a known deviation, which should soon have a submitted resolution. I would like the MDT/OCL documentation to precisely identify our OCL 2.0 + {resolved Issues} + {submitted Issues} + {known deviations} and since it will not exactly match any OMG number I want a comparable but distinct number or name for it. Our present change from ocl to perhaps ocl2, perhaps ocl2a, is forced by P2 tooling. If we adopt ocl2a, a change to ocl2b could occur either through another P2 problem or a significant incompatible change in the {resolved Issues}. I would not expect to change to ocl2b,... for each new issue, and certainly not when an unknown deviation is brought to our attention. I would expect to change to ocl3a to align with OCL 3.0 and not before. |
|
By Nicolas Rouquette on Nov 08, 2009 13:50 Instead of: ocl2a == OCL 2.0 + {resolved Issues} + {submitted Issues} + {known deviations} how about: ocl20a == OCL 2.0 + {resolved Issues} + {submitted Issues} + {known deviations} That is, I'd rather avoid as much as possible confusion about numerology between OMG's OCL versions and Eclipse's implementation of a particular version of OMG's OCL. |
|
By Ed Willink on Nov 09, 2009 13:54 ocl20a is good for me. |
|
By Alexander Igdalov on Nov 25, 2009 17:31 Created attachment 153132 This patch should to be applied to the root project for MDT OCL, i.e. It converts all bundle names to *.ocl20a. (In reply to comment #18)
Yes, this is what I disliked too. That's why I supported the old extension point name in 3.0. See plugin.xml of the o.e.ocl plugin. Since both MDT OCL implementations contribute to the same extension point I check the type of the contributed class. It is selected for further use only if it is an instance of EnvironmentFactory interface. The same must be also done in 1.4 branch (where EnvironmentFactory interface will have a different class loader). Thus, each implementation will choose the appropriate environment factories.
I would +1 it, but extracting a common part would be a new headache for the releng. I would be very happy with the described workaround instead. :notepad_spiral: patch_20a |
|
By Ed Willink on Nov 26, 2009 02:01 Practicalities: (In reply to comment #24) I am very uncomfortable about plugin and extension point name changes, which seem to forced by support for 1.4.0 (which I don't want and) which we seem to refuse to maintain; no correction of the warnings. This has only been discussed by this Bugzilla at the moment. I think we need to put a short clear posting of the problem, the consequences of the possible solutions and our preferred to solution on the main modeling list and newsgroups, so that the community is aware of the impact. I would particularly like to know whether Kenn Hussey and Ed Merks think this is a sensible direction or perhaps have better suggestions for us. Perhaps the problem should actually be fixed in p2. If we go with this approach, it will break all patches awaiting review so they need to be cleared first. If community input fails to identify an alternative, and if a community is identified that requires 1.4.0, I suggest that we plan to apply this patch immediately after M4. |
|
By Ed Willink on Nov 26, 2009 02:09 Details: (In reply to comment #24) Reviewing the patch (without applying it - I assume it works)
change in plugin.xml can work. All extension points are prefixed by the plugin name so that instead of org.eclipse.ocl.environments we get org.eclipse.ocl.org.eclipse.ocl.environments It could be good to do any significant feature reorganisation at the same time. |
|
By Alexander Igdalov on Nov 26, 2009 06:22 (In reply to comment #25)
Ed, you seem to have misundertood my previous comment. I paid special effort to keep the extension point id unchanged. (In reply to comment #26)
Nope ;-) See bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=112856 for details. Please keep special attention to https://bugs.eclipse.org/bugs/show_bug.cgi?id=112856#c37 . I agree that it is strange that the ability to contribute an extension point to other namespaces than the bundle id is not very well-known.
I have defined a system property "org.eclipse.ocl.ecore.tests" in the launch. Is that wrong? I cannot run the launch without it from my workspace.
We still have o.e.emf.ocl bundles left. These are the test feature and the examples. They aren't related to MDT OCL 1.1. I am not quite sure whether these must be changed. In any case, this can be done in a separate patch. |
|
By Ed Willink on Nov 26, 2009 14:55 (In reply to comment #27)
Ah! Clever stuff. That nicely avoids one incompatibility.
It's not very wrong. It's just that the property was not previously needed. I suspect there is a bit of 'clever' code that synthesizes the resolution from a bundle name and that the patch breaks this code. I'll try to fix the 'clever' code before we patch.
Yes. The interpreter is 'emf.ocl' but everything else including the tests are gone. I would like to post the following to eclipse.org-committers@eclipse.org to see whether we have overlooked a simple solution. Alex perhaps you can improve the description of the p2 limitation and then post it. The MDT/OCL is making an API breaking change and so is taking a major increment from 1.3.0 to 3.0.0 for Helios. [The 2.0.0 is skipped since 1.3.0 already contained a 2.0.0 plugin.] In order to preserve API compatibility for existing customers the 1.3.0 functionality for Galileo will be preserved in 1.4.0 for Helios. We have failed to make both 1.4.0 and 3.0.0 releases coexist on an update site when both releases offer the same plugin and feature names. p2 fails to install features or plugins that have the same name but different version. We therefore plan to rename the org.eclipse.ocl-based names to ocl.eclipse.ocl20a in 3.0.0M5 to avoid the p2 problems. [20a represents the first attempt to codify the Eclipse resolutions of OMG 2.0 specification problems.] Questions: Is it right to rename plugins and features (but not packages or extension points)? Is p2 at fault in forcing us to rename? Are we wrong to try to provide API compatibility in an alternate release? Is there a better solution? If you are able to help us please comment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=293605. |
|
By Alexander Igdalov on Nov 26, 2009 15:14 (In reply to comment #28)
Ed, the test feature name (org.eclipse.emf.ocl.tests-feature) contains "emf" too.
This is a very good idea to make this post. I will add a line or two to your description and post it to the cross-project list. Regards,
|
|
By Ed Willink on Nov 26, 2009 15:57 (In reply to comment #29)
This is dead. -- The problem with the launch is that each of the AbstractTestSuite classes had a plugin id string. Following the commit for Bug 254919 this string moves to the TestReflection.Static.getTestPlugInId() method. These string need changing from ocl to ocl20a. NB. Bug 254919 added an org.eclipse.ocl.tests plugin. Only you can edit the releng and psfs. |
|
By Ed Merks on Dec 01, 2009 06:50 I'd like to understand what's driving this fork of the code. Certainly UML has made API incompatible changes without taking this forked path, so what's driving OCL to take a path I've never seen any other project take? Why not simply break the API and tell clients to use the new one? Are you expecting all clients to also fork their code? |
|
By Ed Willink on Dec 01, 2009 15:47 (In reply to comment #31)
Since we're changing the API, we would like to allow existing MDT/OCL dependent code to run on Helios. This motivated the 1.4.0 maintainance idea [1.3.0 perhaps should have been 2.0.0 since org.eclipse.ocl.uml went to 2.0.0 to track UML2, but since org.eclipse.ocl.ecore didn't need a major change none was made elsewhere.] I wrote in #25 when preparing to ask for wider advice: "If community input fails to identify an alternative, and if a community is identified that requires 1.4.0, ..." Two big IFs. I do not know who will use Eclipse 3.6 while using some third party package with an OCL 1.3.0 dependency. Our major known concern was QVTo and consequently GMF. QVTo seems happy with the changes so far. |
|
By Ed Merks on Dec 01, 2009 17:15 Don't try to ship two streams into Helios. It's best to ensure that all other Helios dependencies use your newest version. Don't give them a choice. Please let the PMC know if there are any hold-outs. |
|
By Alexander Igdalov on Dec 02, 2009 08:54 (In reply to comment #33)
Hi Ed, It's not only Eclipse downstream projects that we are concerned about. We also take care of third-party OCL clients that have their commercial projects dependent on MDT OCL 1.3.0. Regards,
|
|
By Ed Merks on Dec 02, 2009 09:22
My comments are about providing two releases of OCL in Helios. Provide other releases if you like, but don't try to feed them into Helios.
This is merely an assertion. It's open source and there's no such obligation to give anyone years to do their migration work. Anyone is welcome to keep using older versions.
What version will GMF use? Will clients of GMF also be given a choice? It's nice to offer clients a choice but I would suggest you do this off on the side and that you don't try to make the two version coexist in a single installation.\
Given that all models register themselves with the package registry all models must be singletons. The PDE notices that extension points are being used and is tell you what you're doing isn't valid. |
|
By Ed Willink on Dec 09, 2009 03:15 The changes to EMF EModelElement inheritance make provision of a simple 1.3.0 functionality-preserving 1.4.0 far from simple. Provision of both 1.4.0 and 3.0.0 in Helios seems difficult, unwelcome and unwise. Therefore the 1.4.0 maintenance release is abandoned, and there is no need to rename plugins and features in the 3.0.0 stream. [If a co-existing 1.4.0 is ever re-activated, the 1.4.0 release should have renamed plugins and features.] |
|
By Ed Willink on May 27, 2011 02:46 Closing after over 18 months in resolved state. |
| --- | --- |
| Bugzilla Link | 293605 |
| Status | CLOSED WONTFIX |
| Importance | P3 major |
| Reported | Oct 28, 2009 14:48 EDT |
| Modified | May 27, 2011 02:46 EDT |
| Version | 3.0.0 |
| Reporter | Alexander Igdalov |
Description
Due to the fact that p2 cannot install features with the same name but different version we have no other option than to change all feature names in 3.0 stream. Otherwise they conflict with those in 1.4 stream.
Since this is a trivial change, it doesn't need to be reviewed. I will commit the changes and see what the build procedure and the p2 installer say about them;)
The text was updated successfully, but these errors were encountered: