| Re: [papyrus-rt-dev] [Neon] in Progress |
Hi, Ernesto,See some replies in-line, below.HTH,ChristianOn 7 April, 2016 at 16:25:52, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
With respect to #1, another possibility is, instead of having project builders, just committing the generated sources, as Ed Willink suggested in Bug 479634. But before making a decision, I sent an e-mail to IncQuery to check what was their original objection, and what approach would they prefer.
How does IncQuery enter into it? Is this “their” code? I don’t understand.
With respect to #2, I'll push a gerrit to fix it. We would still have to build the Xtext artifacts, and that should be done with a builder. I'll open a bug for it.
The Xtext SDK already provides a project builder, I think, so that much at least should be quite easy. It’s really the EMF-generated models that need more work because EMF doesn’t provide a builder.
You are right that you don't need codegen to create models, so it's OK for a development environment. By the way, you still have to create a run/configuration manually, right?
Sorry, I don’t understand the question.
As for the name of the checked out branch, I'm not sure. I thought I chose neon on all those, but I just started testing it again, and Oomph seemed to remember the last settings, and showed that I had selected Neon for all except for the "Releng/Oomph" component. This time I tried making sure I set all of them to neon, and it worked as expected. So, in the case where you choose different branches for different components is the expected behaviour to choose the last one? Or something else? Seems a bit confusing, if you select different branches. Makes me wonder why, if you are selecting components only from one git repo, should you be allowed to enter different branches for different components.
This is a limitation of the Oomph Setup model. Only projects that have streams can be imported, and you can choose exactly one stream of any project to import. Moreover, every project has to own the streams that it defines; they cannot be shared. And when your setup defines multiple development streams, then every project that is importable must repeat all of those streams, and they must all have the same name in each project. And there is no validation in the wizard to warn the user when they are importing conflicting streams from different projects because nothing in the Oomph run-time actually knows what they mean (it’s all just opaque IDs and labels as far as the system is concerned).
As for the name of the cloned git repo, my default is "${git.container.root/}${@id.remoteURI|gitRepository/}${@id.checkoutBranch}" so the name of the folder is as expected. I don't have a problem with that, but what I find confusing is how it's shown by EGit (so it's probably an EGit issue rather than an Oomph issue): it seems to show the name of the repo as the last segment in the path. It's not a big deal.
Yes, that’s just how EGit presents the repositories: using the last path segment. I keep all of my Git repos in /Users/damus/git/, so that works fine for me. 😉
On Thu, Apr 7, 2016 at 3:53 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote: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.ChristianOn 7 April, 2016 at 15:22:53, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I just tested the latest patch to the developer Oomph setup. Works great!There are a couple of kinks though:1. A bunch of 'API baseline has not been set for the current workspace' errors in the oep.umlrt.core and tooling plugins.2. Errors in the xtumlrt EMF plugins (see Bug 479634 and Bug 491189). For now it requires manual generation as described here: https://wiki.eclipse.org/Papyrus-RT/Developer_Guide/DevEnv_Mars#Generate_code_for_EMF_models3. Errors in the Xtext plugins: the execution environment has to be updated to Java 1.8; also there is a complain about missing 'src', 'src-gen' and 'xtend-gen' folders. Right now these are empty so they won't be on git. I'll push a gerrit for this.What should be done about #1? In the past I've changed 'Preferences->Plug-in Development->API Baselines->Missing API baseline' from "Error" to "Warning", but I get the feeling this is very hackiish. Shouldn't we add the target platform to the API baseline? Or something else?Also, Christian, I noticed that the latest setup model mentions the update site where successful builds from tooling are being published, but not the one for codegen. Does it matter?Other notes:- When installing, I selected the neon branch, but it cloned into a 'mars' folder and checked out the mars branch.- In the Git Repositories View the cloned repo is shown as if it was called with the checked out branch (mars). I think it would be better to give it the same name as the repo, specially since one may clone other repos (I used Oomph earlier to setup PapyrusRT by first setting up Papyrus and as a result I got two repositories named 'master' in the Git Repositories View)On Thu, Apr 7, 2016 at 12:34 PM SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:Hi,
It is only a git repo, no gerrit on it yet. This should be interesting to open it to gerrit, for external contributions.
git://git.eclipse.org/gitroot/www.eclipse.org/papyrus-rt.git
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Ernesto Posse
Envoyé : jeudi 7 avril 2016 18:30
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] [Neon] in Progress
The website exists at https://www.eclipse.org/papyrus-rt/ but it's not connected to gerrit. So far it's been Simon maintaining it, and I don't recall where it is stored. I'll look it up.
On Thu, Apr 7, 2016 at 12:02 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,
No, I don’t suppose we would care much about the history of the setup model, but we would get it for free, because the Eclipse website is maintained in git.
BTW, I don’t see a repository for the Papyrus-RT website in gerrit. Does the website exist, or is it just not (yet) connected to gerrit?
Christian
On 7 April, 2016 at 11:59:48, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I think the argument for putting the setup model in the web repository is very good. But I'm assuming we don't care much about the model's history, is that right?
On Thu, Apr 7, 2016 at 11:49 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi,
As a latecomer to the project, I have to ask why hyphens in project names are bad. Many, if not most, Eclipse Projects use feature IDs that are the same as their lead plug-in IDs, and so append a “-feature” on the name of the feature project to make it distinct in the workspace from the bundle project of the same name. This avoids the redundant suffix “.feature” in the actual feature ID, which the results in a p2 IU name with “.feature.feature.group”.
Anyways, I can certainly postpone any requests to the Oomph team for cataloguing our setup model until we have settled the issue at hand. Developers can always add the setup to their User Projects from their git checkout.
But, now that you mention it, this reminds me of a problem that we have in Papyrus that would perhaps best be avoided here while we have the chance. The problem is that the setup model actually includes information for all development streams of the project, which means that it doesn’t make much sense for it to be hosted within the same Git repository as the source code that is branched for those various development streams. In Papyrus we are now maintaining the setup model on the master branch only, which means that if you’re working on (e.g.) Mars branch, then you have to switch back-and-forth to the master branch to work on the setup model. Very cumbersome.
So, I would rather maintain this setup model for Papyrus-RT in the web repository. The extra benefit of this is that then the Oomph Catalogue can reference it on the Papyrus-RT website, which by-passes the Git repository viewer. That would make our Webmasters very happy (the web server takes quite a hit whenever Oomph requests resources from the git viewer).
Comments?
Christian
On 7 April, 2016 at 11:36:38, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:
Hi,
I have not looked at the latest patch set yet, I just wanted to give a quick comment, since I saw that you wanted to get the model added to the Oomph catalogue (which I think will be great).
As part of https://git.eclipse.org/r/#/c/69746/ Celine proposed to rename the project in which this setup-file is placed. Celine's argument was that it needed to follow naming rules which disallows '-' to be included in the project name. I made the comment that any change to the project name, will impact the installation instructions, including any users that already have followed these instructions and now have a reference to the setup file via a plain git resource link as given by the instructions at https://wiki.eclipse.org/Papyrus-RT/User_Guide/Eclipse_Installer
Since I do know that the Oomph catalogue uses exactly the same approach using a plain git resource link, we will "bump into" yet another issue if we later decide to change the name of the project containing these setup-files, then with both the product setup files as well as the new project setup files.
So I would really like to settle the name of this project. I do know that Celine reverted the name of the project in later patch sets of that Gerrit change, but I guess Celine still thinks that the project should align its names. As I indicated in that Gerrit change, I think that Charles should give his view on any name change, since it will impact the installation guide (which Charles has mainly worked with) and the aspect on the impact on any existing users that now has references to a file in this project in the Git repo.
Simplest would of course be if we just accepted that this project keep its name which does not follow the naming conventions. But I don't know what kind of impact that will have.... Celine, please give your view regarding this.
/Peter Cigéhn
On 7 April 2016 at 17:07, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Team,
To follow this up, I have just pushed a new Gerrit patch for a new Oomph setup model for Papyrus-RT development:
I would greatly appreciate a review of this patch so that we can merge it and request this new setup model’s addition to the Oomph catalogue to get the development team on track for Neon development.
In the meanwhile, if you’d like to get a head start on Neon, you can fetch this patch and use the setup model from your local filesystem.
Thanks!
Christian
Hello everyone,
The Neon build has been merged on the master branch.
But the papyrus-rt.setup file has not been updated accordingly yet and should be soon available. Allowing an easy update of your IDE.
Therefore, it is recommended to push your work on the new mars branch "origin/mars" waiting for this update in a couple of days.
Regards
Céline--
Céline JANSSENS
Software Engineer
+33 (0)2 44 47 23 23
Mail : cej@xxxxxxxxxxx
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev______________________________________________________________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev