[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.emf] Re: EMF2.0 and CWM Rose Model

OK - looks like I'll have to revert to EMF 1.X - I'm not sure what the
problem could be, whether its some odd-ball thing with the model itself or
if there's some strange bug in 2.0.0, or some odd-ball thing with the
model that 1.X didn't catch. I'll try a future release.

Thanks
Ray


Frank Budinsky wrote:

> A missing upperBound in the .ecore file means that it has the default value.
If
> you look at the Ecore model, you'll see that the default value for
upperBound is,
> not surprisingly, 1.

> Thanks,
> Frank.

> Ray Harrison wrote:

> > Frank -
> > The ownedElement has an upperBound value of "-1" in the Emf1.X version on
> > Eclipse 212. For Emf2 on m5, there is no upperBound placeholder at all.
> >
> > Cheers
> > Ray
> >
> > Frank Budinsky wrote:
> >
> > > Ray,
> >
> > > There are quite a few changes in EMF 2.0, but nothing that should cause
an
> > > upper bound of * to not be handled by an EList. If you look at the .ecore
> > > file that is produced for this model, what is the value of the
"upperBound"
> > > attribute in the "ownedElement" EReference? Can you send us a simplified
> > > (stripped down) model that illustrates the problem you're seeing, so we
can
> > > take a look at it?
> >
> > > Thanks,
> > > Frank.
> >
> > > Ray Harrison wrote:
> >
> > > > Hello,
> > > >
> > > > I have started playing around with EMF2.0 and Eclipse 3.0 - m5. I have
> > > > been successfully using the Rose model provided by the OMG web site for
> > > > their Common Warehouse Metamodel (CWM) in EMF 1.X. However, when I
loaded
> > > > the model into 3.0 - m6 and now 3.0 m5 using EMF 2.0 I noticed a
problem:
> > > >
> > > > 1-M relationships seem to be treated as 1-1 relationships. As an
example,
> > > > a Namespace can contain a collection of ModelElements. However, in the
> > > > EMF2.0 generated code the relationship is indicated by:
> > > >
> > > > ModelElement getOwnedElement();
> > > >
> > > > and
> > > >
> > > > void setOwnedElement(ModelElement value);
> > > >
> > > > Using EMF 1.1.X resulted in a statement such that the collection was
> > > > represented by EList getOwnedElement(), etc.
> > > >
> > > > I used the same model in each case. What might the problem be? Have I
> > > > missed something in the List of Changes for 2.0?
> > > >
> > > > Thanks
> > > > Ray Harrison