Bug 149981

Comment 1 Tomasz Pik 2006-07-07 16:22:25 EDT

Please, tell me, what's the plan for doing this:
* move 'eclipse-related' classes to other plugin;
* move 'planned-to-be-not-coupled-to-eclipse' classes to other plugin/location;
* just make org.eclipse.mylar.provisional.tasklist do not depending on eclipse classes;
thanks for answer.

Comment 2 Mik Kersten 2006-07-07 17:18:05 EDT

The plan is to move almost all of the classes from org.eclipse.mylar.provisional.tasklist along with a few other non-UI classes into the new org.eclipse.mylar.tasks plug-in.  This plug-in will only be coupled to org.eclipse.core.runtime, and will be usable in JAR form, and could provide additional build scripts for alternate packagings (e.g. to support Maven and other forms of headless use). 

Comment 3 Mik Kersten 2006-07-13 23:22:50 EDT

Mostly done.  See message to mylar-dev list.  I'll leave this open to gather any additional feedback you may have on using this.  What I see as likely is splitting the AbstractRepositoryConnector into a core and UI part so that it can be accessed in headless mode and provide a single API for multiple repositories.  However, that would create a hard dependency on org.eclipse.core.runtime, since we use those facilities for running jobs and managing synchronization.

Comment 4 Mik Kersten 2006-08-04 03:31:46 EDT

Too many good patches came in in the past few days, so I will have to wait until I return from vacation (end of next week).  The split will be straightforward--AbstractRepositoryConnector will have all the UI and wizard stuff and a seperate class that it uses (e.g AbstractServerFacade) will have the creation/query/modification code.

Comment 5 Mik Kersten 2006-08-25 03:22:45 EDT

This  is nearly done, and along with it I separated out and encapsualted TaskSynchronizationManager.  What remains is adding an extension point, fixing up some naming, and doing other fixing, so NOTE that not all tests pass yet.  I'll be finishing Friday morning PST, but committed the current status in case others need to synch up before then.

Comment 6 Mik Kersten 2006-08-25 03:24:53 EDT

Also note that the version before this major refactoring is tagged as R_0_6_1_prerefactoring

Comment 7 Mik Kersten 2006-08-25 13:04:41 EDT

Nearly complete, so you can now feel free to updated your woskapces.  There are a couple of Bugzilla test problems due to synchronization but we'll get those sorted out shortly.  Do not bootstrap until this bug is marked resolved.

Rob: note that createTaskFromExistingId hangs, probably due to my removing a forceSynchExec for testing.

Comment 8 Mik Kersten 2006-08-25 14:56:21 EDT

Done.  AllTests pass, and I've updated my bootstrap workspace.  The new class is AbstractRepositoryConnectorUi, and the extension format has changed to the one listed below.  While there were large changes in mylar.tasks.core and mylar.tasks.ui, Connectors were largely insulated from these beyond the split.  Note:
* RepositorySynchronizationManager now encapsulates the synchronization policy, not the AbstractRepositoryConnector (at some point we may want to move that class into mylar.tasks.core as well, probably when we move search support into tasks.core)
* TaskRepositoryManager is in mylar.tasks.core and can be used headless (as per Nathan's request)

   <extension
         id="org.eclipse.mylar.bugzilla.repository" 
         name="Bugzilla Repository"
         point="org.eclipse.mylar.tasks.ui.repositories">

      <connectorCore
            class="org.eclipse.mylar.internal.bugzilla.ui.tasklist.BugzillaRepositoryConnector"
            id="org.eclipse.mylar.bugzilla.tasklist.repositories"
            name="Bugzilla Repository Connector"
            type="bugzilla"/>
            
      <connectorUi
            brandingIcon="icons/eview16/bugzilla-logo.gif"
            class="org.eclipse.mylar.internal.bugzilla.ui.tasklist.BugzillaRepositoryUi"
            name="Bugzilla Repository Ui"/>
   </extension> 

Comment 9 Mik Kersten 2006-08-25 14:56:23 EDT

Created attachment 48761 [details]
mylar/context/zip

Comment 10 Eugene Kuleshov 2006-08-25 15:05:06 EDT

Looks great, except strange choice of "Ui" suffix... :-)

Comment 11 Mik Kersten 2006-08-25 15:12:26 EDT

Do you mean the camel casing or the actually name of the class?  On Mylar we take Josh Bloch's "Effective Java" convention if camel casing acronyms, and yes, the case where it looks weirdest is when "Ui" is at the end.  The rest of Eclispe is mixed in this convention although they tend to capitalize acronyms, and I think that they always capitalize two letter acronyms too.

Comment 12 Eugene Kuleshov 2006-08-25 15:45:24 EDT

(In reply to comment #11)
> Do you mean the camel casing or the actually name of the class?  On Mylar we
> take Josh Bloch's "Effective Java" convention if camel casing acronyms, and
> yes, the case where it looks weirdest is when "Ui" is at the end.  The rest of
> Eclispe is mixed in this convention although they tend to capitalize acronyms,
> and I think that they always capitalize two letter acronyms too.

Yes. I meant "Ui" vs. "UI". It is matter of personal preferences, except that "camelized" search by type could be confusing.