Possible non-specification extensions in aries blueprint

[Balázs Zsoldos]

Hi,

I am planning since a year to make some extensions concerning to the basic
blueprint functionality to be able to create more complex business logic
for bundles. Till now I have been busy therefore I planned to have the
features I want in July. One month late I can start the development.

A couple of months ago I wrote down what I would like to have at
https://www.osgi.org/bugzilla/show_bug.cgi?id=143 to let others writing
notes.

In summary:

I would like to have a function called createChildContainer() in the
BlueprintContainer interface. A container may have many children, they
build up a tree. A child sees the components of the parent.

Why would it be good?

More complex namespace handlers could be written that handle the
ManagedServiceFactory like this:

    <cm:managed factoryPid="com.acme.designate.factory"
componentIdPrefix="someUniqueAttributePid">
        <bean .... >
           <property key="a" value="${attributeName}"
        <bean>
        <reference ... />
        <service ... />

        <c:choose>
            <c:when test="${someAttributeId eq 'value'}">

                <reference ... />
                <bean  ... />
                <service ... />

            </c:when>
            <c:when test="${parent.parent.otherAttributeId eq 'value'}">

                 ...

            </c:when>
            <c:otherwise>

                 ...

            </c:otherwise>
        </choose>

    </cm:managed>

In my opinion a possibility like this with a namespace similar to the
Metatype XML structure would really give a boost to the blueprint
technology. In this case when someone designs a module the API and the
metatype interface should be designed together.

After checking the source a lot of Gemini and Aries I made the decision to
go in the aries way. Now I have two options:

   - Wrap the aries.blueprint.core in a custom bundle and extend with the
   possibility of having child blueprint containers
   - Creating a branch on GitHub and write the changes inside the source of
   aries blueprint classes

My questions would be:

   - Which way would you recommend?
   - In case of a Github branch do you see any chance that it will be
   merged into the trunk?
   - In case of wrapping option (where some copy paste and modification is
   done) do you see any chance to merge it into the trunk?
   - Is there anyone who things that this feature would be useful or
   useless?

In case there is less chance I would choose option two so first I wrap the
aries blueprint code. After a while if you like the solution you still have
the chance to take any code back by using simply a diff tool on the classes.

Regards,
Balazs Zsoldos