improve: generate OSGi headers

[rbraeunlich]

add plug-in and configuration to POMs so that a proper OSGi Manifest
will be generated

[rbraeunlich]

It would've been great if I could have used the bundle plug-ins default values, especially if this line wouldn't be necessary:
org.camunda.bpm.model_
Because that leads to *impl_ packages being exported. Unfortunately bpmn-model does require some impl classes from xml-model. Maybe you could create a JIRA issue to fix this dependency later.

[menski]

Hey Ronny,

thank you for your contribution. I'm really sorry that I missed the OSGi project. I merged your changes for the bpmn-model and will do so for the engine next.

I only have one question left. I'm not very familiar with OSGi and maven and would be happy if you can answer this.

To successfully run the engine-osgi test suite I had to declare the assertj import as optional in the xml-model which I did by adding the following section to the pom.xml of the xml-model:

<Import-Package>
  javax.xml.parsers,
  javax.xml.transform,
  javax.xml.transform.dom,javax.xml.transform.stream,
  javax.xml.validation,
  org.assertj.core.api;version="[1.5,2)";resolution:=optional,
  org.w3c.dom,
  org.xml.sax
</Import-Package>

So my question is this the right way to do it? Or is there a better way?

Thank you again for you help.

Cheers
Sebastian

[rbraeunlich]

Hi Sebastian,
it depends ;-)
I didn't change the engine-osgi tests yet, because I wanted to wait if you'd accept my pull requests. That way I wanted to ensure compatibility with alpha2 as long as the pull requests are open.
Locally I included the dependency when setting up the OSGi test environment.
To me it seemed like the validation stuff that depends on AssertJ is an essential part of the xml-model. If you thought of it more like an additional feature that's not neccessary for the engine to work then declaring it optional is the right way.
As you can see, it's up to you.

[menski]

Hi Ronny,

thank you for the clarification. The AssertJ dependency is only an internal of the xml-model. We used it to simplify our xml-model testing. But this custom assertions are not used elsewhere and I currently think they are not very useful outside of the xml-model. So we wanted to make them optional for the xml-model and not a real dependency.

So thanks again for your answer.

Cheers,
Sebastian