[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2m-atl-dev][ATL] API changes in HEAD
|
Hello William, ATL commiters,
I've seen the changes in CVS HEAD: I haven't been able to merge the
ATL_Dynamic_ResourceSet branch back into HEAD, because of the major
architecture change. The crux of the problem lies here:
* AtlModelHandler changed into ModelFactory
* ModelLoader disappeared, and is more-or-less replaced by IInjector
In order to work with disposable ResourceSets, I've changed
AtlModelHandler to create disposable ModelLoaders. These ModelLoaders
then add models to their internal model set, which is a ResourceSet in
case of EMFModelLoader. At the end of an ATL run, the ModelLoader is
disposed, together with the internal model set (ResourceSet).
In the new architecture, ModelFactories and IInjectors are singletons
that are registered in CoreService. This ensures that the same
ResourceSet is used for all loaded models in LauncherService. However,
it is only necessary to use the same ResourceSet within one execution of
LauncherService.launch().
I short: there is no model creator/loader class in the current
architecture of which the instances lives only for the duration of
LauncherService.launch() *and* is common for all IModels of a particular
kind involved (e.g. EMFModel) in the launch.
It's impossible to continue the dynamic ResourceSet effort now without
the help of the other ATL committers, especially William ;-). The
current architecture follows a different approach to solving the filling
ResourceSet problem: cleaning out the static ResourceSet every now and
then. In a following mail, I'll try to make the argument why dynamic,
disposable ResourceSets are better than doing housekeeping on a static
ResourceSet.
Cheers,
Dennis
William Piers schreef:
Hi ATL commiters,
As I have said to Dennis last week, I plan to commit several changes
on the HEAD branch in order to prepare the next ATL version. These
changes mainly consist of an API, which centralizes ATL launch
utilities. The initial goal of this work was to decouple ATL VM and
UI, and to provide a generic API for both RegularVM and EMFVM
launching in order to avoid rewriting the same tools for both VMs.
Here are the main new features:
* EMFVM & RegularVM compatibility
* in-place refining mode support
* injectors, extractors, model extensibility
And here is what will come soon:
* atl ant tasks, based on old AM3 ant tasks
* atl command line utility
* programmatic launch examples, based on the new api
As explained here:
http://wiki.eclipse.org/index.php/Version_Numbering#When_to_change_the_major_segment
The next ATL release will be 3.0.0, as the new API replaces some old
launch utilities.
Here are the changes in ATL source code:
* 4 new plugins:
o org.eclipse.m2m.atl.core: the api definition and tools
o org.eclipse.m2m.atl.core.emf: the api specification for EMF
o org.eclipse.m2m.atl.core.ui: the api launch
configuration definition (was initially in
org.eclipse.m2m.atl.adt.debug)
o org.eclipse.m2m.atl.core.ui.vm: the api adapter
launching the RegularVM
* 3 plugin change:
o org.eclipse.m2m.atl.adt.debug: removed all launching
packages, now this plugin is dedicated to debug the RegularVM
o org.eclipse.m2m.atl.engine.emfvm: adapted to the new API
o org.eclipse.m2m.atl.tests: adapted to the new API
There are also changes at the ADT level, as I merged some plugins into
one and reorganized UI features:
* 2 new plugins:
o org.eclipse.m2m.atl.adt: was initially
org.eclipse.m2m.atl.adt.builder
o org.eclipse.m2m.atl.adt.ui: perspective, wizards
* 4 unused plugins, which will be removed
o org.eclipse.m2m.atl.adt.builder
o org.eclipse.m2m.atl.adt.wizards
o org.eclipse.m2m.atl.adt.perspective
Feel free to comment about these changes and give your opinion!
Best regards,
William
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev