A blueprint is a dependency injection framework for OSGi bundles. It could be written by hand or generated using the Blueprint Maven Plugin. A blueprint file is just an XML file describing beans, services, and references. Each OSGi bundle could have one or more blueprint files.

Blueprint files represent the architecture of our bundle. Let's visualize it using Groovy and graphviz, available in my GitHub repository and analyze.

Example Generation

All you need is Groovy and graphviz installed on your OS. I am working mostly with bundles with generated blueprints, so I will use a blueprint file generated from Blueprint Maven Plugin as an example. All examples are included in the GitHub repository.

Generation could be invoked by running run.sh with a given destination file prefix (in this case, a PNG extension will be added to it) and the path to the blueprint file:

mkdir -p target

./run.sh target/fullBlueprint fullBlueprint.xml

The visualization is available here, or you can click on the thumbnail below to enlarge it. 

Separating Domains

First, if you look at the image, you see that some beans are grouped. You could easily extract such domains with tree roots: beanWithConfigurationProperties and beanWithCallbackMethods to separate blueprint files and bundles in the future and generate images from them:

./run.sh target/beanWithCallbackMethods example/firstCut/beanWithCallbackMethods.xml
./run.sh target/beanWithConfigurationProperties example/firstCut/beanWithConfigurationProperties.xml
./run.sh target/otherStuff example/firstCut/otherStuff.xml

Now we have three slightly cleaner images: beanWithConfigurationProperties.png, beanWithCallbackMethods.png and otherStuff.png.

We also could generate images from more than one blueprint:

./run.sh target/joinFirstCut example/firstCut/otherStuff.xml example/firstCut/beanWithConfigurationProperties.xml example/firstCut/beanWithCallbackMethods.xml

And the result is here. (That's another big one. Click on the link to see the image.) The image contains beans grouped by file, but if you do not like that, you could force generation without such separation using --no-group-by-file:

./run.sh target/joinFirstCutGrouped example/firstCut/otherStuff.xml example/firstCut/beanWithConfigurationProperties.xml example/firstCut/beanWithCallbackMethods.xml --no-group-by-file

It will generate an image with all beans from all files.

Exclusion

Sometimes, it is difficult to spot and extract other domains. It will be easier to do some experiments on a blueprint. For example, bean my1 is a dependency for too many other beans. You could consider converting my1 to an OSGi service and extracting it to another bundle.

Let's exclude my1 bean from generation via -e and see what happens:

./run.sh target/otherStuffWithoutMy example/firstCut/otherStuff.xml -e my1

The result is available here. Now we see that trees with root bean myFactoryBeanAsService could be separated and my1 could be injected to it as an OSGi service in another bundle.

You could exclude more than one bean adding the -e switch for each of them, for example, -e my1 -e m2 -e myBean123.

Conclusion

Blueprints are great for dependency injection for OSGi bundles, but it is easy to create a big context containing many domains. It is much easier to recognize or search for such domains using a blueprint visualizer script.