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 |
Silvestre Martins 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 |
Ed Merks Messages: 33113 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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
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 |
Ed Merks Messages: 33113 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...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
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 |
Silvestre Martins 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 |
Ed Merks Messages: 33113 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)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
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 |
Ed Merks Messages: 33113 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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Fri Mar 29 10:30:53 GMT 2024
Powered by FUDForum. Page generated in 0.05153 seconds
|