On Fri, Apr 8, 2011 at 9:25 AM, Justin Edelson <[email protected]> wrote: > 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.
On second thought, this might not work. I forgot that the Maven Session can only carry string properties from plugin to plugin. I'll look at this some more over the next few days. > >> 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] >> >
