Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-atl-dev] New ATL adopters

Hi Martin,

That's great news! I suppose Frédéric can best explain how to go about the documentation bit, so I'll leave that to him ;-). You also gave some technical remarks, which I'd like to comment on below:

Martin J Bartlett schreef:
Hello guys.

We're using ATL at CSC - we'll be using it extensively eventually in a new
MDD based product.

Now, in the KINDEST possible voice and with the greatest possible respect
for your technical acheivements with ATL, we, by common accord at CSC, have
to say that the documentation sucks! Sorry for the strong term, but it
really does. If you are open to assitance I offer mine: I am a) a very
competant English technical writer, b) a big fan of what ATL can do (as far
as we have gone with it) and c) living permanently in Paris (and,
consequently, perfectly able to read French and write English like a native
- dont ask me to try the other way round though :-)).

Secondly, a mundane bug report on the latest sources that we are working
from (where should I post this normally): Line 146 of
org.eclipse.m2m.atl.engine.AtlEMFModelHandler reads:

IFile file = ResourcesPlugin.getWorkspace().getRoot().getFile(new
Path(uri.path()));

this is not good, however, when running transforms outside of Eclipse. The
ResourcePlugin is not active in such circumstances, so the call to
getWorkspace results in an IllegalStateException. The call should be
surrounded by guard code. Unfortunately, the only way I can find of
checking if the workspace is valid without throwing an exception is to call

ResourcesPlugin p = ResourcesPlugin.getPlugin();

which at least will show if the plugin itself has been started (which it
won't have been in non-Eclipse environments)

Another (possibly better) approach might be to remove the Eclipse platform
specifics which are not necessary.

Current CVS code has a guard block around this code, as per your suggestion. See also the following 2 bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197797
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202069

If it does not work for you, or you find additional places in the code that need this fix, please report it in bugzilla :-).


Thirdly, exception handling.  Any chance of getting ATL to pass Exceptions
much higher up the call chain rather than reporting everything to the
console at a low level?

This should be handled by the debugger object. The default SimpleDebugger class uses the continueAfterErrors attribute, for example, to influence the control flow in case of an exception.

The ATL visual debugger uses the NetworkDebugger class to communicate exceptions and influence control flow.

Both debugger implementations log exceptions to the java.util.logging framework, regardless of how the exception is handled otherwise.


Headless operation - We have successfully built some tooling/hacks that
allow the dynamic transformation of incore ecore models - that is we bypass
the file IO veneer that ATL has and go straight to the ASMModel creation
with an existing ecore Resource, and then take the "extent" from the output
ASMModel and go and work with that. Is there work within the ATL project to
do similar - or are we trail blazing? (Note that the ResourcePlugin and
exception issues mentioned above derive from this integrated headless
operation).

Best way to find out you're working on the "edge": always use ATL from CVS HEAD. About integrating ATL with an MDD tool: I'm guessing that TopCased and Papyrus had to do similar stuff when calling ATL on models that are being edited.


Here's hoping that we (and I) can be come very active in helping to develop
ATL.

Martin Bartlett

Senior Technical Consultant
CSC Financial Services SAS
Registered Office: 14 Place de la Coupole, Axe Liberté, 94220 Charenton Le
Pont, France
Registered in France: RCS Créteil B 323 127 332

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev


--
Cheers,
Dennis



Back to the top