EMF/EMF 2.3/Standalone Zip Removal

Request For Comment: Will anyone miss the EMF Standalone Zip?

With the advent of jarred plugins, improvements to Update Manager, and all the new smaller EMF 2.3 features (including 7 core "runtime" ones in Europa's Enabling Features category -- see bugs 106804 and 189295), the EMF team is evaluating if the Standalone Zip introduced in EMF 2.1 is still meaningful and useful to consuming teams, projects, and products.

Basically, aside from the directory tree differences, the Standalone Zip contains a subset of the EMF runtime features/plugins, plus translations. Since translations will not be provided for EMF 2.3 (because of the proposed Globalization Project, aka "Babel"), the standalone zip will only contain completely translated text for the parts of EMF that haven't been added or changed since 2.2.1 -- the rest will be English-only. If you're picking up this zip because it contains translations, consider this -- will it still be useful to you with this limitation?

If you're picking up this zip because of the way its contents are packaged, please let us know what it is about this format that's useful, and why a zip with Eclipse plugins/features is not *more* useful. If you download this zip for another reason, we'd like to know why -- really, just to know if we'd be crippling you by removing the zip from the available EMF 2.3 downloads.

Digging Deeper -- What's In The Zip?

Here's what's in the zip, in an emf/bin/ folder, along with a readme file and the accompanying image:

xsd.edit_2.3.0.v200705300200.jar 
xsd_2.3.0.v200705300200.jar 
emf.mapping.ecore2xml_2.3.0.v200705300200.jar 
emf.edit_2.3.0.v200705300200.jar 
emf.ecore.xmi_2.3.0.v200705300200.jar 
emf.ecore.sdo.edit_2.3.0.v200705300200.jar 
emf.ecore.sdo_2.3.0.v200705300200.jar 
emf.ecore.edit_2.3.0.v200705300200.jar 
emf.ecore.change.edit_2.3.0.v200705300200.jar 
emf.ecore.change_2.3.0.v200705300200.jar 
emf.ecore_2.3.0.v200705300200.jar 
emf.commonj.sdo_2.3.0.v200705300200.jar 
emf.common_2.3.0.v200705300200.jar 

SDK & Runtime Zips

In the SDK and runtime zips, these jars are in eclipse/plugins/, and include their accompanying features, plus OSGi bundle info and extra runtime stuff (like plugin.xml, schemas, and model files). Taking org.eclipse.emf.ecore_*.jar for example:

vs.

File:EMF23StandaloneZipImg2.gif

Standalone Zips

In the standalone, the jars are just Ant-build jars with nothing more than classfiles, about.html, and a much simplified MANIFEST.MF, whereas the SDK and runtime jars are OSGi bundles.

What's the Difference?

If you're running the jars with "plain" java (setting the classpath manually) the difference between the manifest files shouldn't cause any change in behaviour. However, if you're running the jars in an OSGi environment (such as the latest Websphere App Server or other Eclipse-based tool), the OSGi settings in the manifest file of the jarred plugins will be "activated". Since EMF exports all the packages and doesn't do any fancy with OSGi, this too shouldn't cause any difference.

The standalone also includes translations in a nested plugin folder.

Using OSGi Bundles Standalone

To further clarify the fact that you can effectively swap out the old standalone zips for the new OSGi bundles, I've created a sample application that uses XMLProcessor to create an in-memory EMF model from an XML Schema document, then validates an instance of that model (an xml file) to ensure it conforms to the model spec. It's attached here. For the curious, this is a slight variation on the code used for generating/validating RSS Feeds for Eclipse project builds.

Outcome

As there were no major objections to this idea posted in bug 191837, the decision was made to remove the Standalone Zip from EMF 2.3. See bug 191837 for more information.