Community
Participate
Working Groups
I have created a new project called org.eclipse.mylar.trac.core, so you can now extract your core API and we can make it accessible via the headless tasks.core API.
Great. Since I still have pending changes for the rich editor implementation in my workspace I'd rather make the split when these have been resolved.
No problem. Don't forget to make sure that all of the packages of trac.core get exported (via the Runtime tab of the MANIFEST.MF editor).
Note: add core to Team Project Set
Created attachment 48518 [details] updated Team Project Set
Patch applied.
Steffen: I'm raising the priority of this since it will enable use of Trac via the headless frameworks, and should be a straightforward move.
I have moved the core and the model package to the Trac core plug-in (not committed, yet). I am not sure which classes in org.eclipse.mylar.trac should be moved to the core plug-in such as TracTask, TracRepositoryConnector, Trac*Handler, TracAttributeFactory, Trac*Query? Looking at the Bugzilla plug-in I noticed that BugzillaTask and BugzillaRepositoryConnector are (still) located in the UI plug-in. I am also thinking about renaming the following packages: org.eclipse.mylar.internal.trac -> org.eclipse.mylar.internal.trac.ui org.eclipse.mylar.internal.trac.core -> org.eclipse.mylar.internal.trac.core.server Mik, could you please advise?
You should move as much as you can without coupling to the UI. You can consider the use case to be a server side application that wants to query Trac but does not use any of the Eclipse UI facilities. Yes, the mylar.internal.trac package in the trac.ui package should be renamed to mylar.internal.trac.ui. I wouldn't bother renaming to trac.core.server, because trac.core will be largely about connecting to the server, so that naming should probably come from class naming conventions. We still need to resolve bug 149940, so just use what you think is right and that will provide good input to the Connector naming conventions.
I have moved the packages mentioned in comment #7. I was not able to move TracRepositoryConnector and dependent classes since it needs the RepositoryManager and TaskList instances that are managed by TasksUiPlugin: * TasksUiPlugin.getRepositoryManager() * TasksUiPlugin.getTaskListManager().getTaskList() Once these become accessible from core TracRepositoryConnector, TracTask, TracTaskExternalizer Trac*Handler, TracQuery and TracQueryHit can be moved to trac.core.
Created attachment 48997 [details] mylar/context/zip
Is it possible to instantiate those classes with a TaskList instance, or pass that instance to the methods that need it? And consider doing the same for RepositoryManager? Using that approach, rather than a central entry point, can make for easier unit testing and better encapsulation...
Yes, I certainly agree that getting rid of accessing singletons as much as we can is the way to go. This will take quite a bit of refactoring but this shouldn't be too hard. I am not sure about classes extending AbstractRepositoryConnector as these are created through an extension point. We may need a setTaskList() and setRepositoryManager() method here. In most other cases extending signatures (e.g. AbstractQueryHit.getOrCreateCorrespondingTask(TaskList)) should do it.
Yes, supporting turned out to be a big refactoring, but it's done now. BugzillaRepositoryConnector is now in bugzilla.core, and TracRepositoryConnector has been updated accordingly. So go ahead and try to extract it following the Bugzilla example and let me know if anything blocks you.
I have moved the remaining classes with only minor hiccups. The implementation of the repository attribute serialization needs to be cleaned (I think TracRepositoryConnector should not depend on TracCorePlugin) but this will be addressed as part of bug 150680.
Created attachment 49712 [details] mylar/context/zip
