Home » Archived » IMP » New release of IMP available on update site and downloads page
| New release of IMP available on update site and downloads page [message #520723] |
Sun, 14 March 2010 22:04 |
 Robert M. Fuhrer
Messages: 294
Registered: July 2009 |
Senior Member |
|
|
Hi All,
There's a new release of IMP available on the IMP update site:
http://download.eclipse.org/technology/imp/updates/
and, for those who prefer, as an archive, on the downloads page:
http://download.eclipse.org/technology/imp/
*** Please Note: ***
This release fixes a significant, though intermittent, installation problem that caused p2 to claim it couldn't find
some IMP bundle. In my testing, on platforms for which this actually manifested, the offending bundle was usually
"org.eclipse.imp.doc". Details below. [1]
========================
= New in this release: =
========================
- Fixes for memory leaks in the IMP runtime, which previously would maintain references to ASTs and token streams (via
the parser and lexer) after editors were closed. In short, various dispose() methods now do most (all?) of the things
they should.
- A number of miscellaneous small fixes to the runtime (e.g. null guards to handle various anomalous conditions).
- A fix for the recently-discovered race condition in the initialization of the IMP runtime.
- A number of fixes and updates to the meta-tooling, mostly to the templates, in order to update them to the latest
API, and avoid compilation warnings/errors in generated code.
- Enhancements for structured differencing (please see the previous email on the subject). There is no wizard as of
yet for this, so for now, you'll have to manually create an extension of org.eclipse.imp.compareNodeIdentifier.
- Changes to accommodate the recent change to the LPG runtime bundle ID (from "lpg.runtime" to "lpg.runtime.java").
The IMP runtime and other bundles now depend on the bundle "lpg.runtime.java", rather than "lpg.runtime". IMP now
distributes the LPG runtime feature as two bundles:
(1) the proper binary bundle with all the LPG runtime code, with ID "lpg.runtime.java",
(2) a "wrapper" bundle with ID "lpg.runtime", for backward compatibility with existing LPG clients.
- The LPG and PrefSpecs IDEs now support the "entity name locator" service (interface: IEntityNameLocator), so that
selecting an outline item causes the editor to select just the name, rather than the entire source extent, of a given
source entity (which looks a bit jarring).
- SimpleLPGParseController now implements the parse() method, and takes care of basically all of the necessary steps
to perform a parse of the supplied source text. As a result, most LPG-based IParseController implementations are *much*
shorter.
- Removed an unnecessary dependency of org.eclipse.imp.smapi (in the feature org.eclipse.imp.java.hosted) on JUnit.
- Removed an unnecessary dependency of org.eclipse.imp.box on org.eclipse.imp.smapi, which prevented installing the
"IMP Source Formatting" feature without the "Java Hosted" feature.
- Removed a bogus "<separator>" element from a popupMenus extension in org.eclipse.imp.lpg.ide, which caused runtime
errors in the error log.
- Added some missing license files.
============================================
= News for IMP developers and the curious: =
============================================
- Updated the "features.psf" and "plugins.psf" Team Project Sets in the various update/feature projects. The IMP
RelEng tools are once again capable of pulling down all the IMP source from a single gesture.
- The build scripts now use the bundle/feature meta-data to drive the whole build process, eliminating the per-feature
and per-plugin build scripts. The build.properties files are now consulted to determine what's part of the build (as it
should be).
- The build scripts have been refactored to separate common behavior from project-specific data, in order to make it
easier to use the build scripts for another project. [The X10DT project is currently using them, for example.]
- The build scripts can now be used on IMP source that lives outside an Eclipse workspace. Previously, they implicitly
required that the JDT builder had placed class files in the right places before the Ant script was run. Now, the Ant
script builds what it needs as it goes, and puts it in the right places for subsequent build steps to find. As a result,
the build scripts work properly in continuous integration environments like CruiseControl (which we're using internally).
- Update site (for Mac users): I found a fix for the problem that occurs when using Safari to view the update site
page: Safari complains that "the document could not be loaded". This was due to some inappropriate XSL-related
Javascript code that doesn't work under Safari. With the fix, you get a nicely-formatted listing of the update site's
contents.
[1] The install problem was caused by automatically-generated source bundles that had the same bundle ID as the
corresponding binary bundles. As a result, some times p2 would confuse the two, and when trying to install the binary
bundle, would be attempt to do so from the source bundle's jar, which obviously wouldn't work. It would have been nice
had p2 warned that the source bundle contained a different bundle ID than advertised via the bundle jar file name. I've
submitted a bug report to p2 related to this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=305174 The build scripts in
org.eclipse.imp.update have been fixed to prevent this bundle ID clash.
--
Cheers,
-- Bob
--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:46:13 GMT 2024
Powered by FUDForum. Page generated in 0.02573 seconds |
] 
Search
Help
Register
Login
Home
