|
| Re: QVT project organization [message #1059297 is a reply to message #1058860] |
Wed, 15 May 2013 13:24   |
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 14:56 |
 Ed Willink
Messages: 7655
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
>
|
|
|
Powered by
FUDForum. Page generated in 0.02062 seconds
] 
Search
Help
Register
Login
Home
