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:
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.