Bugzilla – Full Text Bug Listing
| Summary: | Breaking ui/ide name change in 2.8.0M4 | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Ed Willink <ed> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | adolfosbh, jan, sebastian.zarnekow, st.oehme, sven.efftinge |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Whiteboard: | v2.8 | ||
|
Description
Ed Willink
Hi Ed, I understood that you used to regenerate your language against the latest Xtext version but installed that with an older version? Is that what you do? Yes. I want to use the latest and best Xtext to regenerate my editors for a range of Eclipse releases, just the same as I use the latest and best EMF. (The converse of having to use a release-specific generator per Eclipse release, or not support older releases is very undesirable. Unfortunately there are many users who are unable to update their Eclipse versions and so need back support.) It is generally not recommended to generate with version 2.y for a runtime env with 2.x. Why can't you use the version that you generate and build against also as the version that is installed? I don't know what version of Eclipse my users are using. I do know from Marketplace statistics that a depressing number of users were getting unhelpful P2 failures when trying to install Kepler OCL on Juno, so for Luna, I improved the backward capability so that Luna OCL to supports Xtext >= 2.3.0 and so out of the box Juno. (This required a minor *.xtextbin tweak to make it to 2.3.0 rather than just 2.3.1.) No more Marketplace issues. I doubt that this kind of backward compatibility has worked in the past. At least we don't do any explicit testing in this direction. Do you run any tests against Xtext 2.3.1? That said the refactoring you mentioned should be optional and defaulting to the old style. (In reply to Sven Efftinge from comment #5) > Do you run any tests against Xtext 2.3.1? Not regularly or automatically; just manually. I was pleasantly surprised when it worked. 2.3.0 was disappointing but *.xtextbin support was surprisingly easy. I think there is a Bugzilla open for you to autogenerate the BinaryResource rather than assuming it's there. > That said the refactoring you mentioned should be optional and defaulting to > the old style. The old names are available as deprecated, which is irritating on fault free code. The new generator uses the new names without option. It is an unfortunate corrolary of Xtext's utility that because it generates as well as consumes tools, it needs bidirectional compatibility. (In reply to Sven Efftinge from comment #5) > That said the refactoring you mentioned should be optional and defaulting to > the old style. I think it should be the other way round, an optional switch to use the deprecated API. It would be confusing if we generated deprecated code by default. (In reply to Stefan Oehme from comment #7) > I think it should be the other way round, an optional switch to use the > deprecated API. It would be confusing if we generated deprecated code by > default. Yes. Analogous to GenModel runtimeVersion. Initialized to the prevailing value on creation, preserved thereafter. So MWE script generation could freeze the Xtext runtime version as a fragment option. > (In reply to Stefan Oehme from comment #7)
> > I think it should be the other way round, an optional switch to use the
> > deprecated API. It would be confusing if we generated deprecated code by
> > default.
>
> Yes. Analogous to GenModel runtimeVersion. Initialized to the prevailing
> value on creation, preserved thereafter. So MWE script generation could
> freeze the Xtext runtime version as a fragment option.
We should enhance the project wizard, so the user can choose whether an ide project is wished. That wizard should create the needed projects and create a corresponding mwe2 configuration.
Unchanged existing mwe2 files shouldn't generate files into a non-existing project.
(In reply to Sven Efftinge from comment #9) > Unchanged existing mwe2 files shouldn't generate files into a non-existing > project. We still generate to the ui project/package, as always. The ide project is already optional. So that is not the problem. The problem is that there are new base classes and the old ones are deprecated/unmaintained. That is why I think that the backwards compatibility should be an option. Using the new, maintained base classes should be the default. (In reply to Stefan Oehme from comment #10) > Using the new, maintained base classes > should be the default. I don't think you understood my comment #8. When you create a new Xtext language and MWE script, the MWE script could acquire a fragment option specifying the prevailing default e.g. 2.8. (So yes the current practice is the default). But in a few releases time in the absence of edits, the MWE script will continue to specify 2.8 ensuring no change to consumers of the editor. For older MWE scripts that currently have no default, the default default could be 2.7 to provide ongoing compatibility. I'm not worried about the default default setting; I can change my MWE scripts. Perhaps the default default should be a warning. (In reply to Stefan Oehme from comment #10) > (In reply to Sven Efftinge from comment #9) > > Unchanged existing mwe2 files shouldn't generate files into a non-existing > > project. > > We still generate to the ui project/package, as always. The ide project is > already optional. So that is not the problem. > > The problem is that there are new base classes and the old ones are > deprecated/unmaintained. That is why I think that the backwards > compatibility should be an option. Using the new, maintained base classes > should be the default. Ok, I understand now :-) Makes perfect sense. Ed, I'm closing this as won't fix. We cannot keep this kind of compatibility, because it would further reduce the ways in which we can improve the framework and would be a lot of effort to test. If you want to make sure that your code works against 2.3.1 and 2.8 you need to code, compile and generate against 2.3.1 and run your tests also against 2.8. That's how we ensure compatibility with external libraries: Code and compile against the smallest version and run tests against all others (or the most important ones). (In reply to Sven Efftinge from comment #13) > Ed, I'm closing this as won't fix. OK, but I think you should change to 3.0, which will give you opportunities for other legacy cleanups. Not using the latest Xtext for development is pretty impractical, so I think that in Mars we will have to distribute an optional 'OCL' plugin that provides the missing xtext.ide declarations as delegations to xtext.ui for installations that have xtext.ui but no xtext.ide. Since this is not really an OCL plugin at all, just a compatibility, it might be better if Xtext hosted it. Presumably optional and dependent on Xtext 2.3 to 2.7 inclusive should ensure that P2 can sort out the problem. (In reply to Ed Willink from comment #14) I think you are better off with a clear dependency to Xtext 2.8 and a reference to the Xtext update site such that clients of yours will simply install the matching version when they upgrade their OCL installation. (In reply to Ed Willink from comment #14) > Not using the latest Xtext for development is pretty impractical, so I think > that in Mars we will have to distribute an optional 'OCL' plugin that > provides the missing xtext.ide declarations as delegations to xtext.ui for > installations that have xtext.ui but no xtext.ide. Since this is not really > an OCL plugin at all, just a compatibility, it might be better if Xtext > hosted it. See Bug 456506. Isn't the required content just what's in xtext.ui 2.8.0 that delegates to xtext.ide already? So you could just provide it as a compatibility feature that third parties could bundle in their own distributions. (In reply to Sebastian Zarnekow from comment #15) > I think you are better off with a clear dependency to Xtext 2.8 and a > reference to the Xtext update site such that clients of yours will simply > install the matching version when they upgrade their OCL installation. OCL is not always the most important product for customers. Xtext is widely used, so an existing installation may impose some version that OCL needs to work with rather than change. (In reply to Sven Efftinge from comment #13) > Ed, I'm closing this as won't fix. We cannot keep this kind of > compatibility, because it would further reduce the ways in which we can > improve the framework and would be a lot of effort to test. Bug 460522 decided to revert the "ui" to "ide" name changes, so presumably now FIXED. Thanks for coming back to this. |