Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EMF/EMF 2.3/Standalone Zip Removal"
(New page: == 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...) |
m |
||
| Line 1: | Line 1: | ||
| − | |||
== Request For Comment: Will anyone miss the EMF Standalone Zip? == | == Request For Comment: Will anyone miss the EMF Standalone Zip? == | ||
| Line 26: | Line 25: | ||
emf.common_2.3.0.v200705300200.jar | emf.common_2.3.0.v200705300200.jar | ||
| − | [[Image:]] | + | [[Image:EMF23StandaloneZipImg1.gif]] |
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: | 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: | ||
<table><tr valign="top"> | <table><tr valign="top"> | ||
| − | <td>[[Image:]]</td> | + | <td>[[Image:EMF23StandaloneZipImg2.gif]] |
| + | </td> | ||
<td>vs.</td> | <td>vs.</td> | ||
| − | <td>[[Image:]]</td> | + | <td>[[Image:EMF23StandaloneZipImg3.gif]] |
| + | </td> | ||
</tr></table> | </tr></table> | ||
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. 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. | 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. 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. | ||
| − | [[Image:]] | + | [[Image:EMF23StandaloneZipImg4.gif]] |
The standalone also includes translations in a nested plugin folder. | The standalone also includes translations in a nested plugin folder. | ||
Revision as of 23:28, 9 June 2007
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, the standalone zip will only contain completely translated text for the parts of EMF that haven't been added or changed since 2.2 -- 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
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:
| File:EMF23StandaloneZipImg2.gif | vs. | 
|
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. 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.