QVTo editor with changing input model [message #917610] |
Thu, 20 September 2012 08:47 |
Eclipse User |
|
|
|
Hello,
in my project, the input and output models (EMF Ecore and EMF XSD) are
changing quite frequently. Every time I open the QVTo editor I must
ensure that it knows the correct model version. So far I've solved this
by creating a launch configuration "QVT Editor" that contains the
generated EMF model code and loads the current XSD model on startup.
However this is a bit sub-optimal. It is a major extra step for each
developer to construct such a run-time eclipse. Opening QVTo scripts in
the normal development eclipse just blows you away with error markers as
it doesn't know any of the input/output models. That and the extra QVT
learning curve makes my client having 2nd thoughts about using the QVT
technology.
Long story short: is there a way to make the regular QVT editor aware of
changing models? Ideally, the editor would load the .ecore everytime
when opened. How can I archieve this?
Thanks
Marius
|
|
|
|
Re: QVTo editor with changing input model [message #917834 is a reply to message #917773] |
Thu, 20 September 2012 13:31 |
Eclipse User |
|
|
|
On 20.09.2012 14:21, Ed Willink wrote:
> Hi
>
> I don't understand your problem. I use EMF models that have never been
> code generated using QVTo.
>
> You just define the {project}->Properties->QVT Settings->Metamodel
> Mappings appropriately.
Oh. Ok. I didn't have that option in my project's properties. I've now
added the nature and the QVTo builder to the .project and restarted. (Is
that enough? I don't get the fancy QVTo icon...)
I've even managed to set up the model uri map for some of my EMF models.
But as I said in my OP, I'm also using XSD based models. And the model
uri map dialog doesn't seem to allow me adding those: "Failed to load
...." Any idea?
Thanks
Marius
|
|
|
|
Re: QVTo editor with changing input model [message #917882 is a reply to message #917865] |
Thu, 20 September 2012 14:24 |
Eclipse User |
|
|
|
On 20.09.2012 16:12, Ed Willink wrote:
> Hi
>
> QVTo support Ecore models.
>
> EMF provides a magic translation so that as far as I am aware your 'XSD
> model' should appear to be an Ecore model to QVTo; you just need to
> ensure that your Ecore to XSD configuration is coherent. The Sample
> Ecore Editor is always a good test of whether EMF is correctly configured.
I'm not sure I'm getting you (or vice versa). Previously, with my
"hand-rolled" runtime Eclipse I had to throw in a small own plugin which
basically used the XSDEcoreBuilder() to generate dynamic Ecore models
from my XSD files and add them to EMFs global registry. I guess this is
process is what you refer to as "magic translation".
But with the Model URI map approach - who would be doing that for me?
The map doesn't accept .xsd files. I could be using my plugin of course
to load the XSDs into the EMF registry, but this way I'd be losing any
chances of dynamic updates upon changes to the XSD.
Regards
Marius
|
|
|
|
Re: QVTo editor with changing input model [message #918597 is a reply to message #917917] |
Fri, 21 September 2012 06:50 |
Eclipse User |
|
|
|
On 20.09.2012 17:04, Ed Willink wrote:
> I don't use XSD much, but my understanding is that you create an Ecore
> metamodel from your XSD, so that your XSD files are loadable as EMF
> resources.
>
> If you have particular serialisation concerns you customize the
> ExtendedMetaData so that your XSD round-trips via an Ecore Resource to
> your satisfaction.
>
> That done, you then have a registration so that whenever a *.yourxsd
> file is opened, it uses your XSD configuration to provide the EMF
> resource for use by a variety of Ecore-based tools of which the Sample
> Ecore Editor is the simplest test that *.yourxsd is indeed correctly
> registered.
Well, so far I've loaded XSD as dynamic Ecore at runtime. A while ago I
tried the "offline" approach you mentioned and the roundtrip was broken.
The bug should have been fixed by now though. But anyway roundtrip would
be an extra gimmick which I don't necessarily need right now. Having a
fairly simple process from XSD -> .ecore would be ok. I'll try that
again when I have some time.
I'm not sure if I got you right regarding another point: if I change the
..ecore file in anyway, would the QVT editor pick that up, even if I need
to close it once? Or even more explicitly: will I not(!) have to restart
eclipse? That would be really my #1 requirement. I tried it yesterday
and after the change the editor somehow totally forgot about that (just
changed) model and even the "modeltype ..." was squiggled with an error
marker.
Thanks
Marius
|
|
|
Re: QVTo editor with changing input model [message #918722 is a reply to message #918597] |
Fri, 21 September 2012 09:28 |
Ed Willink Messages: 7676 Registered: July 2009 |
Senior Member |
|
|
Hi
Needing to close Eclipse is definitely unacceptable and certainly a bug.
Generally this only occurs with applications that abuse the global
registries; hopefully not QVTo.
Needing to close the editor is a pain but in principle EMF does not
support meta-model mutation, so this should only occur in model rather
than meta-model editors. Xtext is very good at spotting *.ecore changes.
Other tools seem to be patchy; hence I suspect that QVTo is imperfect here.
If you can provide a repro, please submit a Bugzilla.
Regards
Ed Willink
On 21/09/2012 07:50, Marius Gröger wrote:
> On 20.09.2012 17:04, Ed Willink wrote:
>> I don't use XSD much, but my understanding is that you create an Ecore
>> metamodel from your XSD, so that your XSD files are loadable as EMF
>> resources.
>>
>> If you have particular serialisation concerns you customize the
>> ExtendedMetaData so that your XSD round-trips via an Ecore Resource to
>> your satisfaction.
>>
>> That done, you then have a registration so that whenever a *.yourxsd
>> file is opened, it uses your XSD configuration to provide the EMF
>> resource for use by a variety of Ecore-based tools of which the Sample
>> Ecore Editor is the simplest test that *.yourxsd is indeed correctly
>> registered.
> Well, so far I've loaded XSD as dynamic Ecore at runtime. A while ago I
> tried the "offline" approach you mentioned and the roundtrip was broken.
> The bug should have been fixed by now though. But anyway roundtrip would
> be an extra gimmick which I don't necessarily need right now. Having a
> fairly simple process from XSD -> .ecore would be ok. I'll try that
> again when I have some time.
>
> I'm not sure if I got you right regarding another point: if I change the
> ..ecore file in anyway, would the QVT editor pick that up, even if I need
> to close it once? Or even more explicitly: will I not(!) have to restart
> eclipse? That would be really my #1 requirement. I tried it yesterday
> and after the change the editor somehow totally forgot about that (just
> changed) model and even the "modeltype ..." was squiggled with an error
> marker.
>
> Thanks
> Marius
>
|
|
|
Re: QVTo editor with changing input model [message #921503 is a reply to message #917773] |
Mon, 24 September 2012 07:05 |
Eclipse User |
|
|
|
On 20.09.2012 14:21, Ed Willink wrote:
> Hi
>
> I don't understand your problem. I use EMF models that have never been
> code generated using QVTo.
>
> You just define the {project}->Properties->QVT Settings->Metamodel
> Mappings appropriately.
For some reason the QVT builder doesn't always run properly. Very often
I get the stack trace below. For all I can see, the plugin containing
AggregateProxyPackage is present. Is there anything I can do about this?
java.lang.NoClassDefFoundError: Could not initialize class
org.eclipse.emf.facet.aggregate.metamodel.v0_2_0.aggregate.internal.aggregateProxy.AggregateProxyPackage
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
at
sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:936)
at java.lang.reflect.Field.getFieldAccessor(Field.java:917)
at java.lang.reflect.Field.get(Field.java:376)
at
org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:273)
at
org.eclipse.emf.ecore.impl.EPackageImpl$1.getEPackage(EPackageImpl.java:162)
at
org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:127)
at
org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.EmfMetamodelDesc.getModel(EmfMetamodelDesc.java:64)
at
org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.EmfMetamodelDesc.getLoadStatus(EmfMetamodelDesc.java:86)
at
org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.MetamodelRegistry.toEPackageRegistry(MetamodelRegistry.java:85)
at
org.eclipse.m2m.internal.qvt.oml.compiler.CompilerUtils.getEPackageRegistry(CompilerUtils.java:106)
at
org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.getEPackageRegistry(QVTOCompiler.java:569)
at
org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.parse(QVTOCompiler.java:272)
at
org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.doCompile(QVTOCompiler.java:416)
at
org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compileSingleFile(QVTOCompiler.java:373)
at
org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compile(QVTOCompiler.java:218)
at
org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.rebuildAll(QVTOBuilder.java:223)
at
org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.fullBuild(QVTOBuilder.java:109)
at
org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.build(QVTOBuilder.java:92)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
|
|
|
|
|
Re: QVTo editor with changing input model [message #921911 is a reply to message #921783] |
Mon, 24 September 2012 14:46 |
Eclipse User |
|
|
|
On 24.09.2012 14:22, Marius Gröger wrote:
> On 24.09.2012 11:34, Ed Willink wrote:
>> I'm afraid that I see EMF Facet in the stack trace.
>
> Just for completeness, I've taken the issue over to the EMF news group:
> http://www.eclipse.org/forums/index.php/m/921753/
>
> Summary thus far: I've been able to locate an issue with the order of
> initialization of the various Aggregate*Packages.
One more question: it seems like a silly question, but for what purpose
do I actually need the QVT builder? I noticed that if I uncheck it in
the properties, I still get a working QVT editor with syntax coloring
and completion?!
Marius
|
|
|
Re: QVTo editor with changing input model [message #921923 is a reply to message #921911] |
Mon, 24 September 2012 14:58 |
Eclipse User |
|
|
|
On 24.09.2012 16:46, Marius Gröger wrote:
> On 24.09.2012 14:22, Marius Gröger wrote:
>> On 24.09.2012 11:34, Ed Willink wrote:
>>> I'm afraid that I see EMF Facet in the stack trace.
>>
>> Just for completeness, I've taken the issue over to the EMF news group:
>> http://www.eclipse.org/forums/index.php/m/921753/
>>
>> Summary thus far: I've been able to locate an issue with the order of
>> initialization of the various Aggregate*Packages.
>
> One more question: it seems like a silly question, but for what purpose
> do I actually need the QVT builder? I noticed that if I uncheck it in
> the properties, I still get a working QVT editor with syntax coloring
> and completion?!
Hm, probably for the error markers if I *don't* open the QVT editor, right?
Marius
|
|
|
|
Powered by
FUDForum. Page generated in 0.07998 seconds