Savara 2 : How to manage dependencies for validation
In a previous thread (http://community.jboss.org/thread/153044?tstart=0) I introduced the idea of a project descriptor (called TIA in the thread), that has been partially implemented in Savara 1.1.
The role of this project descriptor, within an Eclipse environment, was to manage information about a testable architecture project, and in particular define relationships between the artifacts associated with different phases of the project. These relationships could potentially have additional information that would help refine the nature of the relationship.
The main reason for providing this information in Savara 1.1 was to support validation of artifacts against each other.
In the discussion thread we touched on the pros and cons of just storing this dependency information in a repository. The main downside was that if this information was only stored in the repository, then validation could only occur when changes had been submitted back to the repository. So the TIA project descriptor (or TAP as it became known) was the proposed solution - the idea being that it would hold this dependency info in an Eclipse environment, and be sync'd up with the dependency info in the repository.
On reflection, this solution is designed around the idea that the Eclipse environment is primary, with the repository being subserviant. However in reality the repository is king, and the Eclipse environment is a temporary working area used to work on subsets of the artifacts in the repository. There is no guarantee where the artifacts from the repository will be placed in the Eclipse environment, whether they will span across Eclipse projects, or whether all of the required artifacts will be 'checked out'. For example, a user may just wish to make minor changes to a BPEL process, and so just download the process file, without any of its dependencies (wsdl and xsd files).
The reason for starting this thread is that with the focus on Savara2, we need to consider how to support the management of dependencies and validation of resources, when dealing with Eclipse and non-Eclipse based environments. The other reason is that there is renewed activities in terms of a repository project, and therefore this is a good time to feed in requirements if appropriate.
So a possible suggestion (not sure if technically feasible) would be:
1) When an artifact is checked out of the repository, into an Eclipse environment, it stores the dependency information to other artifacts. The other artifacts being identified by some unique identifier. It should also be possible to retrieve an artifact and its direct dependencies in one operation.
2) When the artifact is modified, and validation is triggered, it should be possible to:
a) if the related resource is locally available, the validation will be performed and results reported in the Eclipse problem view
b) if the related resource is not locally available, but the repository is accessible, then validation could be performed against the remote artifact (should be user configurable in case incurs significant performance hit)
This has the benefit that:
- artifacts can be stored in any location within the Eclipse workspace and still be used (requires the Eclipse environment to keep track of repository based artifacts based on id)
- its possible for a user to work offline and still have the validation of resources that are stored locally
Side note: this may also require the Eclipse/repository integration to be able to examine an existing file within the Eclipse environment, e.g. a WSDL file, and determine that it is identical to a file in the repository, and therefore associate the repository artifact's id and dependency info with the local Eclipse based file. Need to consider how equivalence is determined, possibly each artifact type needs to provide a mechanism for determining this, and how to handle the situation where multiple copies of the same artifact exist in the repository - possibly need to store multiple ids against the Eclipse file.
A potential downside is that this approach would make Savara dependent upon this new repository project, instead of being agnostic (which was the original intention). However using a ModeShape based repository would mean that any other repositories an organisation may have can be federated - thus achieving the same result indirectly.
Any thoughts welcome.
Regards
Gary