Re: [papyrus-rt-dev] m2e configuration

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Hi Christian. Comments in-line below.

On Mon, May 9, 2016 at 6:00 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Ernesto,

See some replies in-line, below.

Cheers,

Christian

On 9 May, 2016 at 16:54:54, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

I have made some progress with the m2e configuration issues. 

Thanks.  Anyone who volunteers for releng is a hero in my estimation.

Sometimes releng does feel like the 12 labours of Hercules ;)

Opening any of the problematic poms and clicking on the error message on the Overview tab gives a bunch of quick-fixes, which includes installing additional m2e connectors. After installing all required I do get the build-helper-maven-plugin and the Tycho Project Configurator, but I still get errors on the codegen projects, except for the XtUML-RT projects. But I found out some of the reasons:

This looks cool.  Whenever I tried to run that quick-fix, it just did nothing.  No dialog nor other feed-back.

Really? I don't get any quick fixes in the text/xml editor, but I do get a link on top of the pom editor's Overview tab. I'm finding this m2e feature to be rather flaky. 

 

We use the maven-antrun-plugin to build the RTS, and it looks like there is no connector that can resolve that, but one of the options is to add an "ignore" action to that plugin execution, as described in https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html. The quick-fix automatically adds the relevant declarations to pluginsManagement in either that pom or its parent. That's probably what we want, because after all, the RTS builds only on Linux.

Okay, so we only need that for building the RTS C++ code?  That’s fine with me; it’s perhaps less interesting to be able to build that in the development environment than it is to generate EMF models.

That's right, we use the maven-antrun-plugin to build the RTS C++ code, but we also use it in the o.e.prt.codegen.cpp.test plugin to copy some tests. But that's less important.

Since the RTS currently builds only on Linux, we can't build it in every developer's environment. But that's OK for now at least. We do have instructions on the wiki on how to build it.

 

Nevertheless, there are still tons of errors. I found two possible, but horrible solutions:

a) On each plugin with an error, disable the Maven nature and re-enable it.

b) Go to the Error Log, select the top element, delete it, and do a Clean... all.

The second one is easier, but a user shouldn't have to do either of these manually.

Hmm, the second one doesn’t work for me.

Did the first one work?

 

 I had already used m2e’s support for a workspace-local lifecycle mappings POM to suppress the maven-antrun-plugin errors.  Following the procedure b (I didn’t expect that m2e would leave these stale problem markers!) I still have errors on the POMs in three feature projects.  Each of these POMs:

• org.eclipse.papyrusrt.codegen-feature
• org.eclipse.papyrusrt.rts-feature
• org.eclipse.papyrusrt.xtumlrt.xtext.feature

has this error annotating the <parent> tag in the pom.xml:

Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:build-helper-maven-plugin:1.7:add-source (execution: add-source, phase: generate-sources)

which suggests to me that the problem isn’t in this actual POM, but its parent, which isn’t properly in the workspace.

The parent is releng/codegen/pom.xml. Perhaps we need to add an "execute" project delegator there. I'll try that and push it to gerrit, but I wonder why I don't get the same errors as you do.

 

Note also that we could add an initial lifecycle mappings preference file to the Oomph setup model so that we needn’t pollute our actual build POMs with these lifecycle mappings, but that will only help developers when they create a new workspace.

Good point. I'll try that. 

I've pushed 72334 to gerrit with the changes to the relevant poms. The gerrit also contains a whole bunch of other changes to .classpath and .prefs files. These resulted from me doing Maven->Update Project... (to all projects) as Celine had suggested before. I don't know if this is correct or not. Is this OK? So far the builds succeed in Hudson. I've put Christian and Celine as reviewers.

As I commented in the gerrit, the only thing I don’t like is change from bin/ output folder to target/classes/

Me neither. I don't know why m2e did that. The question is how to tell m2e not to do that. 

 

So it looks like we have two pending problems:

1) How and where to obtain the connector dependencies (and do that in the .setup)

I think probably we will just have to add two features obtained from high-maintenance update sites.  It’s either that or develop a new kind of setup task that automates the Maven Connectors Discovery tool, if it provides an API.

Perhaps we can figure out what are the update sites where those connectors come from? That would be a lot easier than a new setup task, I think.

 

2) How to avoid a) and b) above.

That problem looks to me like an m2e bug.  A change in the maven configuration environment should result in stale problem markers being deleted in the workspace.  It’s the m2e builder that has to do this.

Indeed. I'll look if m2e has a forum or mailing list or bugzilla list and search. But I'm getting the feeling that it is a very unreliable.

 

_______________________________________________
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