| Summary: | [Cleanup] GMF feature depends on JDT | ||
|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Antoine Toulmé <antoine> |
| Component: | General | Assignee: | Richard Gronback <richard.gronback> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | haeber, mfeldman, richard.gronback |
| Version: | 2.0 | ||
| Target Milestone: | 2.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Antoine Toulmé
What are the declared GMF dependencies in the BPMN modeler? From our feature: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.bpmn/features/org.eclipse.stp.bpmn.feature/feature.xml?root=STP_Project&view=markup <import plugin="org.eclipse.gmf.runtime.emf.core"/> <import plugin="org.eclipse.gmf.runtime.common.ui.printing"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.printing.render"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.printing"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.properties"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.providers.ide"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.providers"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.render"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.resources.editor.ide"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.resources.editor"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui"/> <import plugin="org.eclipse.gmf.runtime.emf.commands.core"/> <import plugin="org.eclipse.gmf.runtime.emf.core"/> <import plugin="org.eclipse.gmf.runtime.emf.ui.properties"/> <import plugin="org.eclipse.gmf.runtime.notation.providers"/> <import plugin="org.eclipse.gmf.runtime.common.ui"/> I guess it's time we provided a runtime feature to the release train, as update manager seems to just pick whatever feature it finds the dependent plug-ins are located in, and doesn't simply grab the required plug-ins you declare. How important is this for Europa? Can we switch our configuration in Ganymede to provide separate runtime and SDK features (like we have on our normal update site)? I also tried UML2 Tools and got the same result. I suspect there are users that won't want the JDT for UML modeling either. My understanding is that the problem is due to the fact that the GMF feature depends on feature "org.eclipse.emf" which on the other hand depends on JDT. The feature org.eclipse.emf is a container including all the various emf features and it would help if gmf could be more specific in what specific features it needs from emf. If there happens to be another maintenance release of europa, I would appreciate if that could be changed. I think, many people building GMF diagrams do this within a domain NOT specific to developers, and their users may get discouraged if there is too many "IDE-like" features, if you know what I mean. (In reply to comment #4) > My understanding is that the problem is due to the fact that the GMF feature > depends on feature "org.eclipse.emf" which on the other hand depends on JDT. > > The feature org.eclipse.emf is a container including all the various emf > features and it would help if gmf could be more specific in what specific > features it needs from emf. > > If there happens to be another maintenance release of europa, I would > appreciate if that could be changed. > > I think, many people building GMF diagrams do this within a domain NOT specific > to developers, and their users may get discouraged if there is too many > "IDE-like" features, if you know what I mean. > +1 that's what I meant by opening this bug. I don't there will a new maintenance release of Europa now, we will have to see what happens with ganymede. Reassigning to the runtime component. Anthony, is there a subset of the current org.eclipse.emf feature list that we can declare? Below is all that's included following the fine grained feature breakdown EMF did last year. I suspect the runtime doesn't require some of these:
<includes
id="org.eclipse.emf.common"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.common.ui"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.ecore"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.edit"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.edit.ui"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.ecore.edit"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.ecore.editor"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.codegen"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.codegen.ui"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.codegen.ecore"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.codegen.ecore.ui"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.converter"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.mapping"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.mapping.ecore"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.mapping.ui"
version="2.4.0.v200804012208"/>
<includes
id="org.eclipse.emf.mapping.ecore.editor"
version="2.4.0.v200804012208"/>
Review this for 3.4 Reassigning, as I'm making the same changes for bug 158805. Committed updated feature dependencies to R2_1_maintenance and HEAD for runtime and included notation features, as indicated. I also bumped the EMF version to 2.4.0 to align with actual plugin versions specified. [target cleanup] 2.2 M2 was the original target milestone for this bug [GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug |