I have been playing around with plan referencing other plans.
I was able to deploy a plan that references another plan. So far so good.
I also experimented with trying to see what happens when either outer or inner plan are scoped. One note: inner plan atomic setting did note make a difference in behavior.
1. Outer scoped = true, Inner scoped = false
Both plan deploy. Outer plan artifacts of type = bundle are deployed within synthetic.context. Inner plan artifacts = bundle are deployed outside of that synthetic.context.
This means that services published by outer plan are never seen by inner plan.
2. Outer scoped = true, Inner scoped = true
Outer plan is deployed with synthetic.context. Inner plan scoped attribute looks to be ignored. Plan deployed as unscoped plan. Services from outer plan are not visible to inner plan.
3. Outer scoped = false, Inner sopped = false
Deploys fine. Services are visible across (cause nothing is scoped). Hibernate usage is broken understandably ( class not visible error).
4. Outer scoped = false, Inner sopped = true
Deploys fine. Services from outer plan are visible in inner plan. Issues with hibernate (understood why).
Inner plan create a synthetic.context bundle, but bundles from inner plan are not prefixed/rewritten with synthetic.context prefix in BSN.
Also inner plan synthetic.context bundle is generated without a version in it.
Usually when plan is scoped, I see <plan.name>.plan-<plan.version>-<plan.name>.plan-synthetic.context,
but with inner scoped plan it ends up:
We are trying to partition up our application vertically and then horizontally. We have seen some success with Slices.
We have developed a set of common components than includes a host web app and one slice (A).
We are now in process of developing a second slice (B) that will depend on some components of A and transitively on common components.
It would have been a great feature to have plans within plans in this situation where scope of the plan is determined by the outermost plan.
Scope would allow us to use ORM tooling and create composite applications from re-usable set of plans.
I heard that plans within plans are not something planned for 2.0 release at SpringOne.
So now to the questions:
Given that I have a set of "common" bundles, and multiple combination or sliced application (that themselves made up of number of bundles), what would be an approach to deployment? Restriction is usage of Hibernate or any ORM for that matter across slices, i.e. Slice B code can extends Slice A code for entity persistance. This forces us to use scoped plans.
I am planning to do multiple plans for each possible combination. Thankfully we won't have more than 5-6 combination of plans initially.