Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » QVT project organization
QVT project organization [message #1058860] Wed, 15 May 2013 08:51 Go to next message
Matteo M. is currently offline Matteo M.
Messages: 28
Registered: May 2012
Junior Member
Hello,

I was wondering what are the guidelines for managing complex projects in QVT.

In my project, I have a number of transformations each one with a bunch of mapping, query, helper operations. Should I create one file per transformation and put all the operation related to each transform in the corresponding file? Am I allowed (read: may be considered good practice) to create e.g. 4 files per transform, one for the main, one for all the mappings, the 3rd for queries and the last one for helpers?

How do you professionals manage your projects?

--
Matteo
Re: QVT project organization [message #1059297 is a reply to message #1058860] Wed, 15 May 2013 09:24 Go to previous messageGo to next message
Eclipse User
On 15.05.2013 14:51, Matteo M. wrote:
> I was wondering what are the guidelines for managing complex projects in
> QVT.
>
> In my project, I have a number of transformations each one with a bunch
> of mapping, query, helper operations. Should I create one file per
> transformation and put all the operation related to each transform in
> the corresponding file? Am I allowed (read: may be considered good
> practice) to create e.g. 4 files per transform, one for the main, one
> for all the mappings, the 3rd for queries and the last one for helpers?
>
> How do you professionals manage your projects?

If your transformations are indeed complex and at same time independent
of each other, then you might even consider putting them into different
projects. As of now, the QVT builder does not keep compile artifacts or
a build hierarchy, so when you touch any one file it has no choice but
to rebuild all of them. Depending on the complexity of your files this
can become a major nuisance. My experience suggests to have as few
physical files as possible, since each additional file adds up in making
the compile process slower.

[Disclaimer: I am aware that this advice may well conflict with other
best practices and in fact I don't like giving it. But in my own project
I have now reached a point where I have had to permanently turn off the
QVT builder as it just eats to much resources.]

Regards
Marius
Re: QVT project organization [message #1059298 is a reply to message #1059297] Wed, 15 May 2013 10:56 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4030
Registered: July 2009
Senior Member
Hi

I think that best practices are only starting to evolve as users get
more ambitious.

There are a number of Bugzillas regarding poor scalability of the QVTo
builder, some have been addressed recently and so Kepler should be better.

Unfortunately QVTo is not the only builder with suspicious enthusiasm. I
find other builders worse and disabling auto-build after any significant
GIT change very beneficial. Please raise a Bugzilla with clear deficient
scenarios.

Java encourages us to use deep wide package hierarchies.

EMF encourages us to use a simple model folder, and so perhaps just a
transforms folder. EMF JET templates have a bit more hierarchy.

IMHO the reuse of the Java layout by Acceleo is a good idea and will
evolve nicely when direct Java compilation materializes. So I encourage
you to try the Java src/x/y/z layout.

The OMG specifications define a Transformation as both a Package and a
Class and while packages can be nested the specifications tend to assume
that a Transformation is a root package, so you may need to push for
better tool support. For QVTr and QVTc and even OCL, I have been more
generous in the use of qualified names in the concrete syntax.

Regards

ed Willink

On 15/05/2013 14:24, Marius Gröger wrote:
> On 15.05.2013 14:51, Matteo M. wrote:
>> I was wondering what are the guidelines for managing complex projects in
>> QVT.
>>
>> In my project, I have a number of transformations each one with a bunch
>> of mapping, query, helper operations. Should I create one file per
>> transformation and put all the operation related to each transform in
>> the corresponding file? Am I allowed (read: may be considered good
>> practice) to create e.g. 4 files per transform, one for the main, one
>> for all the mappings, the 3rd for queries and the last one for helpers?
>>
>> How do you professionals manage your projects?
> If your transformations are indeed complex and at same time independent
> of each other, then you might even consider putting them into different
> projects. As of now, the QVT builder does not keep compile artifacts or
> a build hierarchy, so when you touch any one file it has no choice but
> to rebuild all of them. Depending on the complexity of your files this
> can become a major nuisance. My experience suggests to have as few
> physical files as possible, since each additional file adds up in making
> the compile process slower.
>
> [Disclaimer: I am aware that this advice may well conflict with other
> best practices and in fact I don't like giving it. But in my own project
> I have now reached a point where I have had to permanently turn off the
> QVT builder as it just eats to much resources.]
>
> Regards
> Marius
>
Previous Topic:Accessing stereotypes defined in SysML profiles with packages
Next Topic:[Announce] Eclipse QVT Operational 3.3.0 (Kepler) RC1 is now available
Goto Forum:
  


Current Time: Sat Aug 23 05:36:12 EDT 2014

Powered by FUDForum. Page generated in 0.05141 seconds