Community
Participate
Working Groups
I've just migrated my workspace to M7 and get 454 errors perhaps all to do with being unable to find org.eclipse.xtext.parsetree.reconstr.IInstanceDescription. If it was in M6 how can it not be in M7?
Hi Ed, I'm afraid you have to regenerate your language. Unfortunately there was a refactoring necessary to keep the code clean and readable. Thereby some classes had to be renamed that generated code refers to. If you don't mind I'ld like to close this ticket. Is that ok for you? Did a regenerate help? Sorry for any inconvenience, Sebastian
I sympathize with refactoring, but I thought the Simulataneous Release Ruiles were no API changes after M6, so I hoped that by developing post M6 I was ok. But no, once I can get a build to work, MDT/OCL will have to ship an M7a because its M6 editor code doesn't work on M7. I also have a problem with DefaultCrossReferenceSerializer no longer existing and its interface going deprecated. Deprecated is ok, but once in M6 surely it must stay for two releases. Shouldn't you re-introdyce a deprecated IInstanceDescription to preserve compatibility.
(In reply to comment #2) > I sympathize with refactoring, but I thought the Simulataneous Release Ruiles > were no API changes after M6, so I hoped that by developing post M6 I was ok. > > But no, once I can get a build to work, MDT/OCL will have to ship an M7a > because its M6 editor code doesn't work on M7. > > I also have a problem with DefaultCrossReferenceSerializer no longer existing > and its interface going deprecated. > > Deprecated is ok, but once in M6 surely it must stay for two releases. > > Shouldn't you re-introdyce a deprecated IInstanceDescription to preserve > compatibility. Hi Ed, the bad news is that the ICrossReferenceSerializer actually has not only been deprecated but there was some renaming involved, too. This was not backwards compatible in terms of binary or source compatibility. But it should be straightforward to adopt the new method names. We consider this clean up to be very important for Xtext and we'll more than happy to help early adopters to migrate their code to the next milestone. Your customized CrossReferenceSerializer should inherit from the org.eclipse.xtext.parsetree.reconstr.impl.CrossReferenceSerializer if it used to extend the DefaultCrossReferenceSerializer. I hope that you will not struggle to much with the necessary steps to keep your code in sync with latest refactoring / fixes in Xtext. It is always a good idea to regenerate your language after an update of Xtext. There is no way for us to be 100% backwards compatible with previously generated artifacts as we would have no chance to fix anything in the generator itself or the framework code. Regards, Sebastian
Thanks for cc'ing me in Ed. It looks like we're the big consumers of XText around here. This is the other build issue that I mentioned in bug 311662. (In reply to comment #3) > It is always a good idea to regenerate your language after an update of Xtext. > There is no way for us to be 100% backwards compatible with previously > generated artifacts as we would have no chance to fix anything in the generator > itself or the framework code. Yeah, for sure..Coincidently I'm just in the process of making major framework changes along with the codegen changes to go along with them for AMF. (Though AMF models get built automatically so its not as big of a deal with my tool consumers.) The good news is that we don't have to actually edit the code.
(In reply to comment #3) > It is always a good idea to regenerate your language after an update of Xtext. > There is no way for us to be 100% backwards compatible with previously > generated artifacts as we would have no chance to fix anything in the generator > itself or the framework code. This is what APIs are about. The 'runtime'/'core' provides a set of facilities (APIs) that the 'generated' code can exploit allowing regeneration to be an option to use new facilities but not a requirement to continue to use old facilities. EMF and GMF have been quite good in this respect. Xtext needs to establish a usage API. While there are a small number of consumers we can grumble and workaround this and although 1.0.0 changes should have stabilised at M6, on balance we must recognise that such an excellent product merits some latitude at 1.0.0. I think that you now need to plan to keep the de facto 1.0.0 APIs throughout 1.x, which almost certainly means that you need to go straight to 2.0.0 next release with a revised stable although internal API that you are happier to freeze at 2.0.0M6. [Happy to close.]
(In reply to comment #5) > (In reply to comment #3) > > It is always a good idea to regenerate your language after an update of Xtext. > > There is no way for us to be 100% backwards compatible with previously > > generated artifacts as we would have no chance to fix anything in the generator > > itself or the framework code. > > This is what APIs are about. The 'runtime'/'core' provides a set of facilities > (APIs) that the 'generated' code can exploit allowing regeneration to be an > option to use new facilities but not a requirement to continue to use old > facilities. Let's distinguish different motivations for code generation: In EMF and GMF code is generated in a re-runnable scaffolding like manner. The generated code is a building block of your software and you are supposed to edit it to fit your needs. That is why I compared it so scaffolding: In the beginning of your development cycle you focus on generation and towards the end you focus on modifying the previously generated artifacts. The code generated by Xtext is more like a library that is tailored to your project. Like a library, you don't modify it directly, but there many hooks (via Guice) to customize it. So in Xtext, the generated code is *not* a piece of software that you start modifying manually. There are two different benefits: - It provides API that is optimized for your grammar. Example: GrammarAccess, ContentAssists. - It provides facilities for your language: Example: Parser, Serializer. As you can see, here it is not about generated code using facilities from a core library, but about generated code *being* the facility. As Sebastian pointed out, this leads to the point that we sometimes need to change the code generator. Actually, I'd rather call the generated code public API and not the code from the core framework that is used by the generated code.
Closed as suggested in comment #5.
(In reply to comment #7) I don't understand your argument. The simple problem is one of comaptibility. If I have a Java 1.4 application I expect its classes to work on 1.5 but not on 1.3. Similiarly if I have an editor developed on Xtext 1.0, I expect its classes to work with Xtext 1.1, but not Xtext 0.8. The removal of IInstanceDescription in M7 meant that the above logic was untrue following the M6 API freeze. OCL and AMP editors developed under M6 failed to work on M7 because the required interface was not present. This oversight can be forgiven now between M6 and M7, but if it occurs between 1.0.0 and 1.* there will be many unhappy customers and consumers. Don't forget that Xtext is used to deliver third party solutions. It is not just a tool for end users who can rebuild.
I'm finding this to be a very interesting discussion. Especially as I'm in the middle of a major refactoring that breaks APIs. But I'm at ~0.7.0 and not cursed with too many users at this point. :) And as I mentioned elsewhere my code is typically generated automatically at runtime, not design time. Anyway, as with any other design issue, there's an inherent dynamic between flexibility and stability. Yeah, duh, but the tradeoffs get deeper as we're dealing with code generation. Since the Eclipse culture is quite conservative with breaking API changes that's naturally going present interesting new challenges. As Ed says, where n.x.y, you cannot really introduce breaking API changes in x or y. You can deprecate in x, but you need to have a path. Let's call that a "bad break" IFF it violates this principal for either generation or API issues. I think this is really a non-issue for M releases btw -- the point of M releases is that nothing's perfect. Personally, I'd rather have any warts out is we're going to need to live with it until 2.0.0. As Moritz says, we need to distinguish context. You can't say "don't touch the api" when we're dealing with internal APIs. But are the generated APIs really like internal APIs? I think there are too seperate issues here: Existing "srcgen", Guice or Extension integrations. I think it's pretty fair to say that a change to the XText API that would *fail* srcgen code would be considered a bad break, right? Existing "src". This breaks built code. Absent an automatic *runtime* build mechanism, I agree with Ed that that's a bad break. If a perfectly working plugin breaks when user upgrades from x or y, that's bad. Generated "srcgen", Existing "src". The interesting edge case is old "src" builds -- or at the very least executes, but a *regeneration* breaks "src". I don't see this as a bad break as it requires the plugin developer to take a positive step to re-generate the code, and at that point it becomes that developers' responsibility to see that these changes work. BTW, I'm not getting how Guice really alters these issues in itself, as long as the use of direct Java APIs is supported.
(In reply to comment #9) > I think this is really a non-issue for M releases btw -- the point of M > releases is that nothing's perfect. Personally, I'd rather have any warts out > is we're going to need to live with it until 2.0.0. The Eclipse ramp-down rules are minor increment API changes are ok till the API freeze at M6. Only features can change at M7. If the API tooling was used it would not permit an Interface removal without a major increment. Xtext 1.0.0 is a major increment, so 0.x.x compatibility is not a problem. The M7 rather than M6 freeze is unfortunate but probably all in a good cause. But this must not happen after 1.0.0 is released; not in 1.0.1 nor in 1.1.0.
Hi all, there's a difference between source and binary compatibility. If you think of code generation as part of the compilation process (and I think that's fair) Moritz and Sebastian were talking about source compatibility of APIs while Ed expected binary compatibility. That said, I agree that we should have binary compatibility from M6 on and especially during the RC phase because otherwise we would force consumers in the Helios train to regenerate/compile and rebuild. Which is not what you expect in an RC phase. Sorry for breaking this contract between M6 and M7, but we thought it was worth an exception. We'll make sure that you don't face these kind of issues during the RC phase. We'll stick with binary compatibility of the major APIs for the 1.* version. However, we plan to increment the major version each year, in order to be able to get rid of old deprecated stuff. Also note, that because of our philosophy to make everything available and customizable, it is hard to find a clear contract for what is considered API (hence stable) or not. If you use very internal things you might still face binary compatibility issues during the "stable"-phase. Our current approach is to talk to users and rely on our gut feeling to decide whether something breaks many clients or not. We'll update our API policy on our website ASAP.
