Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ecore model generator add a line too long to the Manifest.MF file
Ecore model generator add a line too long to the Manifest.MF file [message #1691129] Thu, 02 April 2015 13:29 Go to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
I'm using Eclipse Luna 4.4.1 and codegen.ecore 2.7.

Given a model where the .genmodel refers several .ecore files, such as:
bundle:
com.mycompany.myproject.datamodel

genmodel file:
datamodel.genmodel

ecore files:
componentA.ecore
componentB.ecore
componentC.ecore
componentD.ecore
componentE.ecore

When I generate the model from the .genmodel file, it adds this line (among others) to the manifest.mf:

 com.mycompany.myproject.datamodel.componentA.util;uses:="org.eclipse.emf.ecore.resource,  org.eclipse.emf.ecore.xmi.impl,  org.eclipse.emf.common.util,  com.mycompany.myproject.datamodel.componentB,  com.mycompany.myproject.datamodel.componentC,  org.eclipse.emf.ecore.xmi.util,  org.eclipse.emf.common.notify,  org.eclipse.emf.ecore.resource.impl,  org.eclipse.emf.ecore,  com.mycompany.myproject.datamodel.componentD,  org.eclipse.emf.common.notify.impl,  com.mycompany.myproject.datamodel.componentE,  com.mycompany.myproject.datamodel.componentA",


The problem is that this line becomes too long and it won't compile. Even we format the file manually, the next time the model is generated the manifest.mf is modified and the error is introduced again.

When I format the file manually it becomes like this:
 com.mycompany.myproject.datamodel.componentA.util;
  uses:="org.eclipse.emf.ecore.resource,
   org.eclipse.emf.ecore.xmi.impl,  
   org.eclipse.emf.common.util,  
   com.mycompany.myproject.datamodel.componentB,  
   com.mycompany.myproject.datamodel.componentC,  
   org.eclipse.emf.ecore.xmi.util,  
   org.eclipse.emf.common.notify,  
   org.eclipse.emf.ecore.resource.impl,  
   org.eclipse.emf.ecore,  
   com.mycompany.myproject.datamodel.componentD,  
   org.eclipse.emf.common.notify.impl,  
   com.mycompany.myproject.datamodel.componentE,  
   com.mycompany.myproject.datamodel.componentA",


I have used also other tools that generated Manifest files such as Maven and it makes sure the line do not exceed a certain length, even it stays not formatted at all.

Is there a way to configure the ecore generator so it could automatically format the manifest.mf to avoid introducing errors? I already tried to use the automatic source code formatter but it didn't work.

[Updated on: Thu, 02 April 2015 13:33]

Report message to a moderator

Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691132 is a reply to message #1691129] Thu, 02 April 2015 13:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30366
Registered: July 2009
Senior Member
Which version of EMF are you using? (This sounds like a problem that
was fixed.)

On 02/04/2015 3:29 PM, Silvestre Martins wrote:
> Given a model where the .genmodel refers several .ecore files, such as:
> bundle:
> com.mycompany.myproject.datamodel
>
> genmodel file:
> datamodel.genmodel
>
> ecore files:
> componentA.ecore
> componentB.ecore
> componentC.ecore
> componentD.ecore
> componentE.ecore
>
> When I generate the model from the .genmodel file, it adds this line
> (among others) to the manifest.mf:
>
> com.mycompany.myproject.datamodel.componentA.util;uses:="org.eclipse.emf.ecore.resource,
> org.eclipse.emf.ecore.xmi.impl, org.eclipse.emf.common.util,
> com.mycompany.myproject.datamodel.componentB,
> com.mycompany.myproject.datamodel.componentC,
> org.eclipse.emf.ecore.xmi.util, org.eclipse.emf.common.notify,
> org.eclipse.emf.ecore.resource.impl, org.eclipse.emf.ecore,
> com.mycompany.myproject.datamodel.componentD,
> org.eclipse.emf.common.notify.impl,
> com.mycompany.myproject.datamodel.componentE,
> com.mycompany.myproject.datamodel.componentA",
>
> The problem is that this line becomes too long and it won't compile.
> Even we format the file manually, the next time the model is generated
> the manifest.mf is modified and the error is introduced again.
>
> When I format the file manually it becomes like this:
> com.mycompany.myproject.datamodel.componentA.util;
> uses:="org.eclipse.emf.ecore.resource,
> org.eclipse.emf.ecore.xmi.impl, org.eclipse.emf.common.util,
> com.mycompany.myproject.datamodel.componentB,
> com.mycompany.myproject.datamodel.componentC,
> org.eclipse.emf.ecore.xmi.util, org.eclipse.emf.common.notify,
> org.eclipse.emf.ecore.resource.impl, org.eclipse.emf.ecore,
> com.mycompany.myproject.datamodel.componentD,
> org.eclipse.emf.common.notify.impl,
> com.mycompany.myproject.datamodel.componentE,
> com.mycompany.myproject.datamodel.componentA",
> I have used also other tools that generated Manifest files such as
> Maven and it makes sure the line do not exceed a certain length, even
> it stays not formatted at all.
>
> Is there a way to configure the ecore generator so it could
> automatically format the manifest.mf to avoid introducing errors? I
> already tried to use the automatic source code formatter but it didn't
> work.
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691133 is a reply to message #1691132] Thu, 02 April 2015 13:47 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Sorry, I edited the post after you read it - I'm using EMF/Ecore 2.9 as part of the target platform. However, in the classpath there are the jars org.eclipse.emf.codegen_2.6.0 and org.eclipse.emf.codegen.ecore_2.7.0. I can try to update all these libraries.
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691143 is a reply to message #1691133] Thu, 02 April 2015 14:14 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30366
Registered: July 2009
Senior Member
I think this should be fixed in Luna SR2 (or maybe even in SR1 already)
so you should see a 2.10.1 or 2.10.2 installed for
org.eclipse.emf.codegen.ecore...

On 02/04/2015 3:47 PM, Silvestre Martins wrote:
> Sorry, I edited the post after you read it - I'm using EMF/Ecore 2.9
> as part of the target platform. However, in the classpath there are
> the jars org.eclipse.emf.codegen_2.6.0 and
> org.eclipse.emf.codegen.ecore_2.7.0. I can try to update all these
> libraries.
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691345 is a reply to message #1691143] Mon, 06 April 2015 11:54 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
I updated the libraries to 2.10.2 and now it's working fine!

However, I noticed the EcoreUtil.Copier was changed in 2.10 version, causing my code to stop working. Now, when I copy an EObject, the copied data in the new EObject is stored inside the eProperties field using the eSettings, instead of being stored in each respective feature field. Then, when I use the regular getter the result is null or empty.

Was the API changed? Do I need to perform an additional task at the end of the copy to ensure the objects are in the correct state so I can use the regular getters?
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691411 is a reply to message #1691345] Tue, 07 April 2015 06:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30366
Registered: July 2009
Senior Member
Silvestre,

Comments below.

On 06/04/2015 1:54 PM, Silvestre Martins wrote:
> I updated the libraries to 2.10.2 and now it's working fine!
>
> However, I noticed the EcoreUtil.Copier was changed in 2.10 version,
> causing my code to stop working. Now, when I copy an EObject, the
> copied data in the new EObject is stored inside the eProperties field
> using the eSettings, instead of being stored in each respective
> feature field. Then, when I use the regular getter the result is null
> or empty.
It's hard to speculate what could cause that. Certainly we use the
copier extensively in Oomph and what you describe depends on the
implementation instances involved, i.e., the copier simply uses the
reflective methods and what you describe sounds as if dynamic instances
are involved. I can't think of any reason a generated instance would
behave like a dynamic one.

You might want to look at
http://ed-merks.blogspot.de/2009/01/emf-ultra-slim-diet.html and
consider regenerating your model (though this should have no impact on
the problem you describe).
>
> Was the API changed?
Certainly it has been refactored significantly, so likely that had an
unforeseen impact (though it shouldn't but alas)...
> Do I need to perform an additional task at the end of the copy to
> ensure the objects are in the correct state so I can use the regular
> getters?
No, I'd suggest setting a breakpoint in the constructors of
org.eclipse.emf.ecore.impl.DynamicEObjectImpl, in
org.eclipse.emf.ecore.impl.BasicEObjectImpl.EPropertiesHolderBaseImpl.setEClass(EClass),
and in
org.eclipse.emf.ecore.impl.BasicEObjectImpl.EPropertiesHolderBaseImpl.allocateSettings(int)
to see at what point a dynamic instance is created, or a generated
instance is made to believe its dynamic, and failing that, and when
values are stored as dynamic features...
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691456 is a reply to message #1691411] Tue, 07 April 2015 11:25 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
If you take a look at class BasicEObjectImpl, method eSetting(), you can see the following code:

EClass eClass = eClass();
int index = eClass.getFeatureID(eFeature);
int dynamicIndex = eStaticFeatureCount();
if (index >= dynamicIndex)
{
   return eSettingDelegate(eFeature).dynamicSetting(this, eSettings(), index - dynamicIndex);
}


Since the feature ID is 0 (in my example is the first feature of the EClass), this code will always enter in that if, using the dynamic setting.

This code was not changed in 2.10, however, in 2.9 the EcoreUtil.Copier was not calling eSetting() method, it was simply using the EStructuralFeature (See EcoreUtil.copier.getTarget() methods)
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691458 is a reply to message #1691456] Tue, 07 April 2015 12:14 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30366
Registered: July 2009
Senior Member
Silvestre,

Comments below.

On 07/04/2015 1:25 PM, Silvestre Martins wrote:
> If you take a look at class BasicEObjectImpl, method eSetting(), you
> can see the following code:
>
> EClass eClass = eClass();
> int index = eClass.getFeatureID(eFeature);
> int dynamicIndex = eStaticFeatureCount();
> if (index >= dynamicIndex)
> {
> return eSettingDelegate(eFeature).dynamicSetting(this, eSettings(),
> index - dynamicIndex);
> }
>
> Since the feature ID is 0 (in my example is the first feature of the
> EClass), this code will always enter in that if, using the dynamic
> setting.
The opposite is true. The static feature count should be one more than
the highest feature ID in the generated model, i.e., why is
eStaticFeatureCount() returning 0 when you claim there is at least one
feature which has ID 0. If that were consistent, I'd expect this
implementation

protected int eStaticFeatureCount()
{
return eStaticClass().getFeatureCount();
}

to return that feature count, i.e., at least 1 for the case you mention,
and it should end up NOT going down that first branch...

My suspicion is that there's something not (re)generated properly in
your model...
>
> This code was not changed in 2.10, however, in 2.9 the
> EcoreUtil.Copier was not calling eSetting() method, it was simply
> using the EStructuralFeature (See EcoreUtil.copier.getTarget() methods)
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691468 is a reply to message #1691458] Tue, 07 April 2015 13:16 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Yes, you are right, this method was overridden in a common abstract class which is not part of our generation procedure. I need to investigate the reason why this was overridden.

Nevertheless, I didn't understand what is the goal of this method, more specifically, was it the difference between this method and the method eClass().getFeatureCount()? Because I was assuming what you described is what the method getFeatureCount() returns.
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691487 is a reply to message #1691468] Tue, 07 April 2015 15:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30366
Registered: July 2009
Senior Member
Silvestre,

Comments below.

On 07/04/2015 3:16 PM, Silvestre Martins wrote:
> Yes, you are right, this method was overridden in a common abstract
> class which is not part of our generation procedure. I need to
> investigate the reason why this was overridden.
It seems very questionable of course...
>
> Nevertheless, I didn't understand what is the goal of this method,
> more specifically, was it the difference between this method and the
> method eClass().getFeatureCount()?
All EObject implementations must also support InternalEObject. Hence the
framework can call
org.eclipse.emf.ecore.InternalEObject.eSetClass(EClass), which it does
when it needs to create a dynamic subclass of a generated instance.
The difference between eClass() and eStaticStatic() is that eClass will
return the dynamically set subclass while eStaticClass is generated to
return the exact subclass for which the implementation is generated.
The difference between their feature counts lets the framework know
which features are generated (and directly supported by the generated
eGet/eSet/eIsSet/eUnset, and which features must be represented as
dynamic settings because the implementation class knows nothing
statically about them.

> Because I was assuming what you described is what the method
> getFeatureCount() returns.
Re: Ecore model generator add a line too long to the Manifest.MF file [message #1691496 is a reply to message #1691487] Tue, 07 April 2015 16:00 Go to previous message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Thanks Ed, got it.
Previous Topic:GMF with vaadin
Next Topic:Using CDOModificationTrackingAdapter
Goto Forum:
  


Current Time: Thu Aug 22 17:31:26 GMT 2019

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

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

Back to the top