Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] org.eclipse.equinox.util bundle

Hi Jeff,


Should I rename org.eclipse.equinox.util packages to org.eclipse.equinox.internal.util or not. Some of the packages are used only by DS bundle in equinox distribution. Others are used for more than one bundle.


The nature of the packages used only from DS bundles are utilities - like thread pool, xml processing, io, common utilities for access to the framework structures etc. 

In our FW implementation such utilities are packaged in one bundle putil 

http://dz.prosyst.com/user-manuals/mBS_Equinox_Edition_2.0.0/framework/bundles/prosyst/system/putilfull/introduction.html similar to equinox.common bundle (license of PUTIL is EPL and the code is distributed with mBS Equinox Eddition). We want after including the code in Equinox to move our code to use donated one in order not to have duplication of the code. It will be strange other bundle to have a dependency with DS only for utility classes.


Now I work to remove as many as possible dependencies from util bundle but in some cases this will decrease performance (removing of thread pool) and increase used memory (remove usage of object pools). Do you think that this is the right way?




-Pavlin


>


Interesting.  This is a friend (no pun intended) of the problem raised recently on the PMC mailing list.  The idea of having whole bundles as "internal".  By default I suppose that if a bundle only ever exports x-internal := true things then there is nothing interesting for anyone to depend on the bundle for so there is no real need to depend on the bundle at all and the idea of marking the bundle "internal" does not matter. 


I am bummed by having another bundle that we have to ship and manage etc but if the code really is shared and used/useful across many bundles than having it actually shared is a good thing. 


Jeff 





Thomas Watson <tjwatson@xxxxxxxxxx> 

Sent by: equinox-dev-bounces@xxxxxxxxxxx 

11/30/2007 05:43 PM 

Please respond to

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To

Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 

cc


Subject

Re: [equinox-dev] org.eclipse.equinox.util bundle








equinox-dev-bounces@xxxxxxxxxxx wrote on 11/30/2007 08:08:22 AM:


> Hi all,

> For the org.eclipse.equinox.util bundle:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151

> I have some comments/questions.

> 1. Can I change the name to the "org.eclipse.equinox.internal.util"

> and kept here only the classes that are needed for more than one bundle?


There is no precedence for doing this in Eclipse.  But it does make some

sense to me.  This would make it obvious that the whole bundle is 

really just an internal implementation detail.  What do others think?


> 2. Still we will keep the bundle in the equinox distribution or we will

> move the classes to the org.eclipse.equinox.common.jar in the future?


For now I think we should make all the packages internal and use 

x-friends where appropriate for the other service bundles.  In the 

future it is possible that we could move the packages to common and 

make them real API with no "internal" name in the package.  But we 

will not do that unless the gain is substantial (i.e. needed by a 

large set of clients in the Eclipse community).


> Next week I will work on removing dependencies and some packages from

> the util bundle but I need decision about the packaging and naming

> prior finishing the work.

> -Pavlin


Thanks Pavlin.  For now you should move the packages out

of the equinox.util into other bundles where appropriate and rename 

the remaining packages to include "internal" in the name with 

x-friends for the bundles that need the package.


A final decision on the symbolic name of the util bundle can

be made after the package restructuring.


Tom.

_______________________________________________

equinox-dev mailing list

equinox-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev







Back to the top