Hi, Ernesto,
I think the Papyrus setup model actually configures that preference to “ignore”. 😕 I can do the something similar in this setup. There are a couple of different tasks in Oomph that have to do with API Baselines, but I haven’t investigated them, yet (there is no documentation for them). One thing I would like to avoid is forcing a download of a whole additional Eclipse installation on people. But one of these tasks appears to create an API baseline from a target, and if it can materialize a baseline from the same shared bundle pool as it does everything else, and if that baseline can include only the Papyrus-RT bundles, then that would be great. I’ll check it out.
Yes, the handling of generated code and the missing empty classpath container folders are not new and unaffected by this setup model. There are no setup tasks for generation of code, and I would much rather see a project builder that does the generation than to attempt to extend the setup framework for that. It really needs to be included in the incremental build in the same way as Xtend.
I forgot that I had fixed errors in the Xtext plug-ins by associating a Java 8 run-time with the JavaSE-1.7 EE, because at that time I still had some C++ Codegen plug-ins from Papyrus Extras that on the Neon branch were using Java 8 APIs and language features without having updated their BREEs. But, again, not a setup problem (that was missed in the original port to Neon).
For now, the setup model isn’t installing the codegen bundles in the development environment because (I think) originally I didn’t know that the Papyrus-RT feature actually doesn’t contain them (cf. the discussion about the “All” Hudson build and repository). But then, it seemed that only the tooling would actually be needed for development because it’s all that’s needed for editing the source models. If that’s not true, then I can easily enough add the codegen bundles to the workbench installation. Just let me know.
There are three places where you have to select “Neon” to get a proper Neon setup:
- the version of the Eclipse Product on which you’re basing your installation (I always recommend the Eclipse for Committers product)
- the stream of each of the Papyrus-RT project that you import from the setup model
- the value of the “eclipse.target.platform” variable, which if you selected the Neon streams of the imported projects, should default to Neon anyways
Is it possible that you missed one of those? In the mean-time, I’ll try with a new installation, too.
The default name for the git clone should be something like “papyrus-rt-neon” for a Neon stream checkout. I’ll try a from-scratch setup with a new clone and everything to test this.