Add 'org.eclipse.m2e:lifecycle-mapping:1.0.0' to maven central

[hazendaz]

Hi, see discussion over at renovatebot/renovate#22579 (reply in thread).

Here is the situation.

There are some 27k repos that call out 'org.eclipse.m2e:lifecycle-mapping:1.0.0' based on check done there. I don't see that as actually deprecated here.

My ask over there was to make Renovate ignore the warning since that does not exist. Some things came to light out of this. First, there is better syntax since m2e 1.7.0 but don't think outside a visual change log it was even noticed. I've never seen any repo use it that way nor ever noticed until it was called out. The second option is to push up a dummy solution to central. Well that one I think only your team could do given the groupId. And final option was where we started in asking Renovate to possibly just ignore that one. But what about other similar tools?

So my thinking is that if m2e still supports that mechanism, has the ability to release on that group id, then releasing a fake jar out there as that would suffice for all use cases.

Open to any other suggestions? In the past this came up on a separate initiative I was working with regarding blackduck scanning. It too ended up having us require adding a bunch of stuff externally to all the pieces to make it presume to be approved at our workpace even though its not actually real. This would at least make it real and maybe even in that dummy jar, add resource samples that show all the variations, maybe ;)

[laeubi]

@hazendaz do you like to provide a PR that adds a module as you suggested to m2eclipse? I think the jar could at least contain the mapping.xsd

[HannesWell]

My ask over there was to make Renovate ignore the warning since that does not exist. Some things came to light out of this. First, there is better syntax since m2e 1.7.0 but don't think outside a visual change log it was even noticed. I've never seen any repo use it that way nor ever noticed until it was called out.

I think the processing-instructions are superior over the approach to use a pseudo plugin-config and therefore would be glad if this would be the motivation to improve the documentation about those processing-instructions and maybe even the tooling in m2e (e.g. by let m2e suggest to use those instead of a pseudo plugin-config or to convert from the plugin-config to the processing-instructions).

The only available documentation is:
https://www.eclipse.org/m2e/documentation/release-notes-17.html#new-syntax-for-specifying-lifecycle-mapping-metadata

[garretwilson]

I just found the note about processing instructions on Stack Overflow. The larger question and discussion shows that this is an issue, and if the processing instructions work, they should get more visibility.

Note that Eclipse Bugzilla Bug 367870 (and Eclipse Bugzilla Bug 541521) claims the bug was "moved" (i.e. refiled) here somewhere, but no one provided a link. Is it this the ticket it was moved to, or is there another one? I'm just trying to improve the documentation and add connections so that it will be easier in the future for people to find this.

[garretwilson]

Note also that the "documentation" indicates that I can use e.g. <?m2e ignore?> "in a <plugin> node", but doesn't clarify whether it can be used in the <build><pluginManagement> section (which would take care of all child POMs and importing POMs), or if it must be used only the <build><plugins> section. In particular this prose is confusing:

It can also be placed in a <plugin> node, this way it acts the same as a dedicated <pluginManagement> section which lists all goals of this plugin.

So if I place it in <build><plugins><plugins>, it acts "the same" as <pluginManagement> somehow?? Perhaps the prose meant to make an analogy of adding the processing instruction in one place and having it apply to multiple things, but as written it is confusing whether it is somehow "equivalent" or just "analogous" to the <pluginManagement> section. Someone needs to give this description a makeover. Actually dedicated documentation needs to be added for it, as the "documentation" I'm referring to was just sort of a "what's new" notice.

[jchamlin]

I tried to create a org.eclipse.m2e:lifecycle-mapping dummy jar. And what I found out is that the pom.xml editor checks the goals against that jar too. So, the dummy jar doesn't support those goals, the pom editor will complain. So to have a real dummy jar it would have to support every possible maven goal. I don't think that's realistic.

I ended up isntead using lifecycle-mappings-metadata.xml in the .metadata//.plugins/org.eclipse.m2e.core directory to store the lifecycle mappings and keep them out of the pom.xml. It would be nice to have them in the pom.xml so they are checked in, portable, and automatically available to anyone using Eclipse with the project without additional setup. The only real way to do that would be to have m2e know about this special artifact, and not flag it as a warning.

Also, m2e's pom editor complains about the lifecycle-mapping-metadata.xml not having an XSD, so I took the lifecycle-mapping-metadata-model.xml from the repo at https://github.com/eclipse-m2e/m2e-core/blob/9776a7ff672778266e56d4ee60a74ef6d14b9efd/org.eclipse.m2e.core/mdo/lifecycle-mapping-metadata-model.xml and fixed the file by replacing this section Map -> Set so it would build with modello without errors,

        <field>
          <name>parameters</name>
          <type>Set</type>
          <association>
            <type>String</type>
            <multiplicity>*</multiplicity>
          </association>
        </field>

and created the following lifecycle-mapping-metadata-model-1.0.0.xsd. It may be useful for anyone else editing the lifecycle-mappings-metadata.xml file in the pom editor or an editor with language server support to be able to validate the syntax of and provide autocopletions for the lifecycle-mappings-metadata.xml file. I renamed the attachment .xsd.xml so that I could upload it here (it didn't support uploading an .xsd file).

lifecycle-mapping-metadata-model-1.0.0.xsd.xml