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.
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.
<image>
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.
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. 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.
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.
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/
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.
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.
|
