On Fri, Apr 8, 2011 at 5:08 AM, Carsten Ziegeler <[email protected]> wrote: > Hi, > > I think we really have a great way of bundling a Sling application with > the current launchpad Maven plugin and the builder project. > > But :) I think it makes sense to talk about the next version of this. > I hope this describes the current situation briefly: > > - you create a builder project with a list.xml > - list.xml contains the bundles / artifacts to be included together with > their start level > - pom.xml invokes the launchpad plugin for the wanted artifacts > - it's possible to add additional bundles in pom.xml > - it's possible to exclude bundles in pom.xml > - it's possible to deploy the bundle list as an artifact into the repo > - it's possible to include one bundle list artifact > - As the dependencies are not in the pom and handled by the launchpad > plugin, these dependencies are not visible to Maven and the dependency > tree calculation does not include the listed bundles. > - The final bundle list is not available for other plugins
I think this all basically correct, except for the last point (which I'll come to below). > > Now, my wishlist for the next version is: > a) it should be possible to include several bundle list artifacts The way I've started to think about this is as a "mixin". I think you still want a base list somewhere (what we currently call launchpad.builder) and then add additional "sets" of bundles on top of this. > b) additional bundles and excludes should be defined in the same file as > the initial list of bundles I agree that the current exclude syntax in the POM is awkward, but I don't know about it being in the same file as the bundle list. Perhaps this could be a "negative mixin"? What I'd prefer to avoid is that the input to the plugin is different than the output. Things like includes and excludes are only inputs to the plugin and aren't relevant for downstream projects. All a downstream project wants to know is what the base bundle list is, not how that bundle list was created. > c) the exception for the above rule is of course if a final produced > artifact from the launchpad has such excludes/includes, e.g. the Karaf > artifact has special excludes - that's fine if they're defined at a > different location > d) it would be nice if the bundle list is visible to the Maven > dependency resolution > e) the final bundle list should be available for other plugins - this > could be as easy as writing out the complete list in the target > directory. For example I've a maven plugin creating a complete source > tree of all included bundles etc. Pretty sure this already happens if the bundle list is going to be installed to the (Maven) repository. The final list is in target/bundleList.xml. That said, if there were going to be other plugins using the bundle list (or whatever we rename it to), I would prefer we made a bundle list API (really just an object model) available and then store the final list in some immutable form in the Maven Session. > f) support for other artifact types than bundles - I want to have a > single place where I write down all artifacts bundled into the launchpad > artifact, this might be configurations, war files etc. Our Sling OSGi > installer supports all of this. Despite the fact that the bundle list is called the *bundle* list, it is really just an artifact list. WARs should already work. In terms of configuration files (or others), perhaps we could just add a "resources" section at the same level as "startLevels". This would likely need to support single files or ZIP files which were extracted before being included in the launchpad artifacts. Justin > > I guess from this list d) is the hardest - in addition we need > additional metadata for artifacts like the bundle start level which we > can't simply add in the pom.xml. > So I think we should forget about d) (unless someone knows how to do > it), and define everything in a single xml file. > > One way would be, to use something like the following xml > <launchpad> > <includes> > <!-- Add list artifacts here, together with exclusions -> > </includes> > <bundles> > <!-- the same as the current list.xml --> > </bundles> > <resources> > <!-- additional resources --> > </resources> > </launchpad> > > This is processed by the plugin and the expanded list is written into > the target directory. > > Maybe we should also add a version information for the xml format. And > we could make this compatible by looking at the root element name - if > it is "bundles" its the old format - if not, new format. > > Oh, and we could also add a section for the launchpad base artifact > here, so we have everything in one place. > > Just a rough idea - wdyt? > > Regards > Carsten > -- > Carsten Ziegeler > [email protected] >
