499979: Deployment of nested plans fails
Originally, if a top-level plan referred to another plan the deployment
of the top-level plan would fail because the tooling did not take into
account the nested plan when deploying the top-level plan.
Now nested plans are supported:
- JmxServerDeployCommand parses the top-level plan to look for
references to nested plans
- If found, nested plans are copied to the stage directory before
deploying the top-level plan
Implementaiton details
----------------------
The code tries to deal with the case that plans are distributed across
the workspace in multiple projects. If the top-level plan is contained
in a Java project and such Java project depends on other Java projects,
the project dependencies will be scanned in the proper class-path order
when looking for nested plans and in case of duplicates, the first
matching plan found in the cass-path will be used.
If the project containing the top-level project is not a Java project,
nested plans will be searched only within the top-level project.
While the tooling do their best to support plans, please not that the
above only accounts for the most typical use cases and that certain
corner cases won't be optimally managed. For example, if a nested plan
is changed the server will not be able to detect this and auto-publish
the nested plan and refresh the top-level plan. The user who changed the
nested plan will have to un-deploy and re-deploy the top-level plan to
see the change. The modified nested plan will however be picked at the
next server restart.
This limitation exists because currently the Tools do not create a WST
module for the whole project containing the plan, but rather a WST
module for the plan file only. This design choice implies that the WST
infrastructure will be tracking workspace changes related to the
top-level plan file only. To change this behavior a significant rewrite
would be required and the effort is in my opinion not worth the benefit.
9 files changed
