Placeholders in target definition

[fipro78]

Hi,

I played around with repackaging the openjfx jars as OSGi bundles. I use the Maven locations in the target definition with the "generate" option and customized bnd instructions. The results are promising, although not yet 100% compatible with the e(fx)clipse runtime, but that is a different topic.

https://github.com/fipro78/javafx-osgi

The build works nice, but I have to specify the org.openjfx library version in the Maven coordinates. I would like to parameterize the build, so it is easy to create the bundles for newer versions with just an environment variable, instead of changing the target definition every time. I tried different ways:

• Maven property ${revision}
• Eclipse variables as described here
  • ${system_property:revision}
  • ${env_var:revision}

But nothing is resolved.

Question 1: Are properties/variables supported for Maven locations in a Target Definition?
Question 2: Would it be possible to do the repackaging in plain Maven so the Target Definition is not required?
(Although I then don't know directly how to build the features. But one step after the other.)

Greez,
Dirk

[laeubi]

I would like to parameterize the build, so it is easy to create the bundles for newer versions with just an environment variable, instead of changing the target definition every time

You need to mange the version somewhere, and as a target is a standalone artifact there is in general not much one ca place such "shared" content, but for updates its actually not a big deal, just select the location and press the "Update" Button in the target editor so you will get the latest version.

Question 1: Are properties/variables supported for Maven locations in a Target Definition?

Not yet, mostly because there is now UI for such support see for example:

• [target] Support user variables inside targets eclipse-pde/eclipse.pde#204

Question 2: Would it be possible to do the repackaging in plain Maven so the Target Definition is not required?

In general you can use any technique you like, e.g. bnd-maven-plugin, tycho "wrap" feature and alike but the most sustainable way is to ask the project to add (proper) OSGi headers in the first place.

Although I then don't know directly how to build the features. But one step after the other

Features are usually not required for thrid party dependencies, neverless m2-targets also support generating a feature from the content.

[fipro78]

@laeubi Do you have an example on how to use the bnd-maven-plugin to add the OSGi headers on an existing jar?

[laeubi]

Sadly last time I tried it was utterly complex, and basically involves:

1. create a maven project with the jar to wrap as dependency
2. use copy-dependencies
3. either include the jar on the Bundle-Classpath or unpack it
4. repack it with maven-jar and bnd-process goals

At least felix offers something out-of-the-box:

https://felix.apache.org/documentation/_attachments/components/bundle-plugin/wrap-mojo.html

but then still you need to make this available (e.g. with thatch artifact goal), in the end maven-target locations are much more comfortable and integrated (e.g. in the PDE) so I actually have only two cases:

1. I use maven-targets
2. I build the project from source and add a manifest in the first place.

Also keep in mind that adding manifest to existing jars has always the potential to confuse people.