Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » NoSuchElementException while traversing CDOResource.getAllContents()(CDO EMF Migration)
NoSuchElementException while traversing CDOResource.getAllContents() [message #1741583] Fri, 26 August 2016 06:29 Go to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Hi there,

I'm currently working on the EMF/CDO-Migration started by Christophe Bouhier. One of the problems I encounter is the traversing of the element tree in the CDOResource.
What the code does is:
for (final TreeIterator<EObject> i = resource.getAllContents(); i.hasNext();) {
                    EObject eObject;
                    eObject = i.next();
                    //DO SOMETHING WITH THE EOBJECT
}


What I get is:
java.util.NoSuchElementException
	at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:713)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692)
	at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:473)
	at org.eclipse.emf.common.util.AbstractTreeIterator.next(AbstractTreeIterator.java:139)
	at migration.OwnStrategyForwardConverter.initElements(OwnStrategyForwardConverter.java:118)


The CDOResource is:
CDOResource@OID456[PROXY]("cdo.net4j.tcp://localhost:2035/REPO/resource")


Currently there are no options used while doing the
CDOResource.load(Map<?, ?> options)

Any idea what's going wrong?

Thanks in advance

Alex
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741594 is a reply to message #1741583] Fri, 26 August 2016 08:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
Hi Alexander,

Normally you wouldn't call CDOResource.load() directly. how are you loading the resource?

The NoSuchElementException most likely occurs because the resource contents are concurrently modified by another transaction. Please read this post to get an idea of how to protect your iteration against such concurrent updates.


Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741606 is a reply to message #1741594] Fri, 26 August 2016 09:16 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Hi Eike,

first of all: WOW for the very quick response! I try to upgrade my CDO version to the current CDO 4.5 (emf-cdo-R20160607-1209-Site) and check out the post you recommended. If it's not working I get back!

Cheers

Alex
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741671 is a reply to message #1741606] Fri, 26 August 2016 22:19 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Hi Eike,

after upgrading to CDO 4.5 and trying to understand the problem I removed the loading of the resource as I already had the proxied one in hand. But nevertheless the problem persists so here's what I do ( respectively the code of Christophe Bouhier does):

What I try to do is to read the contents of the resource to migrate them without having the generated model files (as they have evolved to a newer version and the CDO repo is still the old one).

First the code to obtain the view/transaction in org.eclipse.emf.edapt.cdo.migration.execution.EdaptCDOViewProvider:
public CDOView getView(URI uri, ResourceSet resourceSet) {

		final CDOURIData cdouriData = new CDOURIData(uri);

		final String repoName = cdouriData.getRepositoryName();

		IManagedContainer container = repoContainers.get(repoName);

		if (container == null) {
			container = new ManagedContainer();
			Net4jUtil.prepareContainer(container);
			TCPUtil.prepareContainer(container);
			container.activate();
			repoContainers.put(repoName, container);
		} else {
			for (final Object e : container.getElements()) {
				System.out.println(e);
			}
		}

		// TODO Base the connector on the schema.
		final String uriSchema = cdouriData.getScheme();
		System.out.println("EDAPT TODO: Schema requested is " + uriSchema //$NON-NLS-1$
			+ " base connector on this requested schema. "); //$NON-NLS-1$
		if (uriSchema.equals("cdo.net4j.tcp")) { //$NON-NLS-1$
			// Base connector on TCP.
		} else if (uriSchema.equals("cdo.net4j.jvm")) { //$NON-NLS-1$
			// Base connector on JVM.
			// Note, condition is a bundled which is server side.
			// consider checks for this.
		}

		// Produce a TCPConnector which respects all params like UserID, Port,
		// and Host.
		final IConnector connector = (IConnector) container.getElement("org.eclipse.net4j.connectors", "tcp", //$NON-NLS-1$ //$NON-NLS-2$
			cdouriData.getAuthority());
		final CDONet4jSessionConfiguration config = CDONet4jUtil
			.createNet4jSessionConfiguration();
		config.setConnector(connector);
		config.setRepositoryName(repoName);

		if (cdouriData.getUserName() != null
			&& cdouriData.getPassWord() != null) {
			final PasswordCredentials passwordCredentials = new PasswordCredentials(
				cdouriData.getUserName(), cdouriData.getPassWord()
					.toCharArray());
			final IPasswordCredentialsProvider credentialsProvider = new PasswordCredentialsProvider(
				passwordCredentials);

			config.setCredentialsProvider(credentialsProvider);
		}

		final CDOSession session = config.openNet4jSession();

		// Make sure the packages are emulated.
		session.options().setGeneratedPackageEmulationEnabled(true);

		// Get the package registry for this resource set and make sure
		// it is known in the repository. Note:
		// CDO will also populate from the global registry when?
		//
		final Registry packageRegistry = resourceSet.getPackageRegistry();

		boolean packagesAdded = false;
		if (!packageRegistry.isEmpty()) {
			final CDOPackageRegistry cdoPackageRegistry = session
				.getPackageRegistry();

			for (final String nsURI : packageRegistry.keySet()) {
				final EPackage packageToAdd = packageRegistry.getEPackage(nsURI);

				if (!cdoPackageRegistry.containsKey(nsURI)) {
					cdoPackageRegistry.putEPackage(packageToAdd);
					packagesAdded = true;
				}
			}
		}

		final CDOTransaction openTransaction = session.openTransaction(resourceSet);

		// Commit the added EPackages to the registry.
		if (packagesAdded) {
			try {
				openTransaction.commit();
			} catch (final ConcurrentAccessException e) {
				e.printStackTrace();
			} catch (final CommitException e) {
				e.printStackTrace();
			}
		}

		if (rootResourceRegistry.get(repoName) == null) {
			final CDOResource rootResource = openTransaction.getRootResource();
			@SuppressWarnings("unused")
			final URI uri2 = rootResource.getURI();
			rootResourceRegistry.put(repoName, rootResource);
		}

		return openTransaction;
	}


What I still had to do to prevent the following NPE was:
for (final EPackage pack : metamodel.getEPackages()) {
                      EPackage.Registry.INSTANCE.put(pack.getNsURI(), pack);
        }


not to get

java.lang.NullPointerException
	at org.eclipse.emf.cdo.internal.common.model.CDOPackageRegistryImpl.registerPackageInfo(CDOPackageRegistryImpl.java:287)
	at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.load(CDOPackageUnitImpl.java:246)
	at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.load(CDOPackageUnitImpl.java:228)
	at org.eclipse.emf.cdo.internal.common.model.CDOPackageInfoImpl.getEPackage(CDOPackageInfoImpl.java:125)
	at org.eclipse.emf.cdo.internal.common.model.CDOPackageInfoImpl.getEPackage(CDOPackageInfoImpl.java:118)
	at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:127)
	at org.eclipse.emf.cdo.common.model.CDOClassifierRef.resolve(CDOClassifierRef.java:114)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOClassifierRefAndResolve(CDODataInputImpl.java:171)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.readSystemValues(BaseCDORevision.java:210)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.read(BaseCDORevision.java:163)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDORevision(CDODataInputImpl.java:434)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDORevision(CDODataInputImpl.java:425)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readRevision(RevisionInfo.java:225)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:165)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:142)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:1)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequest.confirming(CDOClientRequest.java:97)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedInput(RequestWithConfirmation.java:125)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:105)
	at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:53)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
	at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:466)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:89)
	at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:75)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:605)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:638)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.loadRevisions(CDOClientProtocol.java:203)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:431)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:309)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:291)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:284)
	at org.eclipse.emf.internal.cdo.view.CDOViewImpl.getRevision(CDOViewImpl.java:907)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:1833)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:1661)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1498)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.convertIDToObject(AbstractCDOView.java:2140)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertIDToObject(CDOStoreImpl.java:897)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertToEMF(CDOStoreImpl.java:860)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.get(CDOStoreImpl.java:201)
	at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateGet(EStoreEObjectImpl.java:241)
	at org.eclipse.emf.common.util.DelegatingEList.get(DelegatingEList.java:230)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:705)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692)
	at org.eclipse.emf.common.util.AbstractTreeIterator.next(AbstractTreeIterator.java:133)


That I don't understand as the session was created using session.options().setGeneratedPackageEmulationEnabled(true). I thought this would reconstruct the package information in the repo from the stored objects.

The metamodel used to get the registered EPackages was constructed using Edapt methods (org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadMetamodel())

There is no other client connected to the repo thus there should be (???) no other transaction modifying the resource, right? Or does the proxy resolve mechanism does that? As all the existing code tries to work with a resource and is (relatively) CDO agnostic I would like to keep the synced CDOView out of the code if that's really not the reason for the NoSuchElementException.

Sorry for the confusing code. I try to wrap my head around this non-working Edapt-CDO-migration. I really hope to get this working after all the good experiences with CDO.

Thanks again

Alex
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741675 is a reply to message #1741671] Sat, 27 August 2016 05:26 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
The stack trace of the NullPointerException suggests that there's something wrong with the nsURIs in your Ecore file. Does it contain nested EPackages? If so, Are their nsURIs changed (compared to their first registration in the repository)?

Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741679 is a reply to message #1741675] Sat, 27 August 2016 07:21 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
The nsURIs in the Ecore file are the evolved ones, e.g. masterdata6 whereas in the CDO repo the appropriate nsURI would be masterdata5. I increment them with every Edapt based release as suggested by Edapt.
The curious thing is: when I do
session.getPackageRegistry().getEPackage("masterdata6")

I get as expected
null

But when I do
session.getPackageRegistry().getEPackage("masterdata5")

this NPE posted above occurs.
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741680 is a reply to message #1741679] Sat, 27 August 2016 07:59 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
Without a test case that I can run in order to reproduce the problem I'm running out of ideas. Can you provide such a test case? Please have a look at the subclasses of AbstractCDOTest. If you can't expose your model or code to the public you can also send it to me privately.

Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741682 is a reply to message #1741680] Sat, 27 August 2016 09:23 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
I tracked down the problem further more. Sorry that I oversaw this in a previous debugging session.
in org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.loadPackageFromGlobalRegistry(String packageURI) there is a call to
EPackage.Registry.INSTANCE.getEPackage(packageURI); //packageURI = masterdata5

Because the EPackage.Registry.INSTANCE is only populated with the Ecore based model classes (all with nsURI = masterdata6)
the getEPackage(packageURI) finds for masterdata5 only a EPackageDescriptor which leads to a subsequent call to
ePackageDescriptor.getEPackage();

that gets the EPackage in org.eclipse.emf.ecore.plugin.RegistryReader.getEPackage() via
Class<?> javaClass = CommonPlugin.loadClass(element.getDeclaringExtension().getContributor().getName(), element.getAttribute(attributeName));

what gets the evolved model package class with then the new nsURI masterdata6 that is then queried in CDOPackageRegistryImpl. But there it is not present as there is only masterdata5.

That's why the NPE vanishes if I put the Edapt metamodel packages in the EPackage.Registry.INSTANCE.

The NoSuchElementException always occurs at the same point, i.e. at loading the same element (I looked into the repo via the repo web browser). It's an object with a EReference to the evolved model class, i.e. that class I introduced an new EAttribute in masterdata6 in comparison to masterdata5.

While traversing the collection the call to org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(CDOID id) seems to cause the problem, because if I place a conditional breakpoint at line 1831 if the problematic object is about to be created the breakpoint is hit
1831    int originalCount = objectCreationCounter;
1832    InternalCDORevision revision = getRevision(id, true);
1833    if (revision == null)
1834    {
1835     throw new ObjectNotFoundException(id, this);
1836    }

If I place a conditional breakpoint at line 1833 the NoSuchElementException occurs.

Any ideas? Nevertheless I'll continue to look into the problem.
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741696 is a reply to message #1741682] Sat, 27 August 2016 20:48 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
The trace output before the NoSuchElementException is
main [debug.view] Creating object for OID795
main [debug.signal] ================ Requesting: LoadRevisionsRequest(infos=[RevisionInfo.Missing[OID795, Transaction 1]], branchPoint=Transaction 1, referenceChunk=-1, prefetchDepth=0)
main [debug.protocol] Writing branchPoint: Transaction 1
main [debug.buffer] Obtained Buffer@3[INITIAL]
main [debug.buffer.stream] Put signal id 7
main [debug.protocol] Writing referenceChunk: -1
main [debug.protocol] Writing 1 infos
main [debug.protocol] Writing info: RevisionInfo.Missing[OID795, Transaction 1]
main [debug.protocol] Writing CDOIDObject of subtype 0 (LONG)
main [debug.channel] Handling buffer: Buffer@3[PUTTING] --> Channel[1, CLIENT, cdo]
main [debug.signal] ================ Confirming: LoadRevisionsRequest(infos=[RevisionInfo.Missing[OID795, Transaction 1]], branchPoint=Transaction 1, referenceChunk=-1, prefetchDepth=0)
main [debug.protocol] Reading 1 revisions
TCPSelector [debug.buffer] Writing 40 bytes (EOS)
00 00 01 5b 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 03 00 00 00 00 00 00 00 03 1b 00 00 00 00 
TCPSelector [debug.buffer] Retaining Buffer@3[RELEASED]
TCPSelector [debug.buffer] Obtained Buffer@2[INITIAL]
TCPSelector [debug.buffer] Read 606 bytes (EOS)
00 00 01 5a 01 7f 00 00 00 00 00 00 22 02 01 00 19 6d 61 73 74 65 72 64 61 74 61 35 23 42 61 73 65 43 6f 6d 70 6f 6e 65 6e 74 00 01 00 00 00 00 00 00 00 03 1b 00 00 00 00 00 00 01 56 60 05 73 7e 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 1a 00 00 00 00 03 02 00 01 00 06 43 6f 6d 70 20 41 00 02 00 01 00 03 31 32 33 00 02 01 02 00 01 00 11 53 70 6f 69 6c 65 72 20 43 6f 6d 70 6f 6e 65 6e 74 00 02 00 00 00 02 00 00 00 00 00 00 00 03 1c 00 00 00 00 00 00 00 03 1d 02 00 00 00 02 00 00 00 00 00 00 00 03 1e 00 00 00 00 00 00 00 03 23 02 00 00 00 00 00 00 00 03 66 02 00 00 00 00 00 00 00 03 64 02 00 00 00 03 00 00 00 00 00 00 00 03 6c 00 00 00 00 00 00 00 03 2c 00 00 00 00 00 00 00 03 03 02 00 00 00 05 00 00 00 00 00 00 00 03 4b 00 00 00 00 00 00 00 03 4d 00 00 00 00 00 00 00 03 54 00 00 00 00 00 00 00 03 5b 00 00 00 00 00 00 00 03 5e 00 02 00 00 00 04 00 00 00 00 00 00 00 03 28 00 00 00 00 00 00 00 03 29 00 00 00 00 00 00 00 03 2a 00 00 00 00 00 00 00 03 2b 00 02 00 00 00 1c 00 00 00 00 00 00 00 03 7b 00 00 00 00 00 00 00 03 7c 00 00 00 00 00 00 00 03 7e 00 00 00 00 00 00 00 03 7f 00 00 00 00 00 00 00 03 6f 00 00 00 00 00 00 00 03 5f 00 00 00 00 00 00 00 03 4f 00 00 00 00 00 00 00 03 4d 00 00 00 00 00 00 00 03 4c 00 00 00 00 00 00 00 03 4b 00 00 00 00 00 00 00 03 4a 00 00 00 00 00 00 00 03 49 00 00 00 00 00 00 00 03 48 00 00 00 00 00 00 00 03 47 00 00 00 00 00 00 00 03 46 00 00 00 00 00 00 00 03 45 00 00 00 00 00 00 00 03 44 00 00 00 00 00 00 00 03 43 00 00 00 00 00 00 00 03 42 00 00 00 00 00 00 00 03 41 00 00 00 00 00 00 00 03 40 00 00 00 00 00 00 00 03 3f 00 00 00 00 00 00 00 04 35 00 00 00 00 00 00 00 04 34 00 00 00 00 00 00 00 04 32 00 00 00 00 00 00 00 04 30 00 00 00 00 00 00 00 04 29 00 00 00 00 00 00 00 04 16 02 00 00 00 00 02 00 00 00 00 00 00 00 03 0a 00 00 00 00 00 
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@2[GETTING] --> Channel[1, CLIENT, cdo]
Net4jReceiveSerializer-Channel[1, CLIENT, cdo] [debug.signal] Received buffer for correlation -347
main [debug.protocol] Reading CDOIDObject of subtype 0 (LONG)
main [debug.protocol] Reading CDOID of type 0 (NULL)
main [debug.protocol] Reading CDOIDObject of subtype 0 (LONG)
main [debug.revision] Reading revision: ID=OID795, className=BaseComponent, version=1, branchPoint=BranchPoint[Branch[id=0, name=MAIN], 2016-08-18 20:59:09.822], revised=0, resource=NULL, container=OID794, featureID=-1
main [debug.revision] Read feature name: Comp A
main [debug.revision] Read feature partNumber: 123
main [debug.revision] Read feature isMeasurable: true
main [debug.revision] Read feature comment: Spoiler Component
main [debug.protocol] Reading CDOID of type 0 (NULL)
main [debug.revision] Read feature predecessor: NULL
main [debug.protocol] Read feature mountingParts: size=16.777.216, referenceChunk=3
main [debug.protocol] Reading CDOID of type 28 (28)


If I use the transaction sepearately via
cdoView.getObject(org.eclipse.emf.cdo.common.id.CDOIDUtil.createLong(795)) // ID of the problematic object

I get after the same trace messages the following exception
java.lang.ArrayIndexOutOfBoundsException: 28
	at org.eclipse.emf.cdo.common.id.CDOIDUtil.read(CDOIDUtil.java:500)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOID(CDODataInputImpl.java:393)
	at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.readValue(CDOTypeImpl.java:252)
	at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.readValue(CDOTypeImpl.java:1)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOList(CDODataInputImpl.java:548)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.readValue(BaseCDORevision.java:269)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.readValues(BaseCDORevision.java:245)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.read(BaseCDORevision.java:190)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDORevision(CDODataInputImpl.java:434)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDORevision(CDODataInputImpl.java:425)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readRevision(RevisionInfo.java:225)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:165)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:142)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:1)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequest.confirming(CDOClientRequest.java:97)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedInput(RequestWithConfirmation.java:125)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:105)
	at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:53)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
	at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:466)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:89)
	at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:75)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:605)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:638)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.loadRevisions(CDOClientProtocol.java:203)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:431)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:309)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:291)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:284)
	at org.eclipse.emf.internal.cdo.view.CDOViewImpl.getRevision(CDOViewImpl.java:907)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:1833)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:1661)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1498)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:1602)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:1)

As far as I understand the code the byte sequence is interpreted wrong as 28 is not a valid ordinal for a CDOID.Type
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741699 is a reply to message #1741696] Sat, 27 August 2016 22:19 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
The problem seems to be that AbstractCDORevision.getAllPersistentFeatures() returns the features in the wrong order thus BaseCDORevision.readValues(CDODataInput) expects a different feature order in the byte sequence.

BTW: I also had to put the Edapt metamodel packages in the sessions package registry as org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOClassifierRefAndResolve() uses the sessions package registry to resolve the package (technically speaking the subsequent calls to CDOClassifierRef.resolve(EPackage.Registry) and from there EPackageRegistryImpl.getEPackage(String)). If it's not present there but only the EPackage.Descriptor the evolved model package is used again.

So: In the end it seems that the Edapt metamodel packages are the problem. Let's look into this.
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741700 is a reply to message #1741699] Sat, 27 August 2016 22:31 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Isn't there any way to obtain the package information from the CDO server itself?
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741714 is a reply to message #1741700] Sun, 28 August 2016 13:24 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
YEAH! Maybe I did it, let's see.

What I did so far is: I used org.eclipse.emf.cdo.spi.common.model.PackageLoader and manually loaded the packages from the CDO server and replaced the already registered EPackage.Descriptors in the CDOSessions package registry and the EPackage.Registry.INSTANCE with the loaded ones.
Now the NoSuchElementException is gone and also the next bug I ran into has vanished: the instance initialization in the org.eclipse.emf.edapt.cdo.migration.StrategyForwardConverter. This also used
EClass.getAllEAttributes()
for
eObject.eGet(EAttribute)
and ended up with the wrong data.

I report back if I get the migration finally to work!



Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741718 is a reply to message #1741714] Sun, 28 August 2016 17:20 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
On the one hand that sounds promising, on the other hand one sentence makes me suspicious. You said you are replacing a registration in the package registry. As the key is always the nsURI, I wonder if you are dealing with two different EPackages that accidentally have the same nsURI. That would be a problem that you just can't work-around with reregistration tricks.

Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741721 is a reply to message #1741718] Sun, 28 August 2016 21:02 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
The problem is that in org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.load(PackageLoader packageLoader, boolean resolve) the call to loadPackagesFromGlobalRegistry() and subsequently to loadPackagesFromGlobalRegistry(packageURI) and then to EPackage.Registry.INSTANCE.getEPackage(packageURI) implemented by EPackageRegistryImpl finds an EPackage.Descriptor that triggers RegistryReader.getEPackage() what then finds the evolved class via
Class<?> javaClass = CommonPlugin.loadClass(element.getDeclaringExtension().getContributor().getName(), element.getAttribute(attributeName));

So the only chance I seem to have is to put an EPackage in the registry instead of an EPackage.Descriptor. The Edapt metamodel package is somehow constructed differently than the package in the CDO server so my idea was to load the package from the server itself. My still crappy code that runs before the packages are used the first time looks like
InternalCDOPackageRegistry cdoPackageRegistry =
                (InternalCDOPackageRegistry) cdoView.getSession().getPackageRegistry();
        String[] nsURIs = new String[]{"masterdata5"}; // nsURI of "old"/unevolved package

        // load package with package loader
        PackageLoader packageLoader = cdoPackageRegistry.getPackageLoader();
        for (String nsURI : nsURIs) {
            InternalCDOPackageInfo pkgInfo = (InternalCDOPackageInfo) cdoPackageRegistry.get(nsURI);
            EPackage[] loadedPackages = packageLoader.loadPackages(pkgInfo.getPackageUnit());
            for (EPackage loadedPackage : loadedPackages) {
                EPackage.Registry.INSTANCE.put(nsURI, loadedPackage);
            }
        }

You have a better idea? I also suspect that
session.options().setGeneratedPackageEmulationEnabled(true);

might be involved.

Also: how do the EPackage.Descriptors (that only the CDO server knows of) end up in the global registry (EPackage.Registry.INSTANCE)?
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741741 is a reply to message #1741721] Mon, 29 August 2016 08:57 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
I've just double-checked that session.options().setGeneratedPackageEmulationEnabled(true) works correctly. I did the following:

1. Started a CDO server without generated packages deployed.
2. Started a client with generated example package deployed. Created a resource and populated it with instances of the generated example package.
3. Restarted that client with generated example package deployed. Verified that instances of the generated example package are loaded.
4. Restarted that client without generated example package deployed and with session.options().setGeneratedPackageEmulationEnabled(false). Verified that CDOPackageNotFoundException is thrown.
5. Restarted that client without generated example package deployed and with session.options().setGeneratedPackageEmulationEnabled(true). Verified that the dynamic package is loaded from the server and dynamic instances are loaded.

Please let me make sure that I understand your scenario. You used a client with the generated package with the nsURI "metamodel5" and committed instances of that package to your repo. Then you evolved your package, so that it has different structure and the new nsURI "metamodel6". In order to migrate your existing metamodel5 instances in the repo you started a new client with the generated package metamodel6; and you were trying to get the existing metamodel5 instances loaded through the dynamic metamodel5 package, which is stored in the repo. Correct so far?

So please answer the following question precisely: With your "migration client", what are the exact mappings in your global package registry (nsURI -> Object)? I'm only interested in the metamodel5 and/or metamodel6 mappings.


Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741774 is a reply to message #1741741] Mon, 29 August 2016 11:27 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Yes, you understood the scenario totally correct.

The mappings are the following:
EPackage.Registry.INSTANCE.get("masterdata5") 
--> (org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor) org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor@6af78a48
EPackage.Registry.INSTANCE.get("masterdata6") 
--> (com.sc.antennendb.model.masterdata.impl.MasterdataPackageImpl) model.masterdata.impl.MasterdataPackageImpl@61bb1e4d (name: masterdata) (nsURI: masterdata6, nsPrefix: masterdata)


Maybe some explanation for what I'm doing: I found the CDO/Edapt migration code of Christophe Bouhier, the only publically available code (at least the one I found) to migrate an existing CDO resource regarding model evolution. But the last commits on http://git.eclipse.org/c/edapt/org.eclipse.emf.edapt.git/commit/?h=topic_cdo were from 2 years ago. Maybe I got it all wrong when I started working on that issue but to me the code in org.eclipse.emf.edapt.cdo.migration.execution.CDOMigrator, especially what I understood from the main method, was not ready to work to support my scenario to migrate a CDOResource on the fly to a CDOResource.
After debugging for days I might understood, that using the Edapt created model cannot work with CDO (at least not at the moment). Also a comment of Christophe in org.eclipse.emf.edapt.cdo.migration.StrategyForwardConverter in line 134 (that I understood just 2 days ago) point in that direction:
"// CB Doesn't work for CDO! (Not with already loaded resources,
// turned on the option to emulate Generated packages, but provides
// Classifiers here in different order....
"
The was the reason the CDOIDUtil.read() failed as another EStructuralFeature was tried to read as was provided the edapt metamodel.

So do not want to migrate the DB tables of the "old" instance as this would be a lot more complex, but instead load the existing model from the server, just use the Forward- and BackwardConverter logic from Edapt and parts of the code of Christophe to create evolved package based CDOObject instances and save the resource to a new repository and have the CDO server create the tables based on the evolved model.

Currently the BackwardConverter throws some errors I'm working on, but does my approach make sense to you?

Unfortunately not to be able to use the Edapt metamodel creation is a big flaw. Maybe it would be worthwhile to have a closer look at org.eclipse.emf.edapt.internal.migration.internal.Persistency.loadMetamodel(ResourceSet) to fix that problem (in a derived CDO-specific Persistency class). Then the CDO migration might integrate seamlessly into Edapt migration just based on a CDO connection aware URI.

[Updated on: Mon, 29 August 2016 18:23]

Report message to a moderator

Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741784 is a reply to message #1741774] Mon, 29 August 2016 15:09 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
I assume your second mapping should really be EPackage.Registry.INSTANCE.get("masterdata6"), not 5, right?

But I'm more suspicious about the first mapping. A RegistryReader$EPackageDescriptor indicates that some plugin contributes a generated package for the nsURI "masterdata5". What plugin is that and how does its plugin.xml look like?


Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741805 is a reply to message #1741784] Mon, 29 August 2016 18:29 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Yes, you're right, it was a typo. I corrected it.

I debug the code to find out about the registering plugin, but all I can think of is some Edapt magic as there is none of my plugins having the masterdata5 model package available.

BTW: thanks for verifying the setGeneratedPackageEmulationEnabled() and for your overall commitment!!!
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741823 is a reply to message #1741805] Mon, 29 August 2016 22:05 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
2 hours of debugging and I missed the almost obvious. At least now I got in touch with the EMF the registration mechanism Wink
<extension point="org.eclipse.emf.ecore.generated_package">
      <!-- @generated masterdata -->
      <package
            uri="masterdata5"
            class="model.masterdata.MasterdataPackage"
            genModel="model/AntennenDB.genmodel"/>
   </extension>

It was infact in my own model plugin. But how does this end up there. I released (in terms of Edapt the release no. 6). So how does the plugin.xml get's updated?
Just to be clear: the model.history file says
<releases date="2016-08-04T11:33:49.419+0200">
  ...
  <changes xsi:type="history:Set" element="masterdata.ecore#/" featureName="nsURI" dataValue="masterdata6" oldDataValue="masterdata5"/>
</releases> 


I changed the release number to 6 manually and WOW: no more registration tricks needed!

Thanks so far. I'll keep you updated.
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741836 is a reply to message #1741823] Tue, 30 August 2016 05:25 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6583
Registered: July 2009
Senior Member
Yeah, I suspected that something with the registration of your generated model must have been wrong. Good that you found it. I'll ask Ed to comment on why your plugin.xml wasn't properly updated during model generation...

Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741838 is a reply to message #1741823] Tue, 30 August 2016 06:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31959
Registered: July 2009
Senior Member
The plugin.xml is merged when you regenerate. This is done with the help of the @generated annotation's key, i.e., GenModel.getPluginKey. That feature has a derived default value computed in org.eclipse.emf.codegen.ecore.genmodel.impl.GenModelImpl.getPluginKey() and in your case the value is/was "masterdata".

Might it be the case that after generating the plugin.xml the first time you changed the name of the Ecore model from masterdata.ecore to perhaps Masterdata.ecore or MasterData.ecore? That would change the computed value of the plugin key. The plugin.xml merger, when merging in a newly generated plugin.xml, would see that there is already an extension for the class model.masterdata.MasterdataPackage but with a different plugin key and that would block the change from being merged.

If you delete all the contents of the existing plugin.xml and regenerate, what does the result look like? The plugin.xml being empty should allow the plugin.xml merger to merge in all the next contents and from that you'll see what key is being used by the current state of your model.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741848 is a reply to message #1741838] Tue, 30 August 2016 07:16 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
Something's wrong here:
* I emptied the plugin.xml
* saved it
* closed the editor of plugin.xml
* open the .genmodel
* reloaded the model with the "Ecore model (CDO native)" importer (selected masterdata as the root package to use!)
* did "Generate Model Code" and "Generate All" as well
BUT: plugin.xml stays empty

That must have worked some time before. Maybe it has something to do with switching my development machine to a MacOS based one? Also if I really doubt that as none of the bundles involved in the model generation (as far as I know) are MacOS fragments, this is the only obvious thing I did.
Oh, and the other thing is to switch from Mars to Neon with switching my development machine. That could cause the problem.
BTW: my target platform is not IDE dependent, i.e. I always use my Mars-based target platform, but the code generation is done by the IDE platform bundles, right?, so that doesn't matter.
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741851 is a reply to message #1741848] Tue, 30 August 2016 07:44 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31959
Registered: July 2009
Senior Member
As you say, this must have worked before... MacOS has different line feed conventions but the merger is just textual and detects the line feed used in the file, so that doesn't seem likely to be an issue; unless perhaps there is a mixture in the fie. There are no platform specific fragments in EMF so that can't be an issue either. The plugin.xml merge support is quite old, so I don't expect switching versions should be a problem either.

If you delete the plugin.xml, does it generate a new one? If not, is your Model Plug-in ID non-empty?

If you're trying to debug this, you can see what's happening in org.eclipse.emf.codegen.ecore.genmodel.generator.GenModelGeneratorAdapter.generateModelManifest(GenModel, Monitor).


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741853 is a reply to message #1741851] Tue, 30 August 2016 08:01 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
If I delete the plugin.xml it is created correctly.

How do I debug the currently running Eclipse instance?
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1741876 is a reply to message #1741853] Tue, 30 August 2016 11:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31959
Registered: July 2009
Senior Member
If you empty the plugin.xml out now, i.e., remove that extension, does it generate the contents properly now? If you compare the newly generated plugin.xml to the original one, what are all the differences? If you change the nsURI now, and regenerate, does it update the plugin.xml properly?

I've not been able to reproduce your problem, except for an example where the key changed, so I'm try to figure out what's special about your scenario...

It's not easy to debug. You'd need another IDE to debug it from so I'm not suggesting you try this...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1742111 is a reply to message #1741876] Wed, 31 August 2016 14:00 Go to previous messageGo to next message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
For the short version, just skip the part enclosed by ============

====================================================================
I debugged
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.getExtensionData(String contents)

The oldContents input was
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<!--
-->

<plugin>
   <extension point="org.eclipse.emf.ecore.generated_package">
      <!-- @generated masterdata -->
      <package
            uri="masterdata5"
            class="model.masterdata.MasterdataPackage"
            genModel="model/model.genmodel"/>
   </extension>
</plugin>


The newContents input was
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<!--
-->

<plugin>
  <extension point="org.eclipse.emf.ecore.generated_package">
     <!-- @generated model -->
     <package
           uri="masterdata6"
           class="model.masterdata.MasterdataPackage"
           genModel="model/model.genmodel"/>
  </extension>
</plugin>


The strange thing is, that the string after @generated is in the oldContents
the name of the ecore file (I have more than the one package masterdata that are all the same ecore file named masterdata.ecore
and all the packages have @generated masterdata),
in the newContents the string is the name of the genmodel/history file.
Thus the oldContent of each extension is not replaced by the new ones as done by
/*  909 */         if ((oldExtension.generated != null) && (oldExtension.generated.equals(newExtension.generated)))
/*      */ 
/*      */ 
/*      */         {
/*  913 */           oldExtension.content = newExtension.content;
/*      */ 
/*      */ 
/*      */         }


The mergePluginXML(String, String, String) gets called with generated="model" coming from GenModelImpl.getPluginKey
and I have no clue how the old plugin.xml could end up with @genmodel masterdata as the eResource of the GenModelImpl
object always seems to be the genmodel file.
I also had a look at the Mars sources (the last version of the plugin.xml was created with Mars) and the code has not changed as far as I can see.
====================================================================

Long story short: I had a closer look in our git repo and realized that there was a genmodel file for every ecore file some month ago (yes, it was named masterdata.genmodel Wink) , before they got merged into one. Without a deeper understanding of the generation mechanism my collegue just incremented the URI manually as the generation mechanism did not work.

So now I'm very content to have solved another EMF riddle and learned a lot.

Let's get back to the CDO migration! I'll post if there are some news!
Re: NoSuchElementException while traversing CDOResource.getAllContents() [message #1742354 is a reply to message #1741876] Wed, 31 August 2016 14:00 Go to previous message
Alexander Nehmer is currently offline Alexander NehmerFriend
Messages: 19
Registered: January 2016
Junior Member
For the short version, just skip the part enclosed by ============

====================================================================
I debugged
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.getExtensionData(String contents)
The oldContents input was

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<!--
-->

<plugin>
<extension point="org.eclipse.emf.ecore.generated_package">
<!-- @generated masterdata -->
<package
uri="masterdata5"
class="model.masterdata.MasterdataPackage"
genModel="model/model.genmodel"/>
</extension>
</plugin>


The newContents input was

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<!--
-->

<plugin>
<extension point="org.eclipse.emf.ecore.generated_package">
<!-- @generated model -->
<package
uri="masterdata6"
class="model.masterdata.MasterdataPackage"
genModel="model/model.genmodel"/>
</extension>
</plugin>


The strange thing is, that the string after @generated is in the oldContents
the name of the ecore file (I have more than the one package masterdata that are all the same ecore file named masterdata.ecore
and all the packages have @generated masterdata),
in the newContents the string is the name of the genmodel/history file.
Thus the oldContent of each extension is not replaced by the new ones as done by

/* 909 */ if ((oldExtension.generated != null) && (oldExtension.generated.equals(newExtension.generated)))
/* */
/* */
/* */ {
/* 913 */ oldExtension.content = newExtension.content;
/* */
/* */
/* */ }


The mergePluginXML(String, String, String) gets called with generated="model" coming from GenModelImpl.getPluginKey
and I have no clue how the old plugin.xml could end up with @genmodel masterdata as the eResource of the GenModelImpl
object always seems to be the genmodel file.
I also had a look at the Mars sources (the last version of the plugin.xml was created with Mars) and the code has not changed as far as I can see.
====================================================================

Long story short: I had a closer look in our git repo and realized that there was a genmodel file for every ecore file some month ago (yes, it was named masterdata.genmodel ;)) , before they got merged into one. Without a deeper understanding of the generation mechanism my collegue just incremented the URI manually as the generation mechanism did not work.

So now I'm very content to have solved another EMF riddle and learned a lot.

Let's get back to the CDO migration! I'll post if there are some news!
Previous Topic:[CDO] Cannot create root element from my model
Next Topic:news.eclipse.org is shutting down.
Goto Forum:
  


Current Time: Sun Jul 25 17:18:49 GMT 2021

Powered by FUDForum. Page generated in 0.03373 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top