Bugzilla – Full Text Bug Listing
| Summary: | UML2 runtime feature has many dependencies and includes too many unnecessary plugins for clients wanting only to use UML API to create/manipulate UML models | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Nicholas Bennett <nbennett> | ||||||
| Component: | Core | Assignee: | Christian Damus <give.a.damus> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P2 | CC: | bruck.james, eclipse, Kenn.Hussey, nboldt | ||||||
| Version: | 2.2.0 | Keywords: | plan | ||||||
| Target Milestone: | M5 | Flags: | give.a.damus:
luna+
Kenn.Hussey: review+ |
||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | Community Support | ||||||||
| Attachments: |
|
||||||||
|
Description
Nicholas Bennett
We'll have to assess the impact of making these changes, seeing as we are already past API freeze (and some might argue that features are considered "API"). ...A first stab at the issue... Instead of breaking up the UML plugins into many features such as what EMF does, I would propose the following breakup. 1. A core runtime features with the following plugin dependencies -org.eclipse.uml2 -org.eclipse.uml2.uml -org.eclipse.uml2.uml.resources -org.eclipse.uml2.common 2. Keep the existing Doc feature with the following plugin depdencies. -org.eclipse.uml2.doc. 3. Keep the existing Examples feature. -with dependencies on the examples source and plugins. 4. The SDK feature would depend on the following features. - The Doc feature. - The Source code. - The Core feature. - The editor/edit plugins - the exporter/importer plugins. 5. Have an "all" feature which includes... - The UML sdk feature - The UML examples feature. Alternatively, we could further split the SDK feature but there doesn't seem to be a need for it right now. For example, we could have a feature for the edit plugins which include common.edit, uml.editor, uml.edit etc. (In reply to comment #2) > 1. A core runtime features with the following plugin dependencies > -org.eclipse.uml2 > -org.eclipse.uml2.uml > -org.eclipse.uml2.uml.resources > -org.eclipse.uml2.common org.eclipse.uml2 is a branding plug-in that belongs with the runtime feature; in general, each feature needs a branding plug-in. Also, I think that the common plug-ins need to be broken out because they can be used independently of the rest of UML2, e.g. by metamodels generated with the UML2 code generator that used subsets, redefinitions, and/or derived unions. > 2. Keep the existing Doc feature with the following plugin depdencies. > -org.eclipse.uml2.doc. OK. > 3. Keep the existing Examples feature. > -with dependencies on the examples source and plugins. OK. > 4. The SDK feature would depend on the following features. > - The Doc feature. > - The Source code. > - The Core feature. > - The editor/edit plugins > - the exporter/importer plugins. What about examples and codegen? > 5. Have an "all" feature which includes... > - The UML sdk feature > - The UML examples feature. We probably can't change the content of the current runtime and SDK features; we can break pieces of them out into smaller features, but at the end of the day, I think the content of these features needs to remain the same. > Alternatively, we could further split the SDK feature but there doesn't seem to > be a need for it right now. For example, we could have a feature for the edit > plugins which include common.edit, uml.editor, uml.edit etc. I would suggest a breakdown something more like this instead: org.eclipse.uml2.codegen.ecore.ui-feature >org.eclipse.uml2.codegen.ecore >org.eclipse.uml2.codegen.ecore.ui org.eclipse.uml2.common.edit-feature >org.eclipse.uml2.common >org.eclipse.uml2.common.edit org.eclipse.uml2.uml.edit-feature >org.eclipse.uml2.uml >org.eclipse.uml2.uml.edit >org.eclipse.uml2.uml.resources org.eclipse.uml2-feature >org.eclipse.uml2.codegen.ecore.ui-feature >org.eclipse.uml2.common.edit-feature >org.eclipse.uml2.uml.edit-feature >org.eclipse.uml2 >org.eclipse.uml2.uml.ecore.importer >org.eclipse.uml2.uml.ecore.exporter >org.eclipse.uml2.uml.editor org.eclipse.uml2.tests-feature >org.eclipse.uml2.tests >org.eclipse.uml2.uml.tests org.eclipse.uml2.doc-feature >org.eclipse.uml2.doc org.eclipse.uml2.examples-feature >org.eclipse.uml2.examples >org.eclipse.uml2.examples.uml.ui >org.eclipse.uml2.examples.source org.eclipse.uml2.sdk-feature >org.eclipse.uml2-feature >org.eclipse.uml2.doc-feature >org.eclipse.uml2.examples-feature >org.eclipse.uml2.source If there's a need to separate the edit plug-ins from the API plug-ins, we could further break down org.eclipse.uml2.common.edit-feature and org.eclipse.uml2.uml.edit-feature... Created attachment 98336 [details]
features subdirectory zipped
First stab at issue.
Created attachment 98337 [details]
patch version
(In reply to comment #4) > Created an attachment (id=98336) [details] > features subdirectory zipped > > First stab at issue. > Note that the "branding" plug-ins will need to have the requisite branding files added to them, i.e. about.ini, about.mappings, about.properties, modeling32.png. (In reply to comment #5) > Created an attachment (id=98337) [details] > patch version > I can't use this patch... Note that, rather than removing the existing features from the 'plugins' folder and adding them to the 'features' folder, they should probably be moved (on the server) so as to preserve CVS history. Given that the M7 (feature freeze) build will take place on Monday (May 5), I don't think it's realistic to try to get this feature into the 2.2 release; the request should have come in during the planning process. Note that, in light of p2, features will be much less significant/meaningful than they used to be, so this shouldn't be a blocking issue. Note also that nothing prevents the client from defining their own feature(s) as a workaround... As much as I would like to squeak this in now (and we have a patch), I find it difficult to disagree with Kenn's comment about it being late in the cycle. We are 1 day away from a stable M7 build and would need time to ensure that this does not negatively impact our builds. I agree that this should be introduced in the next release. Nick, for your planning, the next Milestone build in the next release will be sometime in September 2008 at which time UML2 3.0 will be introduced. Unsetting target milestone until planning for 3.0 is done. Too bad this ended up missing 3.0 as well. IMHO, James division made more sense. I am curious why you guys saw that the edit plug-in should go along with the API. Of course, my viewpoint is from someone building a tool that reads and generates UML models in batch mode. org.eclipse.uml2.uml, org.eclipse.uml2.uml.resources and org.eclipse.uml2.common is all I care about. But anything breakdown that allows me to use UML2 without requiring JDT will make me happy. (In reply to comment #11) > Too bad this ended up missing 3.0 as well. Yes, I'm disappointed as well. :( > IMHO, James division made more sense. I am curious why you guys saw that the > edit plug-in should go along with the API. Of course, my viewpoint is from > someone building a tool that reads and generates UML models in batch mode. > org.eclipse.uml2.uml, org.eclipse.uml2.uml.resources and > org.eclipse.uml2.common is all I care about. The goal, if/when we do this, would be to follow a strategy similar to the one EMF used when it was partitioned into fine-grained features... Of course, we would aim to arrive at a set of features that makes sense to all of the UML2 communities (vendors, developers, users)... (In reply to comment #13) > The goal, if/when we do this, would be to follow a strategy similar to the one > EMF used when it was partitioned into fine-grained features... Of course, we > would aim to arrive at a set of features that makes sense to all of the UML2 > communities (vendors, developers, users)... The only way you'll ever make everyone happy is if you have essentially one feature per plugin, with features that group other features into logical chunks. Then you'll satisfy the minimalists AND those who want everything with a couple clicks and don't care about the resulting footprint or if they end up with more than they need. This is why EMF has tiny features, a runtime feature, an SDK feature, and an all-in-one (EMF+XSD) feature. -- Of course these days w/ p2, you only need features if you explicitly want to install something from UML2; if you DEPEND on something in UML2, p2 can find and install the plugins w/o needing any features at all. Just add the update site, and p2 will do the dependency resolution and install. I have published a new branch bugs/227616a which refactors the current features as outlined by Kenn in comment #3. The new feature structure on the branch is thus: feature org.eclipse.uml2.sdk feature org.eclipse.uml2 feature org.eclipse.uml2.common bundle org.eclipse.uml2.common bundle org.eclipse.uml2.types feature org.eclipse.uml2.common.edit bundle org.eclipse.uml2.common.edit feature org.eclipse.uml2.codegen.ecore.ui bundle org.eclipse.uml2.codegen.ecore bundle org.eclipse.uml2.codegen.ecore.ui feature org.eclipse.uml2.uml bundle org.eclipse.uml2.uml bundle org.eclipse.uml2.uml.profile.l2 bundle org.eclipse.uml2.uml.profile.l3 bundle org.eclipse.uml2.uml.resources feature org.eclipse.uml2.uml.edit bundle org.eclipse.uml2.uml.edit bundle org.eclipse.uml2 bundle org.eclipse.uml2.uml.ecore.exporter bundle org.eclipse.uml2.uml.ecore.importer bundle org.eclipse.uml2.uml.editor feature org.eclipse.uml2.doc feature org.eclipse.uml2.examples feature org.eclipse.uml2.source For now, all of the version numbers are for a UML 4.2 release version as this structure entails no API-breaking changes. The UML run-time and SDK features that existed before still contain all of the same bundles as they did in the 4.1 release. Doc, examples, and source features in the SDK feature are unchanged. Looks great. The changes have been merged and a nightly build has been run (successfully) to verify the changes. An integration build containing the changes will be published soon. An integration build containing the changes is now available. |