In theory the compiler generates OSGi metadata inside the .cars, but apparently that's sometimes not good enough, and so @davidfestal has some rubbish additional build step that unzips .cars and edits their META-INF files. And then apparently repository generation is a whole separate manual thing. What a mess.
Instead, I propose that we have a separate assembly command that produces an OSGi repository in one of the layouts listed here, containing .jar files with the needed OSGi metadata.
To be clear: I want to see the whole job of assembling an OSGi "application" or "plugin" automated and no more of this manual futzing around with Ant files or Maven or any of this rubbish that has been going on for years now.
@davidfestal We'll need you to properly define the requirements here.
In theory the compiler generates OSGi metadata inside the
.car
s, but apparently that's sometimes not good enough, and so @davidfestal has some rubbish additional build step that unzips.car
s and edits theirMETA-INF
files. And then apparently repository generation is a whole separate manual thing. What a mess.Instead, I propose that we have a separate assembly command that produces an OSGi repository in one of the layouts listed here, containing
.jar
files with the needed OSGi metadata.To be clear: I want to see the whole job of assembling an OSGi "application" or "plugin" automated and no more of this manual futzing around with Ant files or Maven or any of this rubbish that has been going on for years now.
@davidfestal We'll need you to properly define the requirements here.