Hi, Ernesto,
See some further replies in-line.
cW
On 11 May, 2016 at 12:09:30, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: Hi. Some comments inline. Hi, Asma,
Find some replies in-line, below.
On 11 May, 2016 at 07:55:42, SMAOUI Asma (asma.smaoui@xxxxxx) wrote: Yes. I tried again, and it works now J thanks. However, I get the same error (got before) expect the empty working set. I assume that oomph get the last updated set up file (since I get no empty working set now) that Christian pushed. Now, I want to test the updated setup file in this gerrit https://git.eclipse.org/r/#/c/70911/ to avoid manual code generation from xtuml models. How can I do it ? how can I tell oomph to use the Ernesto updated setup file ?
That’s what the “Papyrus-RT -> Oomph Setup” project is for. Import that, re-start the workbench, and then Oomph will re-direct the URI that links the Papyrus-RT setup model into the catalogue to find it instead in a checkout of the Papyrus-RT website in your local git. Then, you need to fetch Ernesto’s patch into that local git repository of the website and the next time you run an Oomph setup from within your Eclipse installation, Oomph will see that patch. This mechanism is described perhaps a bit more clearly, here: https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs
Christian, out of curiosity, I don't see anything in the .setup that sets "oomph.redirection.papyrusrtsetups", but it is in my eclipse.ini. How did it get there?
It’s the “Eclipse Ini” task in the Oomph Setup sub-project.
Also, I have used another method: start the Eclipse Installer, add the setup file to be tested to the <User> projects folder, and select those components for installation, to create a new workbench. I assume this would not conflict with the existing workbench. Is this correct?
That’s right. It’s just confusing that then there are two copies of everything: the “official” projects in the central catalogue and your local user projects. And trying to switch back and forth between these projects in a single workspace is awkward. But it works fine.
For errors dealing with lifecycle management, what is the best procedure to follow : 1) Ernesto patch here https://git.eclipse.org/r/#/c/72334/ 2) Celine suggestion to disable and enable maven nature 3) Fixes proposed here (figure bellow: discover m2e connectors : I think that Ernesto, who definitively hate m2e will think that it is absolutely not a good idea ;)
I think the life-cycle mapping metadata in the workspace's metadata is a better solution, my gerrit is also plagued with debatable changes to .classpath and .prefs files (which now I'm not sure if were created when I did a Maven->Update Projects or when I disabled and reenabled the Maven nature). So that gerrit is at best incomplete, and at worst, making things worse.
I’m inclined to agree, yes.
The problem with #2 is that there are a lot of projects that have these errors. If there was a way to do them all at once, it wouldn't be too big a deal, but the fact that you have to do it manually one by one is horrible, just as #3. In my case, I tried both #2 and #3 and still get errors! (which explains my growing dislike of m2e ;))
Asma, if you get it to work, please share your solution! This is evidently a common problem, viz
I think this will probably end up being a part of the solution, as well as installing the connectors that we know we need (such as Tycho).
Great link! This is very useful. The issue now is to determine what should be in the lifecycle mapping. In theory, every goal should be executed, but as discussed, the antrun plugin should probably be ignored, at least for now. I'll experiment and report back here.
I think we could just suppress the antrun in this lifecycle mappings preference file for now and remove the same from the POMs. That just leaves the three lifecycle errors in the feature POMs that I mentioned earlier, which we can then review. The nice thing about this is that by default, m2e doesn’t create this file in the preferences, so we can actually create it in the setup model and then the next time developers run the setup, they will get this file. That is, assuming they didn’t already create it for themselves. That’s the tricky bit: we get one chance at creating this file; Oomph will not replace it if we make changes (users would have to delete it and then let Oomph re-create it). BTW, the m2e connectors that we know we need are currently installed in my Eclipse from here: M2E Buildhelper Connector - http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-buildhelper/0.15.0/N/0.15.0.201207090124/ org.sonatype.tycho.repository - http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.8.0/N/LATEST/
So, we can just go with these for now in the setup model? |
