|Re: [AM3][ATL] Experiences getting ATL/AM3/TCS running from CVS [message #381855]
||Fri, 04 April 2008 15:47
| Frédéric Jouault
Registered: July 2009
Your problem seems to be similar to the issue discussed in the following
ATL HEAD has been stabilized so as to be released with Ganymede.
AM3&TCS depend on branch R2_1_0_dev of ATL.
Once the latest CVS version is stable enough, we will make a Project Set
File (http://wiki.eclipse.org/PSF) available. This file will be usable
to check out ATL, TCS, and parts of AM3 still used by TCS.
Note that if you only want to use ATL, you can simply use the version
that is released with Ganymede.
Richard Eckart a écrit :
> Hello folks,
> three days ago I came across ATL and wanted just to try it out. Since I
> could not get all necessary components (ATL, AM3 and the TCS editor)
> from an update site, I resolved to check everything necessary out from
> CVS and build it on my own.
> It took me three nights to get the stuff running in a second Eclipse
> instance and a lot of debugging the classloader action, so I thought I
> should share my finds. I hope I did not forget anything in the following
> list which is reconstructed from memory and by looking at the diff
> between my workspace and the CVS:
> - First I found org.eclipse.m2m.atl.dsls included an outdated version of
> the org.eclipse.gmt.tcs.extractor/injector packages still expecting
> TCSInjector while the code calling it was passing in a TCSRuntime
> I checked out AMMACore and AMMAScript to be able to use the build.xml
> provided in org.eclipse.m2m.atl.dsls to update the package to the
> latest versions of extractor/injector and update the ASMs at the same
> - Thereafter I found org.eclipse.m2m.atl.engine had the same problem
> (TCSInjector instead of TCSRuntime). I ended up updating the
> respective jars there as well and had to update the ATL_Parser.jar
> there as well (took the one from org.eclipse.m2m.atl.dsls.
> - Now I had problems with the outline view. I needed to update
> org.eclipse.m2m.atl.services.core/ServiceTransformationUtil. java from
> branch 184.108.40.206 to resolve TCSInjector issues.
> - Last I could not use Inject KM3 to Ecore because it was unable to
> locate the org.eclipse.gmt.tcs.injector.KM3_ANTLR3* classes. This is
> because the parser/lexer classes are in the same package which also
> houses TCSRuntime, but TCSRuntime and the parser classes are exported
> by different bundles (namely org.eclipse.m2m.atl.dsls and
> Equinox cannot handle merging exports of the
> same package from different bundles - no way. I tried buddy exports,
> boot loading, whatever and finally found that there is no way and it
> is good so because otherwise one may end up with a bad mix of
> different versions of class files at runtime. I resolved to put a
> copy of KM3-parser.jar into the org.eclipse.gmt.am3.dsls.km3 bundle.
> Before I tried the above, I thought if might be a good idea not to have
> the injector/exporter packages jarred up add all - why not simply depend
> on the bundles. When I tried that, it introduced a cyclic dependency! It
> seems that the bundles are not cut very well here. Similar goes for the
> parser/lexer classes which I believe should be moved to their own
> bundles so they can be used from multiple places. Furthermore I believe
> the parse/lexer classes should be moved to a package
> org.eclipse.gmt.tcs.injector.XXX where XXX would be ATL, KM3, etc. and
> should be either moved to their own bundles thereafter to be usable by
> different other bundles or may be included in various other bundles but
> they must not be exported by those to avoid classloader confusion at
> Hope this was a helpful analysis.
> I am not sure if this went to the right newsgroup. I did not want to
> start cross-posting. If this is relevant to other newsgroups, please
> somebody forward it or tell me to post it there.
Powered by FUDForum
. Page generated in 0.02025 seconds