Re: [p2-dev] new bundle in the maintenance branch

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Just an update after an offline discussion
on this with Susan. I think TranslationSupport really belongs in the metadata
bundle. The metadata API exposes the default language strings, but any
client who cares about those strings could reasonably want to access the
translated strings as well. In fact it could even be integrated in the
API via methods like IInstallableUnit.getProperty(String key, Locale l).
Even if we keep a separate TranslationSupport class I think it makes sense
that this lives alongside the code that provides the English strings (in
same bundle/package). We can easily remove the current dependency that
TranslationSupport has on the engine bundle, and apart from that it just
references the metadata API. I can make this change if everyone is ok with
it.

LicenseManager is a bit different. It
doesn't really belong in p2.metadata. Our current usecases for it only
involve the UI so maybe it's ok for this to live in the UI API. I.e., for
clients using engine/director/etc directly, there is no notion of a license
acceptable step in the provisioning process so the concept isn't needed.

My other question is still open though
- are there significantly more API bits that belong in this "between
core and operations" space? If we have a real need for it then we
should add it, but just trying to avoid the extreme decomposition of "one
bundle per API class" <g>

John Arthorne/Ottawa/IBM@IBMCA
Sent by: p2-dev-bounces@xxxxxxxxxxx

11/19/2009 11:13 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To	p2-dev@xxxxxxxxxxx
cc
Subject	Re: [p2-dev] new bundle in the maintenance branch

This kind of "common dumping ground" bundle worries me - what
usually happens is that it ends up pulling in a big list of dependencies
as more services are added, and then anyone who needs a single one of those
services pulls in everything. Are there more examples of things we want
to put here in the near term? The two services that are there today could
easily be put in the org.eclipse.equinox.p2.metadata bundle (it adds two
classes, very little code, and no extra dependencies). The only weird dependency
is that TranslationSupport depends on the engine. I think that could easily
be refactored by having an internal hook for the "default locale query"
that the engine bundle plugs into when it starts. We already have about
30 bundles which seems like more than enough granularity for all the different
deployment scenarios we are interested in... 

John

Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

11/18/2009 07:37 PM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To	P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject	[p2-dev] new bundle in the maintenance branch

Hi, everyone.
I added a new bundle today, org.eclipse.equinox.p2.common, after talking
to Pascal. We needed a home for utility stuff that is above the core and
underneath the UI. I didn't want the p2.operations bundle to become a grab
bag of utils just because it lives in the same space as the utils (above
core, under UI).

The related bugs are
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253203
https://bugs.eclipse.org/bugs/show_bug.cgi?id=295380

The project set has been updated so you should be able to reload it.
UI tests are passing

Some of the rcp examples have not been updated yet, so don't be concerned
if they are not compiling.
The relevant patches to PDE and WST can be found in

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

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