ATC currently supports several ways of referring to EPackages. First, by nsURI that is checked against the local Package Registry, which delegates upon EMF's global registry. Second, packages may be directly referenced inside the transformation. Third, Packages used and referenced in other transformations may be imported via 'importedPackagesFrom : AtcTransformation'. Fourth, Packages may be entirely defined inside the Transformation. Fifth (new), Packages assigned to local variables may be dynamically registered via AtcAccessContext -> registerPackage. This last method allows us to assemble Packages at runtime and register them on the fly.
All these methods do not account for the possibility of choosing a custom model/package registry as a starting point. Concerning this feature request, here is an exhaustive excerpt of the suggestion made:
I've been trying to work out what 'should' happen using the JVM as an example.
Suppose we had a facility to execute ATC code as an applet. Everything that could not be locally resolved would be provided remotely. So a meta-model should be provided on the 'classpath' which should be extensible. This suggests that the ATC command line should support specification of 'jar's (registries) or individual 'class' files (the ecores).
ATC files should reference models in a portable fashion (URIs not file://C:/...) just as they do.
Considering a hypothetical invocation of the ATC VM standalone as
atc
-tx tx.atc
-registry C:\...\.settings\org.eclipse.qvt.declarative.modelregistry
-scope tx\tx.qvtr
-scope tx\tx.qvtc
-in:uml C:\...\model\MyModel.uml
-out:rdbms C:\...\model\MyModel.rdbms
-mm C:\...\model\umlMM.emof
-mm C:\...\model\rdbmsMM.emof
The ATC VM should resolve URIs references against:
a) explicitly provided -mm files umlMM.emof rdbmsMM.emof loaded into ATC's packageRegistry
b) against registration applicable to -scopes tx.qvtr then tx.qvtc then tx.atc
c) against plugin regististrations in the global package registry
An auto-generated ATC invocation will probably use mechanism a) to pass on what it knows.
A manual ATC invocation will probably use mechanism b) to set things up just once for the project containing one of the scopes.
A stable production environment may find c) alone adequate.
Code to support b) using the Model Registry's URI accessor space would be something like
ProjectHandle projectHandle = ModelFileResolver.createProjectHandle(registryFileName);
AbstractModelResolver modelResolver = new ModelFileResolver(projectHandle, scopeFileName);
to configure and possibly
modelResolver.setResourceSet(atcResourceSet)
to enforce reuse of your resource set and then
Resource resource = modelResolver.getResource(uri, true);
to attempt a resolution.
If working within Eclipse the first line can change to
ProjectHandle projectHandle = new EclipseProjectHandle(eclipseProject);