Community
Participate
Working Groups
Default setting for "xplanner" as a repository association is missing in wikitext.twiki.ui plugin
Created attachment 118852 [details] patch for including xplanner as default repository association for twki language definition
Helen, is there a reason why XPlanner cannot do this?
(In reply to comment #2) > Helen, is there a reason why XPlanner cannot do this? What I'm getting at is that WikiText can't possibly know about all of the available connectors. It makes sense to me that connectors should declare their own markup defaults. That way control is in the hands of the connector. What are your thoughts on this?
I was under the false impression that the extension would require a dependency on wikitext but since it only couples to tasks.ui it seems fine to move keep the extensions in the connectors. Should we move that for Trac, JIRA and Bugzilla as well?
(In reply to comment #4) >...since it only couples to tasks.ui it seems fine to move keep the extensions in the connectors. > Should we move that for Trac, JIRA and Bugzilla as well? You're right in that the extension point usage looks something like this: bc. <extension point="org.eclipse.mylyn.tasks.ui.taskEditorExtensions"> <repositoryAssociation connectorKind="jira" taskEditorExtension="org.eclipse.mylyn.wikitext.confluence.ui.taskEditorExtension"> </repositoryAssociation> </extension> The usage referneces a task editor extension id that is declared by WikiText but does not create a WikiText dependency in the plug-in manifest. It's kind of a chicken-and-egg dependency problem. I was thinking originally that obvious dependencies such as Confluence and JIRA, TracWiki and Trac should be declared by the WikiText plug-ins, whereas others that are non-obvious would be declared by the connector UI plug-in. Bugzilla is an obvious exception to this rule since the WikiText Textile plug-in has a Bugzilla-specific markup dialect. However we end up is fine with me, though I am partial to leaving it as-is. The main thing is that we don't end up with constant requests to include repositoryAssociations in the WikiText plug-ins.
I don't know if there is a good answer to this problem but I can see these solutions: Create an additional plug-in for each markup dialog that depends on Mylyn as well as on Wikitext and declares the extension. This would decouple both frameworks but add unnecessary overhead in maintenance. Currently repositoryAssociations are coupled to a specific taskEditorExtension extension. Alternatively this could be generalized and based on the content type of the rendered text. The JIRA connector would declare that uses "markup/confluence" by default as an additional property specified in the taskEditorExtension for instance. That would avoid logical coupling to wikitext while it would still be "clean" to specify the extension in the (JIRA) connector. As a middle ground it could also work to have a single o.e.m.wikitext.tasks plug-in with all tasks specific extensions and implementations. This plug-in would depend on all wikitext markup languages. This would be similar to o.e.m.java.tasks plug-in.
(In reply to comment #6) > Create an additional plug-in for each markup dialog that depends on Mylyn as > well as on Wikitext and declares the extension. This would decouple both > frameworks but add unnecessary overhead in maintenance. Agreed, this sounds too heavy. > Currently repositoryAssociations are coupled to a specific taskEditorExtension > extension. Alternatively this could be generalized and based on the content type > of the rendered text. The JIRA connector would declare that uses > "markup/confluence" by default as an additional property specified in the > taskEditorExtension for instance. That would avoid logical coupling to wikitext > while it would still be "clean" to specify the extension in the (JIRA) > connector. To me this sounds way too complicated. There's already one level of indirection. > As a middle ground it could also work to have a single o.e.m.wikitext.tasks > plug-in with all tasks specific extensions and implementations. This plug-in > would depend on all wikitext markup languages. This would be similar to > o.e.m.java.tasks plug-in. I don't like this one either, since you'll end up with one plug-in that has to know about all of the connectors and all of the markup languages.
> > As a middle ground it could also work to have a single o.e.m.wikitext.tasks > > plug-in with all tasks specific extensions and implementations. This plug-in > > would depend on all wikitext markup languages. This would be similar to > > o.e.m.java.tasks plug-in. > > I don't like this one either, since you'll end up with one plug-in that has to > know about all of the connectors and all of the markup languages. From my understanding that makes sense considering the purpose: provide integration between WikiText and Mylyn connectors, hence the plug-in needs to have that knowledge. Since the plug-in only provides integration glue it would most likely not be reusable in other contexts. The dependencies would not affect integrators and since connector dependencies would be optional (or not specified at all) and the wikitext feature distributes all markup languages users would not be affected either. Can you elaborate why dependencies on connectors and markup languages would be harmful in this case?
(In reply to comment #8) > > > As a middle ground it could also work to have a single o.e.m.wikitext.tasks > > > plug-in with all tasks specific extensions and implementations. > Can you elaborate why dependencies on connectors and markup languages would be > harmful in this case? Having one plug-in know about all others is a weak design. It creates fragility and a single point that must know about everything. If this knowledge is to exist in WikiText, it's much stronger to have it distributed amongst the plug-ins that should be in-the-know, as it is now. If need be, we can put the XPlanner connector repositoryAssociation in the TWiki UI plug-in, however I still believe that it's better for XPlanner if the declaration lies within the XPlanner UI plug-in.
David, Steffen, I actually don't have a problem creating the extension in XPlanner -- it did seem a little strange to me that I would have to go into the wikitext plugin to add that dependency, but I just followed the precedent set by the other connectors -- not to mention it was hard to find -- I had to ask Steffen where I would add that dependency. I think it makes more sense for the connectors to be responsible for defining the extension, although it should probably be a little more obvious how to do that -- maybe more comments in the code -- since that's where I would go to look for it, immediately after actual code examples.
(In reply to comment #10) Helen, so do you think that this is more of a documentation problem or a design problem?
To me, the current state is more of a documentation issue -- the less plugin dependencies, the better. Although I can appreciate both sides of the problem -- if an intermediate plugin was a plugin dependency for supporting the functionality, then it would be more obvious how the two sides connect.
(In reply to comment #12) > To me, the current state is more of a documentation issue I've moved the documentation problem to bug 257126 Please reopen this bug if any other issues remain.
(In reply to comment #8) > > > As a middle ground it could also work to have a single o.e.m.wikitext.tasks > > > plug-in with all tasks specific extensions and implementations. This plug-in > > > would depend on all wikitext markup languages. This would be similar to > > > o.e.m.java.tasks plug-in. > > > > I don't like this one either, since you'll end up with one plug-in that has to > > know about all of the connectors and all of the markup languages. > > From my understanding that makes sense considering the purpose: provide > integration between WikiText and Mylyn connectors, hence the plug-in needs to > have that knowledge. Steffen, I was wrong on this point. I've looked it over in more detail and you have a good argument. I was reluctant to have one plug-in know about all of the Mylyn connector kinds. Though my concerns about that are still valid, there are more issues to consider here. Looking over what's needed to make WikiText more consumable by contributors without an explosion in the number of WikiText plug-ins (bug 256510) has given me a new perspective. Having a plug-in that integrates WikiText with the Mylyn tasks UI is akin to the Mediator design pattern, and in this case is a good compromise between opposing design concerns. Watch me eat humble pie.... ;) So, in light of my enlightenment, how about we go ahead with moving all Mylyn Tasks UI dependencies into the new plug-in as per bug 257009 and add the XPlanner association to it as well.
Great that we have converged. I believe there are multiple valid solutions to this problem and you made good points why maintaining extensions in the connectors is favorable. I was thinking of WikiText more as an extension to Mylyn than as a framework that is used by connectors but I can also see how connectors are extensions of the Mylyn and the WikiText frameworks. The mediator pattern is a great analogy! I agree that decoupling the WikiText framework from Mylyn will potentially help it's adoption and reuse which is good. Let's move forward with creating the new plug-in on tomorrow's call and moving the extensions.
fixed in org.eclipse.mylyn.wikitext.tasks.ui/plugin.xml
