Re: [e4-dev] Re-exporting Require-Bundle

[Eike Stepper <stepper@xxxxxxxxxx>]

Benjamin Muskalla schrieb:
> Hi Eike,
>
> first off: +1 for not re-exporting bundles.
>
> See comments inline.
>
> Eike Stepper wrote:
>> If it is part of the higher API, e.g. B publishes method signatures
>> with parameter types from A, then bundle A should be re-exported
>> since it is a pain for API B clients to recurse through all the
>> non-explicit, transitive dependencies.
> I see your point that this is a real pain but in my eyes it is
> something which should be solved by better tooling support (Chris?)
> and not by reexporting the dependencies in the host bundle.
Better tooling is always good :P

Btw. usually the discussion "require-bundle vs. import-package" is
somehow related to the "re-exporting yes/no" discussion. I think that
the ability to re-export packages at OSGi level would not solve the
general re-export concerns. But if someone decided a re-export is
desireable in a certain case then doing it on package level would be way
better.


>
>>
>> In this particular case it seems as if dependencies (require-bundle)
>> on some EMF bundles raised the issue. I know that the APIs of EMF
>> probably belong to the most stable ones in Eclipse.
> I don't think that it's about EMF in particular. 
Certainly not, but EMF is a bit special here since it usually requires
export of all (generated) packages, even those that are considered
implementation. That is to enable extending models to derive from the
generated impl classes.

> It's always the same problem when you add API that doesn't belong to
> your specific bundle. I stumbled across so many places where a
> dependency could be removed because it was replaced with something
> else or was obsolete - but it was not possible as other bundles relied
> on the reexported dependency instead of having their own dependency. 
I must have misunderstood something in your argument. If you really have
this problem, then you must either:

A) never have needed this re-export, i.e. you only used the dependency
internally but nevertheless re-exported it. Unlikely :P
B) have changed your own API anyway to be able to get rid of the
dependency. In this case I doubt that clients would mind that you
cleanup your API (including remove of unneeded dependencies) completely.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> I think with a better tooling support in this case nobody would notice
> the difference. But we still have the advantage of not managing the
> reexports forever.
>
> Cheers
>   Ben
>
>>
>>  
>> Thomas Watson schrieb:
>>>
>>> +1
>>>
>>> Re-exporting is evil. I think it really dirties your bundle's API
>>> contract. Unless you use a real brittle version range on your
>>> require-bundle constraint you cannot be that confident that your API
>>> signature will remain constant for a particular version of you
>>> bundle. I would almost go as far as to say we should add a warning
>>> in PDE to flag any usage of re-export. I think it is simply a bad
>>> practice re-export bundles. The problem is once you have added
>>> re-export you cannot remove it without it being considered a
>>> breaking API change. This would be equivalent to removing API from
>>> your bundle.
>>>
>>> Tom
>>>
>>>
>>>
>>> Inactive hide details for John Arthorne ---06/11/2009 04:22:57
>>> PM---I noticed org.eclipse.e4.ui.model.workbench re-exports a coJohn
>>> Arthorne ---06/11/2009 04:22:57 PM---I noticed
>>> org.eclipse.e4.ui.model.workbench re-exports a couple of EMF
>>> plug-ins. As a general reminder, re-exporting should be
>>>
>>>
>>> From:    
>>> John Arthorne <John_Arthorne@xxxxxxxxxx>
>>>
>>> To:    
>>> e4-dev@xxxxxxxxxxx
>>>
>>> Date:    
>>> 06/11/2009 04:22 PM
>>>
>>> Subject:    
>>> [e4-dev] Re-exporting Require-Bundle
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>> I noticed org.eclipse.e4.ui.model.workbench re-exports a couple of
>>> EMF plug-ins. As a general reminder, re-exporting should be avoided
>>> if possible, since it means you are essentially publishing the
>>> entire API of that other bundle as part of your bundle, and
>>> committing to maintaining that re-exported content indefinitely.
>>> Avoiding re-export generally gives more flexibility to remove or
>>> refactor dependencies in the future without breaking the API exposed
>>> by your plug-in. Does anyone know of a particular reason for the
>>> re-exports in this case? If I don't hear back, I'll make an attempt
>>> at fixing this to avoid
>>> re-export._______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>   
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>