Community
Participate
Working Groups
Please initiate a release review for WikiText, to move it out of incubation.
I noticed that all o.e.m.wikitext.*.core plug-ins re-export org.eclipse.mylyn.wikitext.core. My understanding is that re-exporting is generally problematic and should be limited to the rare case where a plug-in is split up into multiple bundles but needs to maintain backwards compatibility. Re-exporting makes the same package available from multiple bundles which I believe complicates the resolution process when import package is used. Also it couples the API of the re-exporting bundle to the one that is re-exported. Any API change in o.e.m.wikitext.core would propagate to all other core plug-ins and would require a version update although the API or implementation of those plug-ins may not have changed. The only minor convenience that I can see is that clients only need to depend on a single bundle instead of requiring o.e.m.wikitext.mediawiki.core and o.e.m.wikitext.core. Are there other advantages or technical reasons for re-exporting?
(In reply to comment #1) > I noticed that all o.e.m.wikitext.*.core plug-ins re-export > org.eclipse.mylyn.wikitext.core. My understanding is that re-exporting is Thanks for looking into this > The only minor convenience that I can see is that clients only need to depend on > a single bundle instead of requiring o.e.m.wikitext.mediawiki.core and > o.e.m.wikitext.core. Are there other advantages or technical reasons for > re-exporting? This is the only reason that the packages reexport o.e.m.wikitext.core. If that's not a good reason and it creates problems then I'll fix it. Let me know what is best practice here.
I'm +1 for removing the re-exports. The only related thread I could find is this: http://dev.eclipse.org/newslists/news.eclipse.platform/msg53459.html , but there is not much discussion. Mik, do you have any thoughts?
(In reply to comment #3) > I'm +1 for removing the re-exports Works for me! I'll get on it.
David, can you confirm that WikiText meets the applicable Must Do / Should Do criteria for Galileo? If not, could you briefly summarize the (technical) reasons. http://wiki.eclipse.org/Galileo_Simultaneous_Release#Requirements_For_Participation APIs: Projects should leverage only published APIs of dependencies. As a Release Review requirement, deviations should be listed as part of a migration plan, with bugs listed where APIs need to be provided by dependent projects. Message Bundles: Projects must use Eclipse message bundles unless there are technical reasons not to. Localization: Must use ICU4J. Version Numbering: Projects must use 4-part version numbers. Leverage OSGi: All plug-ins (bundles) must use the true bundle form. That is, provide a manifest.mf file, and not rely on the plugin.xml file being 'translated' into a manifest.mf file at initial startup. Execution Environment: All plug-ins must correctly list their required JVM versions in the manifest.mf. Use Jars: Projects must use jar'ed plug-ins (with unpack=false) unless authorized by the planning council for technical reasons.Nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-ins. Builds: Projects must have build process maturity: scripted, repeatable, and executable by others. Orbit: Any new third-party plug-ins that are common between projects must be consumed via Orbit. Capabilities: Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden. These must be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development. Usability: Should follow the User Interface Guidelines. Accessibility: Should design and test for accessibility.
note that a release review has been scheduled for January 8th: http://wiki.eclipse.org/index.php/Mylyn/Meetings
The release review was completed successfully. I have asked the webmaster to move the wikitext plug-ins to Mylyn proper.
(In reply to comment #7) > The release review was completed successfully. I have asked the webmaster to > move the wikitext plug-ins to Mylyn proper. Great, thanks!
A release review was performed in the last conference call. Mik, I'll leave this one for you to close.
Done. Next step is including this in the Mylyn 3.1 release review.
