[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re[2]: [equinox-dev] new services


I concur. From a device perspective, where we may offer subsets of API, we don't wan't much use of Require-Bundle because it ties an app to a particular bundle or causes us to use the same name for bundles with different content. Encouraging use of Import-Package makes a lot of sense.

                Mark



Thomas Watson/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/23/2007 02:26 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: Re[2]: [equinox-dev] new services






The problem with defining a symbolic-name for a bundle is that it becomes API which we must support for many years.  We should think about a way to loosen this in Equinox.  In many cases if we use Import-Package instead of Require-Bundle then we would not care as much about the symbolic name of the bundle.


Symbolic Names are still important for versioning and deployment but if clients always used Import-Package to access the packages then we would potentially have more freedom to rename symbolic names.  Should we come up with a way to mark symbolic names as not API for Require-Bundle?  This is similar to the x-internal/x-friends directives that Equinox supports for Export-Package.  This way we can have the freedom to move certain packages from bundle to bundle.  When a symbolic name is marked as x-internal it would indicate that the exported packages from the bundle must/should be access using Import-Package not Require-Bundle.


Not sure this is a good idea or not, we still need to think of good symbolic names.  Just an idea I had while thinking about names for all our "util/common" bundles.  Thought it would be better for these types of bundles if the name was not so important from an API perspective.


Tom




Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/19/2007 12:24 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Pavlin Dobrev <p.dobrev@xxxxxxxxxxx>, Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: Re[2]: [equinox-dev] new services








The IP process moves along depending on the other work they are doing.  Right now it is pretty busy with Europa clearances etc.  I will look into this.  We should be able to get this working with the parallel IP process now that Eclipse has an official incubator.


As for naming:

... equinox.ip : this is still fine with me.  While IP = Intellectual Property, in the context of equinox its not clear that anyone will be confused.


... equinox.util : I agree to a certain degree that combining with equinox.common might be a good path but I am concerned by overlapping function etc and the size of util.  So initially we should create equinox.util but I would like ot explicitly state that we have to review this structuring before graduation.  It will be confusing for people to have equinox.common and equinox.util with no story for how they relate to one another.


Jeff



Pavlin Dobrev <p.dobrev@xxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/18/2007 08:13 AM

Please respond to
Pavlin Dobrev <p.dobrev@xxxxxxxxxxx>; Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Jeff McAffer/Ottawa/IBM@IBMCA
cc
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject
Re[2]: [equinox-dev] new services









Hi Jeff,


Is there any indication when IP verification procedure will complete?


Some comments:


org.eclipse.equinox.provisioning
-> org.eclipse.equinox.ip

such naming is not a very good idea - mainly because IP = Intelectual Property

maybe we may use "initialprovisioning", "initialprv" or "iprv" (
org.eclipse.equinox.iprv)?

org.eclipse.equinox.util

We may combine with equinox.common (preferable). But maybe initially it will be separately service?

Now it is used in all other implementation because it provides basic services for logging, collections, xml parsing, timer, thread pooling, object pooling etc.

-Pavlin
>
Great point (about provisioning).  Yes, we should do a naming review.  It probably makes sense to do that before committing just to reliminate churn.  Let me take a initial pass here...

org.eclipse.equinox.component

- Name is too general as noted in the originating bug report.  Choices here are org.eclipse.equinox.scr (Service Component Registry) or org.eclipse.equinox.ds (replace the current "ds" bundle when the new one has been reviewed and graduated.
- personally I lean towards "ds".  If all goes well would we keep to implementations around?  If not, why change the name?

org.eclipse.equinox.io

- no particular issues here

org.eclipse.equinox.provisioning

- Name collision with the Equinox provisioning work
- perhaps consider org.eclipse.equinox.ip?  Other options/thoughts?

org.eclipse.equinox.util

- conceptual conflict with equinox.common.  Consumers will be confused as to what is in common vs. util.
- consider combining?
- util appears to have lots of useful stuff in it.  Reviewing how and when it is used may help us come to some naming/grouping conclusions.

org.eclipse.equinox.wireadmin

- collides with the current wireadmin bundle.
- as with the DS implementation, perhaps the new one should just replace the old one when it graduates?  In that case we can leave the name as is.

Thoughts?

Jeff







Pavlin Dobrev <p.dobrev@xxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
04/13/2007 05:12 PM


Please respond to



Pavlin Dobrev <p.dobrev@xxxxxxxxxxx>; Please respond to

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] new services













Hi Jeff,


No problem from our side after the IP verification process complete.


Maybe also is good to discuss implementation packages and names because it is good do refractoring prior the check-in.

Especially I think that we agree on the name org.eclipse.equinox.scr for Declarative Services.


Regarding initial provisioning - currently I use similar to OSGi package name (org.eclipse.equinox.provisioning) but because of the conflict with general provisioning work already being done in the incubator we may decide for the other name.

What do you think?



-Pavlin




>
As the new services from Prosyst come into the repo and builds, we should ensure that the Bundles page is updated.  It would actually be a great idea to create some wiki pages around each of the services (new and old) to tell people about the options, how to run/use them, etc.  Can the people owning the services take the task of driving this content?

Jeff






_______________________________________________

equinox-dev mailing list

equinox-dev@xxxxxxxxxxx

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






_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev