Community
Participate
Working Groups
As part of modularizing the build (bug 330155) I added the o.e.m.htmltext bundle to the WikiText SDK feature. This will make the bundle available on the main Mylyn update site and also the Indigo release site. Let me know if you would like a separate feature for the bundle or any changes.
I plan on doing a weekly build on Wednesday which will include the changes.
Why did you choose the WikiText SDK feature? Does it make sense for htmltext to get its own feature? On a side note, just looking at htmtext it looks like everything's API. Does this make sense for htmltext or should it be refactored so that there are some internal packages.
All plug-ins are part of the SDK so I assumed the same would apply to HtmlText. Please feel free to remove it if you disagree. As I have said in the description this bug is intended for discussing the best mode of distribution for HtmlText. Right now we have no consumers in Mylyn so either including it in the SDK or its own feature works for me. It just needs to be part of some feature to make it available on the update site. What are your thoughts on it? We should also consider the 0.0.1 version of the plug-in. I would at at least bump it to 0.7.0 or 1.0.0 if the plug-in is considered stable and suitable for consumption by other projects.
(In reply to comment #3) > All plug-ins are part of the SDK so I assumed the same would apply to HtmlText. > Please feel free to remove it if you disagree. As I have said in the > description this bug is intended for discussing the best mode of distribution > for HtmlText. Ok, I'm fine with that. > We should also consider the 0.0.1 version of the plug-in. I would at at least > bump it to 0.7.0 or 1.0.0 if the plug-in is considered stable and suitable for > consumption by other projects. Ok, feel free to change the version to 0.7.0. It is suitable for consumptation but doesn't support all html features yet.
> On a side note, just looking at htmtext it looks like everything's API. Does > this make sense for htmltext or should it be refactored so that there are some > internal packages. The API makes sense. The internal stuff is not Java but JavaScript.
(In reply to comment #3) From what I can see HtmlText doesn't have any commonality with WikiText, so my initial feeling is to put it in its own feature. If there are plans for HtmlText to implement some of the WikiText APIs or have significant feature overlap then it would make sense to have it part of the same feature. (In reply to comment #5) It's always easier to make things API later, rather than straight away. Do clients normally have to reference the command classes directly, for example? If not, I recommend that the commands be made internal.
(In reply to comment #6) > (In reply to comment #3) > > From what I can see HtmlText doesn't have any commonality with WikiText, so my > initial feeling is to put it in its own feature. If there are plans for > HtmlText to implement some of the WikiText APIs or have significant feature > overlap then it would make sense to have it part of the same feature. Good point. I was thinking of the WikiText SDK feature as the Mylyn Docs SDK but as you point out if there is little overlap this may not make sense. Should we create a org.eclipse.mylyn.htmltext feature then? To provide integration with the Task Editor would we end up creating a "Rich Text Support for Mylyn" integration feature that would consume the tasks dependencies both for WikiText and HtmlText?
(In reply to comment #7) > Good point. I was thinking of the WikiText SDK feature as the Mylyn Docs SDK but > as you point out if there is little overlap this may not make sense. Should we > create a org.eclipse.mylyn.htmltext feature then? Yes, that sounds like the right thing to do. > To provide integration with the Task Editor would we end up creating a "Rich > Text Support for Mylyn" integration feature that would consume the tasks > dependencies both for WikiText and HtmlText? That sounds like a good idea. It should contain separate plug-in bundles (one for wikitext and one for htmltext) to keep the dependencies sane. Note that the existing @AbstractTaskEditorExtension@ won't work in its current form for task editor contributions that don't use a @SourceViewer@. We may want to come up with a new abstraction, and have a default implementation that supports implementations of @AbstractTaskEditorExtension@.
Created attachment 187769 [details] mylyn/context/zip
Tom, are you okay with creating a org.eclipse.mylyn.htmltext feature? > Note that the existing @AbstractTaskEditorExtension@ won't work in its current > form for task editor contributions that don't use a @SourceViewer@. We may want > to come up with a new abstraction, and have a default implementation that > supports implementations of @AbstractTaskEditorExtension@. I see. I don't think we'll be able to make that happen for 3.5 since there is a lot on the plate already but I'll create a bug for 3.6.
(In reply to comment #10) > Tom, are you okay with creating a org.eclipse.mylyn.htmltext feature? Yes.
Thanks. I'll go ahead and do that then.
Added org.eclipse.mylyn.htmltext feature and removed plug-in from WikiText SDK feature. The feature will be available on the weekly site after the next weekly build (hopefully today). You can also check the update site generated by the next mylyn-release build at https://hudson.eclipse.org/hudson/job/mylyn-release/lastSuccessfulBuild/artifact/org.eclipse.mylyn/org.eclipse.mylyn.releng/main-site/target/site/ .
Nice work Steffen, that's great.
