maven-based target platform definition: option to generate new manifest even if one already exists?

[sratz]

The missingManifest="generate" option in maven based target definition allows me to generate an OSGi bundle, if it is not one already.

However, we have a use-case where the artifact already is an OSGi bundle, but we need to modify it for consumption.

What do you think about providing a new option like forceGenerateManifest="true" to allow this?
(Alternatively a 4th alternative for the existing missingManifest option, although that would not really fit, since the manifest isn't actually missing).

This would allow us to fully migrate from https://github.com/reficio/p2-maven-plugin to Tycho.

[laeubi]

Can you explain why you need a different manifest? If there are any bugs it might be better to ask the provider to fix them?

[laeubi]

The target support is not really meant to fix broken manifests, so I'm not very convinced we should add those, also there is no requirement that the maven version matches the bundle version...

[sratz]

The target support is not really meant to fix broken manifests

I agree, but since the infrastructure to generate them is there now, the fixing part can trivially be implemented without much effort.

here is no requirement that the maven version matches the bundle version

Maybe there are other scenarios, where one might want to modify/add BND instructions.

Such an option would be quite helpful. It should of course be documented accordingly that it's preferred to not touch existing bundles and considered an advanced option.

Otherwise, I am kind of stuck with the old legacy https://github.com/reficio/p2-maven-plugin which does not appear to be actively developed anymore.

[laeubi]

The target support is not really meant to fix broken manifests

I agree, but since the infrastructure to generate them is there now, the fixing part can trivially be implemented without much effort.

First, as you have already noticed, its not quite clear how this could be implemented in a way that seems not "odd" (e.g. another option for "missing manifest" that replaces a manifest sound really odd). Second one has to test and support such option.

Next the "generate" option is more meant for intermediate usage than as a replacement for any tooling constraints, managing many items with specialized BND instructions will result in large target files that are hard to manage and understand.

here is no requirement that the maven version matches the bundle version

Maybe there are other scenarios, where one might want to modify/add BND instructions.

A manifest is not necessarily created out of BND instructions, and it might then be more valuable to have a real BND step doing what is desired https://bnd.bndtools.org/chapters/390-wrapping.html and later deply the result unter a new dedicated GAV

Such an option would be quite helpful. It should of course be documented accordingly that it's preferred to not touch existing bundles and considered an advanced option.
Otherwise, I am kind of stuck with the old legacy https://github.com/reficio/p2-maven-plugin which does not appear to be actively developed anymore.

I would more consider it a workaround :-) Especially if you are talking about snapshot builds, it seems it will more help in not fixing the build-issue than solving a real problem. Also such an option would mean that always all manifests of a location are recreated, what will further limit the usefulness, because then you most likely will require one location and one bnd instruction for every single artifact and can't use transitive dependencies to be included automatically.

[akurtakov]

IMHO Tycho should not add such option. That would be extremely error-prone option.

[mickaelistria]

I agree with Alex. What's suggested here is extremely likely to create "unofficial" forked artifacts, that are then published in p2 repo, mappend to Maven coordinates of an artifact that is in practice different... Implementing this would IMO be more than error-prone, but even harmful to the ecosystem.

The proper solution to "we have a use-case where the artifact already is an OSGi bundle, but we need to modify it for consumption" is to fix that particular case with a particular solution (fixing the artifact, or creating another artifact exporting same packages but with some fix and requesting the fixed one in clients).