Community
Participate
Working Groups
In order to integrate the modeling bridge with the existing build we need to determine the dependencies of the bridge.
Miles, can you list dependencies of the modeling bridge that are not already required by other components. I am looking for Orbit bundles, Eclipse packages etc. and their minimum versions that we would need to include in the build targets.
(In reply to comment #1) > Miles, can you list dependencies of the modeling bridge that are not already > required by other components. I am looking for Orbit bundles, Eclipse packages > etc. and their minimum versions that we would need to include in the build > targets. Will do. I'm going to go through the dependencies today and I'll package things into features so that we can minimize and understand these dependencies. My guess is that ecore tools and papyrus support will all have to be recent, but I think the really core stuff shouldn't need any thing greater than Eclipse 3.6 or EMF 2.5.0. Question, is there any procedure for actually testing backward compatibility, short of doing an install of all of the earlier components? :O
Thanks! Can you post the list of proposed features/components before creating them? How much work would it be to support Eclipse 3.5? Besides manual testing we run unit tests against supported targets: https://hudson.eclipse.org/hudson/user/spingel/my-views/view/Mylyn%20Integration/
(In reply to comment #3) > Thanks! Can you post the list of proposed features/components before creating > them? Yes, good idea! They'll need to be pretty fine grained, almost matching plugin structure. I'm thinking: o.e.m.modeling.emf contains: o.e.m.modeling.core o.e.m.modeling.ui At this point there really would be nothing of value without support for emf but at some point we might do support for just gef/draw2d. o.e.m.modeling.gmf (same plugin) o.e.m.modeling.ecoretools (same plugin) o.e.m.modeling.papyrus (same plugin) emf <- gmf <- (papyrus || ecoretools) > How much work would it be to support Eclipse 3.5? Wow, I always forget how many people are using legacy stuff. The thing is I really doubt that would be useful, simply because most if not all of the technologies that this will be used for weren't at all mature then. (As it is Papyrus is only a 0.8.1, but even the Ecore Diagram tools have changed quite a bit.) Also, I just realized that GMF itself will probably be the big issue for all but core. > Besides manual testing we run unit tests against supported targets: > https://hudson.eclipse.org/hudson/user/spingel/my-views/view/Mylyn%20Integration/ OK, that's impressive. :) I'm really afraid to even contemplate the build stuff right now.
One change. I'm going to add a separate emf project as well. It seems like this is all pretty much dependency management, because it will only have one class! But that will take out the emf requirement for the core plugin. Again, you can't do much with it, so this will all be in the same feature unless someone request differently. Jan, it is likely that you will only need o.e.m.modeling.emf for the tree work if that's what you decide to do. I'm almost sure that that can be 3.5 / EMF 2.3.
For Eclipse 3.5 what version of Mylyn does that imply? 3.4? Or I could leave the Mylyn version reqs. off entirely?
(In reply to comment #6) > For Eclipse 3.5 what version of Mylyn does that imply? 3.4? Or I could leave the > Mylyn version reqs. off entirely? Mylyn 3.6 (the current version) is compatible with Eclipse 3.5. You can leave out all version constraints on the bundle level. We'll manage that at the feature level. It's too much overhead to maintain it in both places. Thanks for the component listing. In terms of consumers, would o.e.m.modeling.emf be targeted at integrators building specific bridges for their tools or is the feature relevant to users as well? Are the other components usable as tools targeted at users providing focusing for GMF, Papyrus and Ecoretools editors when installed?
(In reply to comment #7) > (In reply to comment #6) > > For Eclipse 3.5 what version of Mylyn does that imply? 3.4? Or I could leave the > > Mylyn version reqs. off entirely? > > Mylyn 3.6 (the current version) is compatible with Eclipse 3.5. You can leave > out all version constraints on the bundle level. We'll manage that at the > feature level. It's too much overhead to maintain it in both places. Great. > > Thanks for the component listing. In terms of consumers, would > o.e.m.modeling.emf be targeted at integrators building specific bridges for > their tools or is the feature relevant to users as well? EMF would target integrators; I can't see any use for it standing alone now. That could change if we support EMF tree editors. Then we'd have an ..emf.edit and possible ..emf.editor as well. > Are the other components usable as tools targeted at users providing focusing > for GMF, Papyrus and Ecoretools editors when installed? Yes, exactly. And actually, GMF wouldn't be installed on it's own either, *unless as with EMF it was provided as part of another tool implementation. You need an actual (quite light-weight) domain implementation as well shick is what papyrus and ecoretools provide.
"shick" = "which" :)
(In reply to comment #7) > Mylyn 3.6 (the current version) is compatible with Eclipse 3.5. You can leave > out all version constraints on the bundle level. We'll manage that at the > feature level. It's too much overhead to maintain it in both places. I had noticed that this isn't the case for Mylyn project maintained plugins, i.e. most of the plugins define those as: ;bundle-version="[3.0.0,4.0.0)" And also assuming that we use version constraints for intra-mylyn.modeling depend.
(In reply to comment #10) > I had noticed that this isn't the case for Mylyn project maintained plugins, > i.e. most of the plugins define those as: > > ;bundle-version="[3.0.0,4.0.0)" Yes, that constraint is not particularly useful even though it's used everywhere in Mylyn. If you already have it in place it's fine to leave it.
(In reply to comment #11) > (In reply to comment #10) > > I had noticed that this isn't the case for Mylyn project maintained plugins, > > i.e. most of the plugins define those as: > > > > ;bundle-version="[3.0.0,4.0.0)" > > Yes, that constraint is not particularly useful even though it's used > everywhere in Mylyn. If you already have it in place it's fine to leave it. One packaging related question -- and thanks, btw -- it seems that we should *not* mark interface implementations with @Override, correct?
(In reply to comment #12) > One packaging related question -- and thanks, btw -- it seems that we should > *not* mark interface implementations with @Override, correct? The standard compiler and formatting settings should enforce the proper conventions. If in doubt, copy the .settings folder from an existing bundle and use Source > Format.
(In reply to comment #13) > (In reply to comment #12) > > One packaging related question -- and thanks, btw -- it seems that we should > > *not* mark interface implementations with @Override, correct? > > The standard compiler and formatting settings should enforce the proper > conventions. If in doubt, copy the .settings folder from an existing bundle and > use Source > Format. Yeah, that's just what I did, and just after that I got a bunch of failures for the overrides. But it looks to be something else causing the issue.
> Yeah, that's just what I did, and just after that I got a bunch of failures for > the overrides. But it looks to be something else causing the issue. The errors are correct. I believe you need to actually remove the overrides.
(In reply to comment #15) > > Yeah, that's just what I did, and just after that I got a bunch of failures for > > the overrides. But it looks to be something else causing the issue. > > The errors are correct. I believe you need to actually remove the overrides. Right, that's what I was thinking. Because of the issue with @Overides on interfaces breaking 1.5 complies and even runtime. Unfortunately, JDT is fighting with itself over this :) so I have to look at what settings are causing the conflict. Thanks.
Looking at the other features, it looks like you must add all of the IP stuff (about.html, ad. infinitum) in some kind of build step so I don't have to worry about that. If so, nice!
(In reply to comment #17) > Looking at the other features, it looks like you must add all of the IP stuff > (about.html, ad. infinitum) in some kind of build step so I don't have to worry > about that. If so, nice! We don't do anything special as part of our build. The about and license files etc. should be included in each feature. Please let me know if this is not the case.
(In reply to comment #18) > We don't do anything special as part of our build. The about and license files > etc. should be included in each feature. Please let me know if this is not the > case. Oh, gack! Forgot I had .html filtered from my view, but didn't realize that because when I had Mylyn focussed when my .html files were showing but not when I was looking at other projects.
OK, the changes are up. Jan, could you let me know if this addresses your issue with build dependencies?
Miles, can you please provide a list of build time dependencies (feature ids) for each of the modeling features?
emf: <import plugin="org.eclipse.core.runtime"/> <import plugin="org.eclipse.mylyn.context.core"/> <import plugin="org.eclipse.core.resources"/> <import plugin="org.eclipse.mylyn.modeling.core" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.emf.common"/> <import plugin="org.eclipse.emf.ecore"/> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.ui.workbench.texteditor"/> <import plugin="org.eclipse.ui.forms"/> <import plugin="org.eclipse.jface.text"/> <import plugin="org.eclipse.ui.ide"/> <import plugin="org.eclipse.ui.editors"/> <import plugin="org.eclipse.search"/> <import plugin="org.eclipse.mylyn.java.ui"/> <import plugin="org.eclipse.mylyn.context.ui"/> <import plugin="org.eclipse.mylyn.ide.ui"/> <import plugin="org.eclipse.mylyn.commons.core"/> <import plugin="org.eclipse.mylyn.monitor.ui"/> <import plugin="org.eclipse.mylyn.resources.ui"/> <import plugin="org.eclipse.mylyn.monitor.core"/> <import plugin="org.eclipse.emf.edit"/> <import plugin="org.eclipse.emf.edit.ui"/> <import plugin="org.eclipse.gef"/> <import plugin="org.eclipse.gmf.runtime.diagram.core"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui"/> <import plugin="org.eclipse.emf.ecoretools.diagram" version="0.9.0" match="greaterOrEqual"/> gmf: <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.core.runtime"/> <import plugin="org.eclipse.ui.ide"/> <import plugin="org.eclipse.mylyn.context.core"/> <import plugin="org.eclipse.mylyn.context.ui"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.providers"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.resources.editor"/> <import plugin="org.eclipse.mylyn.modeling.core" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.ui" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.emf" version="0.9.0" match="greaterOrEqual"/> ecoretools: <import plugin="org.eclipse.core.runtime"/> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.ui.editors"/> <import plugin="org.eclipse.ui.ide"/> <import plugin="org.eclipse.ui.forms"/> <import plugin="org.eclipse.ui.views"/> <import plugin="org.eclipse.ui.navigator"/> <import plugin="org.eclipse.ui.navigator.resources"/> <import plugin="org.eclipse.jface.text"/> <import plugin="org.eclipse.gmf.runtime.common.core"/> <import plugin="org.eclipse.gmf.runtime.diagram.core"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.resources.editor"/> <import plugin="org.eclipse.gmf.runtime.notation.edit"/> <import plugin="org.eclipse.emf.ecoretools.diagram" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.context.core"/> <import plugin="org.eclipse.mylyn.context.ui"/> <import plugin="org.eclipse.mylyn.commons.core"/> <import plugin="org.eclipse.mylyn.commons.ui"/> <import plugin="org.eclipse.mylyn.ide.ui"/> <import plugin="org.eclipse.mylyn.monitor.core"/> <import plugin="org.eclipse.mylyn.monitor.ui"/> <import plugin="org.eclipse.mylyn.modeling.core" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.emf" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.ui" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.gmf" version="0.9.0" match="greaterOrEqual"/> papyrus: <import plugin="org.eclipse.core.runtime"/> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.ui.editors"/> <import plugin="org.eclipse.ui.ide"/> <import plugin="org.eclipse.ui.forms"/> <import plugin="org.eclipse.ui.views"/> <import plugin="org.eclipse.ui.navigator"/> <import plugin="org.eclipse.ui.navigator.resources"/> <import plugin="org.eclipse.jface.text"/> <import plugin="org.eclipse.gmf.runtime.common.core"/> <import plugin="org.eclipse.gmf.runtime.diagram.core"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui"/> <import plugin="org.eclipse.gmf.runtime.diagram.ui.resources.editor"/> <import plugin="org.eclipse.gmf.runtime.notation.edit"/> <import plugin="org.eclipse.mylyn.context.core"/> <import plugin="org.eclipse.mylyn.context.ui"/> <import plugin="org.eclipse.mylyn.commons.core"/> <import plugin="org.eclipse.mylyn.commons.ui"/> <import plugin="org.eclipse.mylyn.monitor.core"/> <import plugin="org.eclipse.mylyn.monitor.ui"/> <import plugin="org.eclipse.mylyn.ide.ui"/> <import plugin="org.eclipse.uml2"/> <import plugin="org.eclipse.papyrus.diagram.clazz"/> <import plugin="org.eclipse.papyrus.editor"/> <import plugin="org.eclipse.papyrus.diagram.common"/> <import plugin="org.eclipse.mylyn.modeling.core" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.ui" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.emf" version="0.9.0" match="greaterOrEqual"/> <import plugin="org.eclipse.mylyn.modeling.gmf" version="0.9.0" match="greaterOrEqual"/>
I am looking for feature dependencies, not plug-in dependencies.
OK, fundamentally it's: mylyn common and context, eclipse.ui, emf, emf.ecore, gef and then, depending on feature: org.eclipse.gmf.runtime (that's important as we don't want any of the tooling), ecoretools, uml2.core & papyrus.uml.
Do you want an rmap or something? I could whip that up, but it would be a lot easier once it is in the actual build since in my experience there is always something that you'vre left out anyway, and I'd hate to have to walk the feature dependency chain by hand.
Thanks for the listing. We'll eventually need to add these to the target files for the build. For now it's sufficient if we add the required features to the feature.xml files, e.g.: <requires> <import feature="org.eclipse.mylyn.context_feature" version="3.7.0" match="equivalent"/> <import feature="org.eclipse.jdt" version="3.4.0" match="compatible"/> </requires>
OK, my next question is whether you wanted to hae me calculate and include the requirements in the features themselves and I gather the answer to that is "yes". And so I'll just take my best guess at lowest supportable version. One additional note. I think that Mylyn is +3 on release train? GMF -- presuming they make it back on-board which seems likely for SR1 -- is at +2, but Papyrus and EcoreTools are both also at +3. I just bring this up now because it all adds a bunch of build dependencies -- many of them not super stable -- (papyrus is only at 0.8.1 and GMF wasn't able to get a build into Indigo at all) and that might color decision about whether to have this as part of the main context build or not.
(In reply to comment #27) > OK, my next question is whether you wanted to hae me calculate and include the > requirements in the features themselves and I gather the answer to that is > "yes". And so I'll just take my best guess at lowest supportable version. Yes, I just want hand-crafted feature dependencies (not the plug-in dependencies that are calculated by PDE). The reason is to ensure that if I install one of the modeling bridge features that I end with a set of tools or frameworks that make sense. > One additional note. I think that Mylyn is +3 on release train? GMF -- presuming > they make it back on-board which seems likely for SR1 -- is at +2, but Papyrus > and EcoreTools are both also at +3. I just bring this up now because it all adds > a bunch of build dependencies -- many of them not super stable -- (papyrus is > only at 0.8.1 and GMF wasn't able to get a build into Indigo at all) and that > might color decision about whether to have this as part of the main context > build or not. Yes, I had the same thought. We'll have to discuss that before making that call.
Well, you started a hell of a discussion pace... sorry for joining late. (In reply to comment #5) > Jan, it is likely that you will only need o.e.m.modeling.emf for the tree work > if that's what you decide to do. I'm almost sure that that can be 3.5 / EMF > 2.3. Yes, I doubt that there is any need beyond that. (In reply to comment #21) > OK, the changes are up. Jan, could you let me know if this addresses your issue with build dependencies? The selfish answer is: yes, as long as it's compatible with e3.6 and EMF 2.6 I'm fine :-) Are the changes available in GIT already?
(In reply to comment #29) > [...] > Are the changes available in GIT already? Forget that one, I pulled the changes, everything seems to be fine on first sight. Other questions I do have or will have are not related to this ticket.
I had to add the following features to the target to resolve all dependencies: <unit id="org.eclipse.emf.ecoretools.sdk.feature.group" version="0.0.0"/> <unit id="org.eclipse.emf.transaction.feature.group" version="0.0.0"/> <unit id="org.eclipse.gef.sdk.feature.group" version="0.0.0"/> <unit id="org.eclipse.gmf.runtime.sdk.feature.group" version="0.0.0"/> <unit id="org.eclipse.papyrus.sdk.feature.group" version="0.0.0"/> <unit id="org.eclipse.uml2.sdk.feature.group" version="0.0"/> Miles, does that list look reasonable?
Hmmm... It really doesn't seem like you should need all of those sdks. Ideally, dependencies should be runtime only. Of course people have different ideas about what "SDK" means. I do like that GMF has a "runtime.sdk". :) (They have separate "tooling" and "runtime" sub-projects but really should have a different name for "runtime".) I'll take a look.
OK, the following should do it, or at least be enough for build-time dependencies. Using these dependencies along with the eclipse.sdk for a feature based build I can get my complete testing workspace to function as expected. I'm not so sure about Papyrus dependencies -- it seems to want to pull in all kinds of stuff that we really want to avoid having build time dependencies on like Xtext. Hopefully those won't be needed for build based on below. <import feature="org.eclipse.mylyn.commons" version="3.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.mylyn.context_feature" version="3.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.common" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.common.ui" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.edit" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.edit.ui" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.ecore" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.ecore.edit" version="2.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.gmf" version="1.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.gmf.runtime.notation" version="1.5.0" match="greaterOrEqual"/> <import feature="org.eclipse.emf.ecoretools" version="1.0.0" match="greaterOrEqual"/> <import feature="org.eclipse.papyrus" version="0.8.1" match="greaterOrEqual"/> <import feature="org.eclipse.papyrus.diagram.clazz" version="0.8.1" match="greaterOrEqual"/> <import feature="org.eclipse.papyrus.uml" version="0.8.1" match="greaterOrEqual"/> <import feature="org.eclipse.uml2" version="3.2.0" match="greaterOrEqual"/>
Moving discussion from bug 355793, comment 7. (In reply to comment #7) > (In reply to comment #6) > > Those don't really fit well here. emf includes non ui components and > ecoretools > > gmf and papyrus aren't ui plugins per se except in the sense that all modeling > > tools are ui. They all include nominally core stuff, but it would be silly to > > pull that out as the projects are already really granular as it is. > > Don't all of these have ui dependencies (concerning emf see below)? If so, the > standard convention is to call them .ui. > > We generally use a separate namespace per component and plug-ins always have one > qualifying segment (org.eclipse.mylyn being the only exception). That way we can > consistently split out core or doc bundles later if we decide to modularize > further. That makes perfect sense, but in this case just feels somehow unnatural to me. Yes, by definition all of the diagram stuff implicates ui, but that actually implies that most of the modeling diagram stuff doesn't explicitly include "ui". Diagram and visualization typically aren't in a "ui" namespace, and instead the actual tools that are used for working with those diagrams are. So for example, in emf, we have emf.edit and emf.editor that support the ui for created models. It all gets so overloaded and it is a subtle and perhaps irrelevant distinction here. > > > > I'm unsure about org.eclipse.mylyn.modeling.core/ui. Where do these fit in > > > component wise? If they are logically part of the EMF component they should > be > > > in that namespace: > > > > > > org.eclipse.mylyn.modeling.emf.core/bridge/ui > > > > I'm not sure I understand the question..but the idea of core is that it really > > is exclusive of any ui dependencies. It basically supports semantics for > mapping > > from domain models to the (implicit) mylyn model. > > Okay, can we then rename org.eclipse.mylyn.modeling.core to > org.eclipse.mylyn.modeling.emf.core and merge it with > org.eclipse.mylyn.modeling.emf? Even though core does not have an EMF dependency > all components depend on the EMF component so this dependency exists anyways. I > don't see any need to provide bundles for non-EMF modeling bundles or did that > come up already? Maybe buried somewhere, but it's a question worth exploring further. Ideally, we'd like to support generic graphical tools that are based on GEF and Graphiti, but not necessarily GMF or even EMF. There has been interest expressed in that and it could be cool. Just as an off the cuff example, imagine a Java hierarchy diagram built on top of Zest, or turing the existing PDE zest tool into a Mylyn savvy one. So what I've been working on -- taking the dependency on emf (and the bogus ecoretools one) out of ui, and am changing that to o.e..mylyn.modeling.gef. (or gef.ui :)) This would still be part of core feature. And *that* has caused me to revisit the rest of the UI and Structure bridge dependencies to see if I can tease things out more. But that has as I feared created issues with extension loading -- avoiding these kinds of issues was part of the reason for the initial design with the delegated structure and ui bits. So I'm probably going to be beating my head against that wall for a while. > Likewise, org.eclipse.mylyn.modeling.ui would become > org.eclipse.mylyn.modeling.emf.ui since it's part of the EMF component. There is > one dependency requirement on org.eclipse.emf.ecoretools.diagram in > org.eclipse.mylyn.modeling.emf.ui though that does not look quite in the right > place? See above.
(In reply to comment #34) > That makes perfect sense, but in this case just feels somehow unnatural to me. > Yes, by definition all of the diagram stuff implicates ui, but that actually > implies that most of the modeling diagram stuff doesn't explicitly include "ui". Yes, I agree. It's equally weird for the Java and Resource bridges which are called o.e.mylyn.java.ui and o.e.mylyn.resources.ui. I'm not saying there aren't more intuitive (e.g. .bridge) but it's the convention that we have been using for all context bridges in the project. Arguably, the existing structure bridges are missing the core/ui split. We can change that for modeling if it makes sense, e.g. for the EMF bridge but to keep things simple I am also okay with putting all bridge stuff in .ui bundles. > Diagram and visualization typically aren't in a "ui" namespace, and instead the > actual tools that are used for working with those diagrams are. So for example, > in emf, we have emf.edit and emf.editor that support the ui for created models. > It all gets so overloaded and it is a subtle and perhaps irrelevant distinction > here. We could end up with .edit or other bundles for specific parts of EMF but at the current stage I think one .ui plug-in per bridge should suffice. > I > > don't see any need to provide bundles for non-EMF modeling bundles or did that > > come up already? > > Maybe buried somewhere, but it's a question worth exploring further. Ideally, > we'd like to support generic graphical tools that are based on GEF and Graphiti, > but not necessarily GMF or even EMF. There has been interest expressed in that > and it could be cool. Just as an off the cuff example, imagine a Java hierarchy > diagram built on top of Zest, or turing the existing PDE zest tool into a Mylyn > savvy one. Fair enough. Looking closer at DomainDelegatedStructureBridge it looks a good place to put it would be org.eclipse.mylyn.context.core? For now I suggest that we keep it in the EMF plug-in and if the need arises move it further up the chain. > So what I've been working on -- taking the dependency on emf (and the bogus > ecoretools one) out of ui, and am changing that to o.e..mylyn.modeling.gef. (or > gef.ui :)) This would still be part of core feature. Okay, that split makes sense. Will the o.e.m.modeling.gef.ui bundle have a dependency on EMF? I am wondering if it makes sense to introduce another component here to avoid forcing a GEF depenency on consumers only interested in the EMF bridge. > And *that* has caused me to revisit the rest of the UI and Structure bridge > dependencies to see if I can tease things out more. But that has as I feared > created issues with extension loading -- avoiding these kinds of issues was part > of the reason for the initial design with the delegated structure and ui bits. > So I'm probably going to be beating my head against that wall for a while. What kind of issues? Can you point me at a corresponding bug?
(In reply to comment #35) > Arguably, the existing structure bridges are missing the core/ui split. We can > change that for modeling if it makes sense, e.g. for the EMF bridge but to keep > things simple I am also okay with putting all bridge stuff in .ui bundles. Yeah, I'm always looking for ways to separate model from view, but let's see how it plays. > We could end up with .edit or other bundles for specific parts of EMF but at the > current stage I think one .ui plug-in per bridge should suffice. Totally. > Fair enough. Looking closer at DomainDelegatedStructureBridge it looks a good > place to put it would be org.eclipse.mylyn.context.core? For now I suggest that > we keep it in the EMF plug-in and if the need arises move it further up the > chain. Exactly. It's the only thing *in* core now. :) > > So what I've been working on -- taking the dependency on emf (and the bogus > > ecoretools one) out of ui, and am changing that to o.e..mylyn.modeling.gef. > (or > > gef.ui :)) This would still be part of core feature. > > Okay, that split makes sense. Will the o.e.m.modeling.gef.ui bundle have a > dependency on EMF? I am wondering if it makes sense to introduce another > component here to avoid forcing a GEF depenency on consumers only interested in > the EMF bridge. Exactly. GEF then has no EMF dependencies -> reseparating the merged ui and structure bits (there were good reasons to do that at some point..) > > of the reason for the initial design with the delegated structure and ui bits. > > So I'm probably going to be beating my head against that wall for a while. > > What kind of issues? Can you point me at a corresponding bug? I'm not sure yet, but right now my working guess is that it is back to the same common issue of getting different extensions to play nicely with each other when you don't have control over either's life-cycle. I guess this task covers the bug, since it is a re-factoring to support splitting up the dependencies in different ways -- but it impacts everything that has come up from internal/spi to interfaces vs. abstract classes, context activation, etc.. :)
(In reply to comment #36) > > Fair enough. Looking closer at DomainDelegatedStructureBridge it looks a good > > place to put it would be org.eclipse.mylyn.context.core? For now I suggest > that > > we keep it in the EMF plug-in and if the need arises move it further up the > > chain. > > Exactly. It's the only thing *in* core now. :) To clarify...this is the only thing that has potential use by both emf only and gef only right now, but it isn't actually being used by any gef-only implementation. Still, I'd like to keep it seperated out in case people want to play with that usage.
OK, see: https://github.com/MilesParker/mylyn.incubator/commit/400d8524612dd73f53955620a6a8f81a3dac0475 It isn't perfect :) but I wanted to get it up here as Jan may be relying on package structure. I'm not sure what to do about the modeling.ui now. It has a gef dependency and I can't think of any reason for any modeling tool not to want that, and it has a class with no such dependencies but it would be totally silly to break out a gef *and* ui. That leaves poor little .modeling.core.
(In reply to comment #38) > I'm not sure what to do about the modeling.ui now. It has a gef dependency and I > can't think of any reason for any modeling tool not to want that, and it has a Correction "any diagram modeling tool". The EMF tree editor wouldn't want that, but it would want the ecore domain stuff which I'll move *back* to emf now. https://github.com/MilesParker/mylyn.incubator/commit/bcd734e3d4c15648fa8aa7e8a3e08b5a0ba32818 bug 353242 is looking like it would be a nice thing to have.
(In reply to comment #38) > [...] > > It isn't perfect :) but I wanted to get it up here as Jan may be relying on > package structure. I'm fine with the current dependencies, thanks a lot. Perfection comes over time... > I'm not sure what to do about the modeling.ui now. It has a gef dependency and > I can't think of any reason for any modeling tool not to want that, and it has > a class with no such dependencies but it would be totally silly to break out a > gef *and* ui. That leaves poor little .modeling.core. Hmm, I'm not sure about that one either. A modeling UI bridge might be also required by products having no GEF; AFAIK it is also used for example to open elements when double clicking in the context of a task and other things. So what to do in case there isn't any GEF based editor but just some tree based editor shall be opened or the element shall selected in a view. That's UI stuff but no GEF. However, it's just theoretical.
(In reply to comment #40) > Hmm, I'm not sure about that one either. A modeling UI bridge might be also > required by products having no GEF; AFAIK it is also used for example to open > elements when double clicking in the context of a task and other things. So what > to do in case there isn't any GEF based editor but just some tree based editor > shall be opened or the element shall selected in a view. That's UI stuff but no > GEF. However, it's just theoretical. Right. See comment 39. For stuff like bug 352173 and bug 343200 you'll only want o.e.mylyn.modeling.emf and ..core. btw, any thoughts about what -- if anything -- you might want to work on? I think you mentioned tree editor which would be a super cool feaature to have.
I'd like to close this one down but of course please reopen if you think I've missed something.
I've made the one gef dependendency in modeling.ui generic, so now emf-feature should have no gef dependencies either.
