Support for service dependencies still needs to be added. Also, some performance work needs to be done, particularly around the repository implementations. I'm not sure these are reasons not to include it in the build, however, and I am not against the idea. I think we may also want to hear status from Mark, who was working on bulking up the itests project (e.g., is everything currently passing?).
John > Graham Charters <[email protected]> > 07/20/2012 08:00 AM > > Please respond to > [email protected] > > To > > [email protected], > > cc > > Subject > > Re: How to generate SUBSYSTEM.MF with maven? > > 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 >
