Using Epsilon with CDO [message #1856457] |
Mon, 12 December 2022 01:02 |
|
I am trying to set up a workflow for Epsilon to operate on CDO. I have a resource and a model URI. The code below uses a resource URI and completes with loading and validation. But when I attempt to list content or access any types, I get the error below. One would assume that the type ModelElementType is known. Or is there any other way to see if there is content and what it is?
Buildfile: /home/jg/eclipse-workspace/read-from-cdo/build.ant
loadModel:
[epsilon.eol - listResources.eol] EXCEPTION: Undefined variable, type or model: 'ModelElementType'
<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="loadModel">
<target name="loadModel">
<epsilon.emf.loadModel name="source"
modeluri="cdo.checkout://2/resource2"
read="true"
store="false"
validate="true" />
<epsilon.eol src="listResources.eol">
<model ref="source" />
</epsilon.eol>
</target>
</project>
ModelElementType.all().println();
|
|
|
Re: Using Epsilon with CDO [message #1856458 is a reply to message #1856457] |
Mon, 12 December 2022 01:07 |
|
Using the URI of the root object instead of the resource, it fails the execution when loading the object as follows:
Buildfile: /home/jg/eclipse-workspace/read-from-cdo/build.ant
loadModel:
BUILD FAILED
/home/jg/eclipse-workspace/read-from-cdo/build.ant:11: java.lang.IllegalArgumentException: Name is null is null
Total time: 84 milliseconds
|
|
|
|
Re: Using Epsilon with CDO [message #1856477 is a reply to message #1856459] |
Mon, 12 December 2022 23:11 |
|
Hello,
I'd recommend trying the EMC CDO driver on EpsilonLabs. You should be able to use it from ANT as follows but if it gives you any trouble, please let us know.
<epsilon.loadModel name="M" type="CDO">
<parameter name="cdo.url" value="..."/>
<parameter name="cdo.repo" value="..."/>
<parameter name="cdo.path" value="..."/>
</epsilon.loadModel>
Thanks,
Dimitris
[Updated on: Mon, 12 December 2022 23:12] Report message to a moderator
|
|
|
Re: Using Epsilon with CDO [message #1856486 is a reply to message #1856477] |
Tue, 13 December 2022 07:48 |
|
Thank you! That works very well. I did not think to check the lab. Does this driver also allow to install a dynamic metamodel by uploading an Ecore resource? I have done that using the GUI, but would like to use Epsilon tooling. Given the issues with the Flock enum copy I think that approach is not going to work. Is there another way to perform a copy from one container to another?
|
|
|
Re: Using Epsilon with CDO [message #1856487 is a reply to message #1856486] |
Tue, 13 December 2022 08:28 |
|
Hi Joern,
The current version of the EMC CDO driver assumes the EPackage already resides in the CDO package registry. Looking at the CDO codebase, I think that CDO exposes a CDOPackageRegistryPopulator class that we could perhaps piggyback on.
Would it make sense to add a configuration section to the CDO driver where you can enter a list of EPackage URIs from your local registry, and have those automatically populated in CDO if they are not there already?
Best,
Antonio
|
|
|
Re: Using Epsilon with CDO [message #1856488 is a reply to message #1856487] |
Tue, 13 December 2022 08:43 |
|
I think that would be excellent. And in the long run maybe a validation to see that the two are consistent. Unfortunately reusing the same URI for different MMs is still a practice that is way to common.
|
|
|
|
Re: Using Epsilon with CDO [message #1856491 is a reply to message #1856489] |
Tue, 13 December 2022 09:33 |
|
Hi Joern,
I found out that CDO will actually register EPackages for you upon committing the transaction, if there is an EObject conforming to an EClass whose EPackage has not been registered yet. There was a thread about this in the CDO forum:
https://www.eclipse.org/forums/index.php/t/158032/
I have pushed a new 1.0.1 release of the EMC CDO driver that will piggyback on the global EPackage registry if a given type cannot be found in the CDO package registry. When you save the model, this will automatically populate the CDO package registry as needed using dynamic EClasses. We're reusing existing CDO behaviour here, so it should hopefully work well across CDO versions.
The good part of this approach is that no extra configuration is needed: just make sure that the given type is in your global package registry (the one in EPackage.Registry.INSTANCE).
I have also created a small toy example for this driver, including a dynamic metamodel (the Tree.ecore metamodel from the Epsilon examples):
https://github.com/epsilonlabs/emc-cdo/tree/master/org.eclipse.epsilon.emc.cdo.example
Best,
Antonio
|
|
|
Re: Using Epsilon with CDO [message #1856516 is a reply to message #1856491] |
Wed, 14 December 2022 00:38 |
|
Hi Antonio, there is a catch, see below. In our case we are using dynamic models, not CDO-aware Java generated ones. This means the side-effect generation that CDO-specific code performs does not happen. Seems that CDOPackageRegistry allows remote writing and reading of the remote registry. I am unsure what happens if you already have a metamodel and then you call put and replace it? I hope it will simply throw.
As for the EMC I am have issues using it with a remote repository that uses branching. The documentation is not very clear. It feels like the checkout needs to be switched to the branch I am on. If that functionality is not available, then the branching and audit modes of CDO cannot be used. I guess that would be a fairly common usecase for CI, as that sort of stuff always operates on branches or at least versions. Thoughts?
Quote:
Rencana,
AFAIK, EPackages are registered (committed to the repository) in the
first attempt to commit a CDOObject that is instance of any of the
elements in the EPackage.
So you only need a CDO-aware model, create instances and commit them in
a CDOTransaction. The EPackage shall be committed automatically.
|
|
|
|
Re: Using Epsilon with CDO [message #1856518 is a reply to message #1856517] |
Wed, 14 December 2022 01:33 |
|
Some experimentation shows that
- The ePackage registry is global and shared
- It is write once, read multiple
- Upon UI upload, locally registered packages are transferred if the identifiers do not match
- Packages can be registered through the session by selecting from the ones known locally
|
|
|
|
Re: Using Epsilon with CDO [message #1856527 is a reply to message #1856520] |
Wed, 14 December 2022 07:44 |
|
Hi Joern,
The example project uses a metamodel from an `.ecore` file ("Tree.ecore"), which is not a Java generated one. In the thread I linked, the requirement was to use a CDO model (e.g. a CDO EResource implementation) - which the EMC CDO driver is using. Could you provide a minimal example to help me reproduce the issue you are having with the CDO driver?
As for branching, I think I just need to add one more configuration option to the driver. Hopefully that shouldn't be too difficult to add - I'll give it a go.
Best,
Antonio
|
|
|
Re: Using Epsilon with CDO [message #1856530 is a reply to message #1856527] |
Wed, 14 December 2022 09:15 |
|
Hi Joern,
I have just pushed a new 1.1.0 version of the EMC CDO driver which adds support for branching. The one caveat is that CDO uses paths for branches, rather than outright names - therefore, if you start "branch1" from the main branch, you'll have to use "MAIN/branch1" instead of just "branch1".
In any case, if someone enters an incorrect branch name by mistake, the driver will print out an error message listing the paths to all the branches in the repository.
Best,
Antonio
|
|
|
Re: Using Epsilon with CDO [message #1856553 is a reply to message #1856530] |
Wed, 14 December 2022 22:06 |
|
Thanks! I just re-checked that the dynamic metamodel upload works as a side-effected as indicated. If the MM already exists, CDO seems to give error messages that are challenging to interpret. I will put that in notes for our UseCase. I will next have a look at the branches.
|
|
|
|
Re: Using Epsilon with CDO [message #1856559 is a reply to message #1856556] |
Thu, 15 December 2022 10:11 |
|
That's great! We could look into those CDO error messages, if you give us a sequence of steps to reproduce them?
I've started writing some automated tests for the driver - hopefully we can graduate the CDO driver into the main Epsilon repository soon, once it's sufficiently covered in tests.
|
|
|
Re: Using Epsilon with CDO [message #1856572 is a reply to message #1856559] |
Thu, 15 December 2022 19:11 |
|
I've got a first full version of a test suite for the driver now, and it found a few bugs in deleting instances and creating new ones. In fact, I've changed the driver to proactively register metamodels before trying to create an instance of a type that is not currently in CDO, to ensure we get the same behaviour when creating the first instance of a type and later instances.
I have updated the emc-cdo update site with a new 1.1.1 version of the EMC CDO driver which passes all the new tests now. This will most likely be the last release from this repo: I'll start moving it to the main Epsilon repo soon.
|
|
|
Re: Using Epsilon with CDO [message #1856576 is a reply to message #1856572] |
Thu, 15 December 2022 22:15 |
|
Very nice. Some doco will be requried, as there are some edge cases in suite it seems:
flockDiscardsFactory:
[epsilon.flock] EXCEPTION: Flock can only be used with models that implement IReflectiveModel. target does not.
[epsilon.flock] at org.eclipse.epsilon.flock.execute.context.FlockContext.wrapModel(FlockContext.java:73)
[epsilon.flock] at org.eclipse.epsilon.flock.execute.context.FlockContext.addAndWrapModel(FlockContext.java:62)
[epsilon.flock] at org.eclipse.epsilon.flock.execute.context.FlockContext.setMigratedModel(FlockContext.java:54)
[epsilon.flock] at org.eclipse.epsilon.workflow.tasks.FlockTask.initialize(FlockTask.java:32)
[epsilon.flock] at org.eclipse.epsilon.workflow.tasks.ExecutableModuleTask.executeImpl(ExecutableModuleTask.java:256)
[epsilon.flock] at org.eclipse.epsilon.workflow.tasks.EpsilonTask.execute(EpsilonTask.java:42)
<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="flockDiscardsFactory">
<target name="flockDiscardsFactory">
<epsilon.emf.loadModel name="source"
modelfile="wakeup.model"
metamodelfile="Flowchart.ecore"
read="true"
store="false" />
<epsilon.loadModel name="target" type="CDO">
<parameter name="cdo.url" value="tcp://localhost:2036" />
<parameter name="cdo.repo" value="repo1" />
<parameter name="cdo.branch" value="MAIN/branch1" />
<parameter name="cdo.path" value="wakeup.model" />
</epsilon.loadModel>
<epsilon.flock originalmodel="source" migratedmodel="target">
<model ref="source" />
<model ref="target" />
</epsilon.flock>
<epsilon.eol src="listActions.eol">
<model ref="source" />
</epsilon.eol>
<epsilon.storeModel model="target" />
</target>
</project>
|
|
|
Re: Using Epsilon with CDO [message #1856577 is a reply to message #1856576] |
Thu, 15 December 2022 22:18 |
|
I also found it confusing that I needed to specify references to the source and target models explicitly. Otherwise an exception is thrown saying that it cannot find them in the model repo. Seems redundant, as if you indicate that these are the original and the migration, you obviously want to use them.
|
|
|
|
|
|
Re: Using Epsilon with CDO [message #1856629 is a reply to message #1856609] |
Mon, 19 December 2022 16:04 |
|
Thanks :-D. The EMC CDO driver is now part of the main Epsilon distribution. You should be able to install it from the interim update site, by selecting the "Epsilon CDO Integration" features.
|
|
|
Powered by
FUDForum. Page generated in 0.04942 seconds