[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] new bundle in the maintenance branch


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