Deployment with plan file

[vladimir.glushak]

I have an issue with deployment my application with plan file.
My application consist of few bundles. Some of them are third party jars that I manually bundled, because did not find it in EBR.
For example oracle jdbc driver 11. My oracle bundle starts before plan file resolving, because there are some optional dependencies in springframework.jdbc bundle to it.
Therefore, my application resolving with plan fails. (Oracle bundle is duplicated and Framework$DuplicateBundleException exception raised).
Of course I can remove oracle bundle from plan file, but it break the integrity of my application.
How to solve this problem correctly? Where can I read about best practice of deployment approaches onto Spring dm server for enterprise applications?

[Glyn Normington]

dm Server 2.0.x has a restriction that plan content must not have already been installed by another plan or some other process. The complex case this is intended to avoid is where multiple plans overlap in content, which complicates various scenarios and was too much to bite off in 2.0.x.

One way to preserve the integrity of your plan and still maintain correct operation may be to invoke your plan earlier in startup. The user region is created with no bundles installed and then the property with default value:

initialArtifacts=repository:plan/com.springsource.kernel.userregion.springdm, repository:plan/com.springsource.server.web

in config/com.springsource.kernel.userregion.properties defines what is installed first. So if you add your plan into the list in this property before the xxx.springdm plan, you'll "get in" before the Spring bundles are resolved in the user region.

If your application depends on Spring DM for its initialisation, then initialisation will be deferred until the Spring DM extender is started. If this is a problem, you may need to play things a little differently and break your plan into a 3rd party dependencies piece (which does not depend on Spring DM for its initialisation) and an application piece (which does depend on Spring DM for its initialisation). Then the 3rd party plan can be installed before xxx.springdm and the application piece can be installed after xxx.springdm.

There is not much in the way of documented best practices for using plans in dm Server. I would say that it is good practice to structure plans into meaningful units and to compose these into higher level plans. So the split between 3rd party dependencies and application could be one way of structuring your overall plan.

Of course, dm Server's normal mode of operation is that 3rd party dependencies are automatically provisioned from the repository and so, in general, deployed plans need only contain the application piece minus the dependencies.

This general scheme may not be suitable in all circumstances. For example, if the dependencies are via services rather than packages, then they will not be auto-provisioned. Also, in some scenarios auto-provisioning dependencies may not perform well and it may be necessary to deploy some or all dependencies explicitly, probably in a plan.