[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] Project synchronization
|
Hi Ed,
Some questions/thoughts, from my own (as QVTo project developer)
perspective:
- I currently only know about QVTd Eclipse official git repos and I dont
not know about any QVTd development layout which relies on external
repos. I hope not to need to be aware of it ;).
- I'd like not to be pending on external repositories so if you manage
to provide me a proper branch (an updated master or an specific one)
every milestone is OK to me. However, if we wait until Milestone week to
integrate QVTd code into the official repos, I'd bet for having a lot of
problems. We should start the integration, at least, one week before.
- In principle, I don't expect to be very impacted by QVTd changes. I
think that current dependencies are more related to dependencies in the
language (relations refinements), which are not supported by the current
QVTo project. So, unless the language changes I hope not be broken by
QVTd changes. Anyway, I still have to do a more deep insight in the project.
- Could you provide some OCL examples (code line numbers) of new code
which relies on the old one to better understand the problem you mention ?
Cheers,
Adolfo.
On 20/01/2013 10:36, Ed Willink wrote:
Hi Horacio, Adolfo
I've just been building Horacio's latest GitHub code and encountering a
little difficulty.
It doesn't build against master or M4. M3 has trivial @NonNull issues.
M2 is needed.
The problem is that I have evolved the mutation 'API' to support code
generated execution:
That is: Type.createInstance(), Property.initValue() have changed.
For these particular methods I should have provided delegating methods
and deprecation. Will rectify for M5.
More generally, evolution of Xtext grammars or the Pivot model tends to
require a bidirectional compatibility, so that old calls to A delegate
to the new A, but also so that new calls to A somehow call old
derivations of the old A. This is difficult and messy, if not actually
impossible. The effort in maintaining the mess is greater than migrating
to the new code in the first place.
Expecting your code to adapt instantly to OCL, QVTd master is clearly
unrealistic.
I suggest that we endeavour to synchronize code as soon as practical
after each milestone release, so today Horacio's QVTd code should using
an OCL branch corresponding to the Kepler_M4_Tools tag and QVTd
corresponding to the Kepler_M4 tag.
Before each OCL, QVTd milestone, I'll check for any missing deprecated
delegations that preserve compatibility. I'll look to remove deprecated
delegation one milestone later.
We'll need to see if there is anything that we can do to improve
Xtext/EMF auto-generated code stability, since once this code is
promoted from examples any changes will be a public API challenge rather
than an informal difficulty for the QVT teams.
Regards
Ed
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev
