bnd
bnd copied to clipboard
BndTools plugin has lifecycle mapping error for 6.2 or 6.3-snapshot on Eclipse Jee 202203.
Conflicting lifecycle mapping (plugin execution "biz.aQute.bnd:bnd-maven-plugin:6.2.0:bnd-process (execution: default, phase: process-classes)"): Mapping defined in 'org.eclipse.m2e.pde.connector_1.20.0.20220208-0831 [605]' and 'bndtools.m2e_6.3.0.202204052137-SNAPSHOT [952]'. To enable full functionality, remove the conflicting mapping and run Maven->Update Project Configuration
Here are the exampleProject. Please check the pom.xml of adsf project. exampleProject.zip .
Hi @simonjhy please file an issue with m2e project since they are the ones who recently decided to add a lifecycle mapping for bnd plugin.
https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.pde.connector/lifecycle-mapping-metadata.xml#L35-L50
I think it's more than fair that bndtools be allowed to own this mapping.
Yes, this seems to be an issue with Eclipse 2022-03. It looks like the PDE M2E connector has added a mapping for the bnd-maven-plugin.
This is not really a Bndtools issue. It is natural for Bndtools' M2E plugin to have a mapping for the bnd-maven-plugin.
There are a couple of workarounds:
- Uninstall the PDE-M2E component if you don't need it. This is the easiest option.
- I think I figured out a way to force M2E to use the Bndtools mapping rather than the PDE one. Unfortunately, I think that this needs to be done on a project-by-project basis. I know it is possible though because I've done it.
https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.pde.connector/lifecycle-mapping-metadata.xml#L35-L50
I think it's more than fair that bndtools be allowed to own this mapping.
We should discuss this with @laeubi as git blame shows him as the one who committed this.
I think it's more than fair that bndtools be allowed to own this mapping
bnd is allowed to do so, m2e only adds a configurator to configure PDE. This has nothing to do with bnd-mappings.
Mapping defined in 'org.eclipse.m2e.pde.connector_1.20.0.20220208-0831 [605]' and 'bndtools.m2e_6.3.0.202204052137-SNAPSHOT [952]'.
As one can see here its not the bnd-maven-plugin
but the bndtools.m2e
plugin that most probably defines another configurator.
- Uninstall the PDE-M2E component if you don't need it. This is the easiest option.
No the easiest option is to use the quickfix and chose one of both (what ever you think solves your situation better)
- I think that this needs to be done on a project-by-project basis
Exclusions could be made on workspace or project level (if you add the snippet to the pom.xml) see https://github.com/eclipse-m2e/m2e-core/issues/549#issuecomment-1031493540
BTW the screenshot shows a conflict with the SLING-IDE so if you also install sling there will be three choice :-)
Thanks for the insight @laeubi. So it sounds like the solution here is some documentation.
Could you help us write up how to solve the conflict? It seems that even marginally experience Eclipse developers had a hard time resolving this in what sounds like the standard way. Can you show us some screen shots of how to resolve the conflict? I personally don't recall being given an quickfix option but maybe I was looking in the wrong place.
This is how it will look like for a execution phase with duplicate mappings:
This for a duplicate packaging type mapping:
this requires the latest m2e release. Also keep in mind that you might need to update the project configuration after ignoring a certain plugin. Just in case this is still not shown let me know and I'll take a look at it.
Awesome, you don't mind if we put these images in our docs. I am thinking the Wiki for example.
@simonjhy would you kindly confirm if this solved your problem?
Awesome, you don't mind if we put these images in our docs. I am thinking the Wiki for example.
Feel free if you think its useful :-)
by the way it would be useful to check what bndtools.m2e
actually do (maybe similar to what m2e.pde.connector
does) and if it might make sense to merge/contribute some codes here.
we know for sure that the bnd configurator adds code annotations/decorations for OSGi specific aspects.
See https://github.com/bndtools/bnd/blob/0a0bea1c0a675295e5703db3c3173070951b8132/bndtools.m2e/src/bndtools/m2e/BndConfigurator.java#L343-L367
Hi @simonjhy please file an issue with m2e project since they are the ones who recently decided to add a lifecycle mapping for bnd plugin.
https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.pde.connector/lifecycle-mapping-metadata.xml#L35-L50
I think it's more than fair that bndtools be allowed to own this mapping.
The bnd-maven-plugin
contributes its own Eclipse m2e mapping. So I'm not for sure why the pde-connector contributed mapping is ever needed.
https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml
The
bnd-maven-plugin
contributes its own Eclipse m2e mapping. So I'm not for sure why the pde-connector contributed mapping is ever needed.
So why is bndtools.m2e
then 'ever needed'? :-)
As I described above pde-connector
does not contribute a mapping it contributes a project configurator and that's needed because PDE by default does not know where BND / Maven places the generated manifest so m2e 'helps' eclipse here by configuring the project accordingly.
As promised I've added a wiki entry about it [1]. Please if I have not explained the resolution properly feel free to update it.
[1] https://github.com/bndtools/bnd/wiki/Conflict-with-M2E-PDE-Connector
@laeubi the bndtools.m2e
feature does a few things as you can see from the _plugin.xml
:
- it adds a build configurator to execute the jar task when using the
maven-jar-plugin
because bnd has plenty of aspects which rely specifically on the final jar unlike more plain Java projects that can be satisfied by the output directory alone. So bndtools in all cases will try to have Eclipse end up with a jar for each project (with the newest releases of bnd you can use thebnd-maven-plugin
directly for packaging which makes this part of the configurator not so important). - the configurator also makes sure to sync markers on java types and packages, bnd, bndrun files etc, at the end of every build operation.
- it adds shortcuts for launching OSGi runtimes and integration tests
Hope that helps a little.
The
bnd-maven-plugin
contributes its own Eclipse m2e mapping. So I'm not for sure why the pde-connector contributed mapping is ever needed.So why is
bndtools.m2e
then 'ever needed'? :-)As I described above
pde-connector
does not contribute a mapping it contributes a project configurator and that's needed because PDE by default does not know where BND / Maven places the generated manifest so m2e 'helps' eclipse here by configuring the project accordingly.
Ah, I understand now. So the m2e project configurator lifecycle mappings support has this notion of primary / secondary configurators. Perhaps you could specify that the pde-connector "project configurator" should run after (or be secondary to) the bnd-m2e's project configurator. Could you maybe investigate this type of configuration? Here is an example of m2e project configurator that has been declared to be "secondaryTo" another "project configurator". https://github.com/liferay/liferay-ide/blob/master/maven/plugins/com.liferay.ide.maven.core/plugin.xml#L10-L16
What do you think about this idea?
the configurator also makes sure to sync markers on java types and packages, bnd, bndrun files etc, at the end of every build operation.
You might want to make bnd-maven-plugin to use a BuildContext that way you can add/update markers in a project without any special code an m2e will notice them.
Perhaps you could specify that the pde-connector "project configurator" should run after (or be secondary to) the bnd-m2e's project configurator
The m2e connector is only to support people using bnd-maven-plugin
with PDE and does not require bndtools. If BNDTools includes m2e+m2epde it might work the other way round, or we probably could extend m2e to have optional primary mappings or something like this ... if anyone of the bnddevlopers likes to investigate here and feels something missing let me know.
Ah, I understand now. So the m2e project configurator lifecycle mappings support has this notion of primary / secondary configurators. Perhaps you could specify that the pde-connector "project configurator" should run after (or be secondary to) the bnd-m2e's project configurator. Could you maybe investigate this type of configuration? Here is an example of m2e project configurator that has been declared to be "secondaryTo" another "project configurator". https://github.com/liferay/liferay-ide/blob/master/maven/plugins/com.liferay.ide.maven.core/plugin.xml#L10-L16
What do you think about this idea?
On Thu, Apr 7, 2022 at 11:04 AM Christoph Läubrich @.***> wrote:
The bnd-maven-plugin contributes its own Eclipse m2e mapping. So I'm not for sure why the pde-connector contributed mapping is ever needed.
So why is bndtools.m2e then 'ever needed'? :-)
As I described above pde-connector does not contribute a mapping it contributes a project configurator and that's needed because PDE by default does not know where BND / Maven places the generated manifest so m2e 'helps' eclipse here by configuring the project accordingly.
— Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/5203#issuecomment-1091918863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAERKFJUEGZTZLJWYVGJX33VD4BQ3ANCNFSM5SXWBBRQ . You are receiving this because you commented.Message ID: @.***>
-- Greg Amerson Liferay Cloud. liferay.com