Justin Edelson wrote >> 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. Not sure :) I'm thinking of building blocks that are assembled to make my final application. For example, I would like to define a core or platform bundle list (containing scr, config admin etc.), maybe a workflow bundle list (containing everything you need for a workflow support) etc. and then I want to have my final application where I just say, ok, I want the platform, workflow support, etc. and here are my 5 app bundles.
> >> 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"? Hmm, ok, when you speak about mixins, you mean I define a number of bundle lists - each one going into an own project and then my final application is "just" the assembly of those mixins? > 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. Yes, exactly, my idea is: Project P1 has bundle list with bundles A, B, and C - Project P2 has a bundle list, include the list from P1 and adds bundles D, E, and F - but excludes B - then the bundle list of P2 is..ehm..A, C, D, E, and F. It is not visible that there have been excludes, or a include from P1 - just a plain list. The next project using the list from P2 just includes it and gets what it wants. > > 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. Ok, I just saw your second mail - but nevertheless an API would be nice (a separate artifact) which I could just include in my plugin and that api reads the bundle list (or stores it somewhere in memory - whatever works) >> 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. > Resources (config files etc.) might go into a different directory than the bundles. Therefore I thought of the below XML. Regards Carsten >> >> 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] >> > -- Carsten Ziegeler [email protected]
