Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] New problem with Oomph developer setup
Comments inline.

On Wed, May 11, 2016 at 2:31 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
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.

On Wed, May 11, 2016 at 8:14 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Asma,

Find some replies in-line, below.

Cheers,

Christian



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.


Ah! I missed it. Thanks. 


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.


I've used this approach to install new workbenches with new workspaces, in order to recreate the scenario of a user that doesn't have the workbench already installed.

But considering the troubles that I've had, not just with m2e but also with my "Secure Storage" and the EMF code generation, I'm wondering if there might be something that might be causing conflicts between multiple installations. Perhaps issues with my .p2, .m2 or .eclipse folders. If I remove these, I should be in a clean slate right?
 


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:

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?

Done. I just pushed 72559 and added you as a reviewer. I put the features and these two repos under the "Core Development Tools" P2 director. Is that the appropriate place?

I haven't tested it yet. I'm about to.

For the m2e buildhelper we still have only that very specific version, right? 
 
 
_______________________________________________
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

Back to the top