[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] Project synchronization
|
Hi Adolfo
As you expect the QVTo dependencies on QVTd are non-existent at present,
except for the unused m2m.qvt.oml.ecore.qvtoperational model plugins,
that dependent on the old qvtbase etc.
Horacio's work in GitHub is almost entirely related to evaluation and
optimization thereof so does not affect the main Eclipse-hosted QVTd
where I support the models and editors. There may be very small model
changes to facilitate Horacio's work, but evolution to track OCL pivot
evolution towards UML and efficient code generation is the main drift.
Once QVTo moves to align with the pivot we again hit the problem that
qvtbase is in QVTd. Since QVTo is the mature project, it may be more
pragmatic to move qvtbase to QVTo, rather than create a new
qvtbase+imperativeocl project. Except that qvtoperational has two
obscure dependencies on qvtrelational; perhaps we could make
OperationTransformation.refined/relation, which are currently
RelationalTransformation/Relation, more abstract as Transformation/Rule
and put an end to the fiction that QVTo and QVTr are related. QVTo would
then be independent of QVTd, and QVTd would depend only on QVTbase from
QVTo.
--
The migration problem occurs when pivot.Nameable migrates to
domain.Nameable; with a compatibility for the deprecated pivot.Nameable
extends domain.Nameable. So all old code working with the old
pivot.Nameable continues to work, in particularly an instanceof check.
No problem yet. However once auto-generated code starts to generate
model elements that inherit from domain.Nameable and eliminate the
deprecation warning from the old inheritance from pivot.Nameable, code
breaks.
Migration has to be three phase:
a) introduce the new domain.Nameable with deprecated pivot.Nameable
extension
b) replace all references to pivot.Nameable by domain.Nameable
c) migrate pivot.Nameable inheritances to domain.Nameable
c) cannot safely start till b) is complete. A compatibility method
cannot be just left lying around to catch old code.
Regards
Ed
On 21/01/2013 10:58, Adolfo Sanchez-Barbudo Herrera wrote:
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
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2639/6045 - Release Date: 01/20/13
