Re: Re[2]: [equinox-dev] new services

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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