Community
Participate
Working Groups
from the newsgroup: bq. I've been using Textile-J for a while (and loving it) and am getting to the point where I want to start playing with implementing some extensions for the editor (with an eye towards pushing them back to the community). In an effort to keep up with the Joneses, I started to pull things out of CVS on eclipse.org only to find that I need to pull in loads of Mylyn bits too. I'm curious why there is this coupling? Shouldn't I be able to use (and contribute to) the WikiText editor without the Mylyn tasks UI?
Chiming in (I was the original poster), I would say that having the deps be optional is definitely a start but really not the cleanest. In my experience understanding and managing optional dependencies is a bit of a headache (especially over the long haul). Would it be too painful to get this right now? On the surface, it doesn't look too hard to separate out the task contributions into separate bundles but I admit I haven't dug too deep. In the end, making it easier for folks to consume WikiText will only help its adoption (outside of Mylyn). Moreover, making it easier to develop WikiText will make it more likely that you'll get source contributions... (Just my 2 cents!)
In principle I like the idea of splitting the Mylyn bundle dependencies out. Splitting it out at the code level is straight forward and feasible. Before going full steam ahead with the idea, consider the following: # each @org.eclipse.mylyn.wikitext.*.ui@ plug-in would have to be split in two, thus resulting in 6 additional WikiText plug-ins ## WikiText would go from having 13 plug-ins to 19 # the various wikitext ui plug-ins would be quite small -- contributors would end up navigating many small bundles before finding what they need
Having lots of little bundles does have a downside but I still think it's worth it considering how it enables WikiText to be consumed (understood and developed) w/o Mylyn. Moreover, these bundles are small today but will they always be? If they're likely to grow much, this splitting out might have more obvious payback over time. On a meta-note, does it make sense to consider a different namespace for the (Mylyn-free) WikiText bundles? In other words, something like @org.eclipse.wikitext.*.*? (Just a thought.)
After talking about the pros/cons, here's my proposed solution: * create a new plug-in called org.eclipse.mylyn.wikitext.ui.tasks ** move all Mylyn dependencies to this plug-in the solution is a compromise: it provides a nice separation of concerns, breaks out the Mylyn bundle dependencies, and eliminates the need for optional dependencies. Contributors to WikiText will either have Mylyn installed, or the Mylyn source in their workspace, or they can close the 5 or 6 WikiText plug-ins that will have Mylyn dependencies. In this case contributors will still be able to use/contribute to all of the WikiText core plug-ins and the WikiText UI plug-in. Phil, would this solution meet your needs?
+1 for moving dependencies on the tasks framework into a separate plug-in.
+1. This would definitely address my issues and feels like the clean (and pragmatic) way to go. Thanks for the follow-up!
great, +1 from me too I've created bug 257009 for creation of this new project.
fixed with creation of new project org.eclipse.mylyn.wikitext.tasks.ui
