[dsdp-tcf-dev] [Bug 273078] [tcf][api] Separate TCF Core from TCF Eclips

[bugzilla-daemon@xxxxxxxxxxx]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=273078  
Product/Component: Target Management / TCF

Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dsdp.tm.tcf-                |eugene.tarassov@xxxxxxxxxxxx
                   |inbox@xxxxxxxxxxx           |m




--- Comment #8 from Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx>  2009-04-28 15:01:33 -0400 ---
(In reply to comment #7)
> After experimenting with different approaches, I think the least disruptive way
> to do the split is to put TCF core code into a fragment, e.g.
> org.eclipse.tm.tcf.core. Everything seems fine, code is nicely exported through
> the host plug-in.
> 
> Do you want me to commit it?

Yes if you could please commit it - thanks for your investigations!

Initially, having a fragment feels odd because it's always bound to one host
bundle; that is, we couldn't easily write an alternative adaption layer (such
as "TCF OSGi wrapper") instead of the Eclipse adaption layer.

On the other hand, compared to what we have now it is definitely an improvement
splitting into fragment + bundle so I'm much in favor of doing this now. It
will give use immediate advantage of avoiding accidental introduction of
unwanted dependencies. And, I cannot see any immediate negative impact.

I have a feeling that in the longer run, explicit activation from Eclipse
(rather than implicit activation via classloader) might be preferable even
though it's API breaking. It would also help with bug 270615. But I'd prefer
getting the split done first, and discussing explicit activation in a separate
bug.

Thanks!


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.