Community
Participate
Working Groups
From http://dev.eclipse.org/mhonarc/lists/emf-dev/msg00602.html Given the complete silence about terminating SDO, which I interpret as a complete lack of interest in it, I personally think it would be best to remove SDO from Ganymede with an eye to terminating it gracefully. To facilitate this, we need to split the SDO build from the EMF/XSD build. I also don't think it's acceptable that the older builds break as a result of physically removing SDO from CVS though, so I still need to talk to the foundation about a more graceful termination process than what was done with EODM, for example. Unfortunately (or fortunately depending on the perspective), eliminating SDO seems to involve more work than keeping in on artificial life support. The SDO plan theme is "Pull Back" and includes this commentary: The EMF SDO project has gained little traction. It may well make sense to phase out support for SDO. We'll discuss with the community to determine if there is any reason to provide builds for this release or in the future. At best we will make only minimal changes to stay current with the platform and EMF Core. Maintenance builds are still important to some clients. So if there is a community out there who cares about SDO, they need to step forward to express their interest... Cheers, Ed
It's funny to consider this an enhancement. It's more of a dehancement. :-P
Comment #1 says "best to remove SDO from Ganymede" - that should be "Galileo" I presume. Can someone define or point to a definition of what "termination of a project" means? For those with code based on earlier releases which include SDO, we need to understand how maintenance of that software is affected. I'd like to understand the full implications. What would not be possible after this action?
Steve, Sorry for the Ganymede verses Galileo typo. :-P I've been trying to talk to the foundation folks about a more gradual form of termination than "delete everything about SDO from CVS including the whole history" as was done with EODM, for example. Deleting SDO from CVS would make it impossible to produce a Ganymede SP2 release, which I think is clearly unacceptable. A more reasonable approach would be to leave SDO in CVS but to remove it from the next release train, with an eye to eventually deleting it from CVS. Or perhaps letting it wither up and blow away when the next strong gust of wind comes by... The problem is of course that the "eventually" part seems to involve a very large number of years from an IBM perspective. Of course I don't care to do anything disruptive in the commercial ecosystem, but I also see pretty much zero value in keeping SDO on life support ad infinitum when the user base is practically non-existent.
(In reply to comment #3) > > I've been trying to talk to the foundation folks about a more gradual form of > termination than "delete everything about SDO from CVS including the whole > history" as was done with EODM, for example. Ed, can you post any information you find regarding a more gradual form of termination to bug #249408?
Just a FYI, when we move or EOL projects, we ask the webmaster to mark them as read only. Thus when we need to run a build from a release from a few years ago, the history and tags are still there to make that possible. At the same time, when someone tries to commit to the old stream, they are unable to do so because that portion of the repository is ready only. This is the approach that was taken when moving the Equinox projects from Eclipse to the RT top level project.
(In reply to comment #5) > Just a FYI, when we move or EOL projects, we ask the webmaster to mark them as > read only. Thus when we need to run a build from a release from a few years > ago, the history and tags are still there to make that possible. At the same > time, when someone tries to commit to the old stream, they are unable to do so > because that portion of the repository is ready only. This is the approach that > was taken when moving the Equinox projects from Eclipse to the RT top level > project. > We also deleted all content from HEAD for the equinox move. If we don't think there will be any new major releases (only possible point or maintenance releases) then there is no reason to keep the code in HEAD. In Equinox we made the old repository read-only and we removed all the content from HEAD (leaving all the old tags and branches intact). This way if we need to reproduce an old build it is still possible. Also, if someone in the community decides to resurrect the project they can go to the last tag available and get the code. I think this addresses Steve's concerns from comment 2 about maintaining old releases. This assumes the concerned party needing the fix will step up with resources to release, support and test the new maintenance build. My understanding in the case of SDO is that all existing committers are decommitting from SDO and will not be available to maintain the code.
Thanks Kim and Tom for the helpful advice! Given the complete lack of response from any type of SDO community, I definitely conclude that SDO is not needed in Ganymede. I'd like to remove it from the EMF/SDO/XSD build and simply stop building it. Later I'd like to take the steps of freezing the CVS module, when there is no outcry about it having disappeared. Steve/Dave is there any reason not to take those steps? Nick, I'll need your help! No matter what, I want an EMF/XSD build that does not depend on SDO...
(In reply to comment #7) > Nick, I'll need your help! No matter what, I want an EMF/XSD build that does > not depend on SDO... Steps to deSDOify the EMF-SDO-XSD build: 1. change all-in-one feature to not include SDO SDK feature 2. change EMF tests to exclude anything that tests SDO 3. change testManifest.xml & testManifest.xml.template to remove SDO tests 4. change buildAll.xml to no longer repackage the SDO-including zips 5. tweak web UI so that new "emf-xsd-" prefixed zips (which replace "emf-sdo-xsd-" prefixed zips) will appear on the downloads page 6. tweak web UI so that old sdo zips are not listed as "missing" or "in progress" but rather optionally built (ie., silently ignored on downloads page when they don't exist, but are still shown for older releases) I'm prolly forgetting something, but that's the general gist.
Ed, Are you proposing to add a separate SDO build? Or are you leaving that to whomever wants to build SDO in the future?
Dave, Given the complete lack of responses, I'm inclined to start out assuming that no one cares about having an SDO build. So yes, I choose door number two.
Created attachment 116724 [details] Changes needed in EMF to remove SDO dependencies We can delete the SDO test and the performance test doesn't appear to be useful anyway and even less so with the SDO stuff removed, so I think we should delete it. We can leave the SDO stuff in head for the time being, in case someone shows up wanting to set up a build for it. We'll apply this changes after M3 is out the door to give us plenty of time to get the build fixed when no doubt we break it.
Just to be sure that I understand that correctly: would that mean removing the SDO implementation from EMF only? The one in EclipseLink would be unaffected?
Created attachment 116799 [details] Updates to previous patch This includes changes to the "all" feature.
Gerald, Yes, only EMF's implementation of SDO is being targeted for removal.
One more question for Nick: will our build still include SDO in the maintenance branches? My reading was that we were talking about changes for HEAD only, and since we're only removing the SDO tests there, presumably we'd need to keep building SDO in the other branches. Still, that hasn't been stated explicitly yet, so I thought I'd ask.
Yes, I don't want to break older streams. Obviously we can't pull this from Ganymede, for example...
Yes, in HEAD only, the plan is: a) stop building some sources (remove from map & all-in-one feature), b) exclude SDO stuff from test suites (once the patches in this bug are committed), and c) change packaging to exclude SDO from zips and update site.
Ed's changes look good to me, but I notice there are still a few passing references to SDO left behind: - the org.eclipse.emf.all feature description - filtering of "org\.eclipse\.emf\.ecore\.sdo\.editor/.*" in the plugin.xml of org.eclipse.emf.activities - a comment in the antJavadoc.sh script in org.eclipse.emf.doc and org.eclipse.xsd.doc Also, all the generator support is left untouched. It appears safe to say that was done intentionally, and I fully support it. If nothing else, it serves as an example of how to use numerous otherwise cryptic generator options.
Oh, I should add a thanks to all for your patience on this. I'm glad for having had the chance to review it, and I'm much more comfortable with the passage of time that these changes aren't going to take people by surprise.
Created attachment 119102 [details] remove SDO and obsolete templateGen folder one big patch! Only remaining reference to "sdo" appears in .releng/builder/zips/jars.mdl, which does not seem to be packaged into the models.zip, and nl.zip, which is afaik a throwback to EMF 2.2
Created attachment 119103 [details] split .psf files so emf-xsd and sdo are separate; remove sdo refs from other files
Created attachment 119104 [details] remove SDO from tests
Build is running w/o SDO. However, o.e.e.test.common still declares dependency on sdo and exports sdo models, so the build fails. [emf.build.SetRequiredBundleVersionRanges] Analyzing '/home/www-data/build/emf/downloads/drops/2.5.0/N200812010159/eclipse/plugins/org.eclipse.emf.test.common/META-INF/MANIFEST.MF' /home/www-data/build/emf/downloads/drops/2.5.0/N200812010159/org.eclipse.emf.releng/builder/tests/customTargets.xml:89: Unable to find the version of 'org.eclipse.emf.ecore.sdo'. --- Require-Bundle: org.eclipse.core.runtime, ... ** org.eclipse.emf.ecore.sdo,** ... Export-Package: org.eclipse.emf.test.common, ... org.eclipse.emf.test.models.sdo.library, org.eclipse.emf.test.models.sdo.library.impl, org.eclipse.emf.test.models.sdo.library.util, org.eclipse.emf.test.models.sdo.simple, org.eclipse.emf.test.models.sdo.simple.impl, org.eclipse.emf.test.models.sdo.simple.util, ... Dave/Ed, what's the next step here?
Build is now happy. Moving to Fixed so this will be picked up in tonight's build.
Fix available in HEAD: 2.5.0.I200812022320.
Fix available in HEAD: 2.5.0 (R200906151043).
We are going to migrate from EMF 2.3 to 2.5. We have several hundreds of classes which are using SDO (EDataObject). Is there any migration guide how to pull out or replace SDO ? Thank you.
No, there's no migration guide. You could create a new GenModel for your Ecore model and regenerate from that, or remove the SDO-specific settings from your GenModel and regenerate. Organize Imports... will remove any unused imports that remain.
