Hi,
On Fri, Apr 8, 2011 at 1:18 PM, Carsten Ziegeler <[email protected]> wrote:
> 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?
Basically, yes. We end up basically with two types of bundle lists.
The first is what we have now - a complete list of bundles which
constitue and application (we have this already). The second is a
partial list which I'm referring to as a mixin. Your application is
composed of one complete lists and zero or more mixin lists.
The key thing is that a mixin need not be runnable by itself whereas a
complete list ("base" list might be a better name) is runnable.
I'm not sure how mixins work with configurations/resources. Especially
with respect to subtracting mixins. Can you remove resources? (do you
need to?) I guess so, but that might be a little hard to describe this
effectively.
>
>> 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)
This is pretty easy to do, but you could also use the
maven-inherit-plugin
(http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/) to
write a new mojo which extends from AbstractBundleListMojo.
Justin
>
>>> 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]
>
