Eclipse Community Forums: QVT-OML » QVTo editor with changing input model

Home » Modeling » QVT-OML » QVTo editor with changing input model

QVTo editor with changing input model [message #917610]

Thu, 20 September 2012 04: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 #917773 is a reply to message #917610]

Thu, 20 September 2012 08:21

Eclipse User

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.

Mine end up (in .settings/org.eclipse.m2m.qvt.oml.mmodel.urimap) as:

<?xml version="1.0" encoding="ASCII"?>
<uriMap:MappingContainer xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:uriMap="http:///www.eclipse.org/m2m/qvt/oml/MModelUriMap/1.0.0">
<mapping sourceURI="http://www.eclipse.org/ocl/XBNF"
targetURI="platform:/resource/org.eclipse.ocl.examples.xtext2lpg/model/XBNF.ecore"/>
<mapping sourceURI="http://www.eclipse.org/ocl/XBNFwithCardinality"
targetURI="platform:/resource/org.eclipse.ocl.examples.xtext2lpg/model/XBNFwithCardinality.ecore"/>
</uriMap:MappingContainer>

I'm not certain the concurrent *.ecore update is perfect, so sometimes
it may be necessary to exit and restart the QVTo editor.

Regards

Ed Willink

On 20/09/2012 09:47, Marius Gröger wrote:
> 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 09: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 #917865 is a reply to message #917834]

Thu, 20 September 2012 10:12

Eclipse User

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.

Regards

Ed Willink

On 20/09/2012 14:31, Marius Gröger wrote:
> 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 10: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 #917917 is a reply to message #917882]

Thu, 20 September 2012 11:04

Eclipse User

Hi

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.

Regards

Ed Willink

On 20/09/2012 15:24, Marius Gröger wrote:
> 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 02: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 05:28

Eclipse User

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 03: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 #921628 is a reply to message #921503]

Mon, 24 September 2012 05:34

Eclipse User

HI

I'm afraid that I see EMF Facet in the stack trace.

My knowledge of EMF Facet is limited, but it appears that they do
'clever' things to meta-models, and from my experience they do not
always avoid causing problems for standard dumb users.

"doesn't always" and "Very often" are a strong indication that some
protocol is being abused; probably meta-model registries.

If you want to use EMF Facet in conjunction with other tools, you will
need to help contribute rather than consume the tools.

I suggest identifying
- a scenario that always works; possibly the first run after starting
Eclipse
- a similar scenario that never works; possibly just a rerun of the first

and create dumps of various meta-models and registries to find out the
difference and then determine where that difference comes from.

My guess is that the problem is that either

some registration is missing and gets created or changed
some meta-model element evolves in response to EMF Facet usage

The NoClassDefFoundError suggests that EMF Facet is being activated
unexpectedly. Try putting it on the classpath explicitly.

Regards

Ed Willink

On 24/09/2012 08:05, Marius Gröger wrote:
> 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 #921783 is a reply to message #921628]

Mon, 24 September 2012 08:22

Eclipse User

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.

Regards
Marius

Re: QVTo editor with changing input model [message #921911 is a reply to message #921783]

Mon, 24 September 2012 10: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 10: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

Re: QVTo editor with changing input model [message #922007 is a reply to message #921911]

Mon, 24 September 2012 12:40

Eclipse User

Hi

The same as why do you need a Java builder. If you only edit you never
need to compile.

Since QVTo doesn't currently persist compiled artefacts, the only
benefit is probably refreshing of problem markers on closed files.

Regards

Ed Willink

On 24/09/2012 15: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?!
>
> Marius
>

Previous Topic:	Exception when invoking a helper method
Next Topic:	[QVTo] Multiple Output Models

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Mar 21 23:16:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter