Hi Graham, I played with it for a little while, and first of all: nice work :)
But I do have some comments/requests/questions: I used the integration test combined with the eba-maven-plugin docpage as my documentation assuming that no documentation is available yet. * I found the following in the integration test: <extensions>true</extensions> <configuration> <includeJar>false</includeJar> </configuration> And am curious what the above configuration does. Or is it a leftover from the maven-bundle-plugin? * <subsystemManifestFile>src/main/custom/SUBSYSTEM.MF</subsystemManifestFile> Why not use the maven convention way of things. Let's say if there is a SUBSYSTEM.MF in src/main/esa/OSGI-INF/SUBSYSTEM.MF it will be used... * I didn't specify a Description in my pom, which resulted in Subsystem-Description: null in the SUBSYSTEM.MF. Better to omit it I would say :) * One pedantic comment: The integration test has version 1.0. You probably don't want that given that this isn't a release. BTW why is it called it0070? And yes, overriding headers and specifying start-orders would be awesome, in fact I can't use it for my CXF-DOSGi subsystem until start-orders are supported... Thanks! David On 20 July 2012 14:00, Graham Charters <[email protected]> wrote: > I'd like to hear John's thoughts on Subsystem's being hooked in, but > given where I believe it is, I would be in favour of doing that. > > Regarding the esa-maven-plugin, I think it's relatively harmless, so > could be hooked in. Maybe we should let someone give it a try first? > > Regards, Graham. > > On 20 July 2012 13:21, David Bosschaert <[email protected]> wrote: >> Thanks Graham, I'll have a look at it soon. >> >> David >> >> On 20 July 2012 11:11, Holly Cummins <[email protected]> wrote: >>> Cool! That will be really useful. Do you think it - and the rest of >>> the subsystems stuff, in fact - should be hooked into the main build? >>> >>> Holly >>> >>> On Fri, Jul 20, 2012 at 10:03 AM, Graham Charters <[email protected]> >>> wrote: >>>> I've just committed a first attempt at a esa-maven-plugin. It largely >>>> does what the eba-maven-plugin does for OSGi Applications, but for >>>> Subsystems. The implementation's based of the eba-maven-plugin. I >>>> tidied things up a bit, removed deprecated configuration options, and >>>> added support for the Subsyste-Type header which doesn't exist for >>>> ebas. There are a few things it doesn't support that it would be good >>>> to add: >>>> 1. Custom headers - in the <instructions> configuration element >>>> 2. Version ranges for the content dependencies (i'd thought about >>>> doing these based on maven dependency version ranges. alternatively, >>>> we could just have a version policy configuration option that then >>>> calculates the ranges (e.g. fixed, minor, mjaor). >>>> 3. Start-order for contents (this should be relatively easy to add if >>>> based on the order of the dependencies (or at least the order they're >>>> presented to the mojo, which is hopefully the same)). >>>> 4. Probably a whole load of other features :) >>>> >>>> Please give it a try and let me know how it goes. I'd suggest looking >>>> at the documentation for the eba-maven-plugin to get started. >>>> >>>> Regards, Graham. >>>> >>>> On 19 July 2012 12:57, Graham Charters <[email protected]> wrote: >>>>> Sorry, I missed this thread the first time round. David is right, the >>>>> eba-maven-plugin is the best place to start. It does also handle >>>>> versions using the shared maven2osgiconverter (also used by the bundle >>>>> plugin). >>>>> >>>>> I'll have a go at an esa-maven-plugin over the next few days. >>>>> >>>>> Regards, Graham. >>>>> >>>>> On 2 July 2012 13:38, Felix Meschberger <[email protected]> wrote: >>>>>> Hi, >>>>>> >>>>>> Am 02.07.2012 um 12:22 schrieb David Bosschaert: >>>>>> >>>>>>> Hi Felix, >>>>>>> >>>>>>> On 2 July 2012 11:13, Felix Meschberger <[email protected]> wrote: >>>>>>>> Am 01.07.2012 um 22:06 schrieb David Bosschaert: >>>>>>>>> 2. The Subsystem-Content lists all the dependencies of the project. >>>>>>>>> However, because some of the bundles for this subsystem weren't >>>>>>>>> developed with OSGi in mind, the start ordering is significant. I >>>>>>>>> don't know of an easy way to generate this so currently it's hardcoded >>>>>>>>> and hence duplicated. Also note that fragments obviously don't have a >>>>>>>>> start-order. >>>>>>>> >>>>>>>> Just wondering: How could start order be forced in OSGi ? >>>>>>>> >>>>>>>> IIRC there is no such thing as start ordering because such an order >>>>>>>> can never be guaranteed -- start levels only help to a certain degree. >>>>>>> >>>>>>> The start-order is an attribute defined in the Subsystems spec section >>>>>>> 134.12.1. It simply defines the order in which the bundles are started >>>>>>> within that subsystem. >>>>>> >>>>>> I see, thanks. >>>>>> >>>>>> Regards >>>>>> Felix
