It still feels to me like you're putting the focus in the wrong place. The problem in this example is still fundamentally being caused by a poorly configured deployment containing unnecessary duplicates, so to me it sounds like you're saying that you want the system to be forgiving to bad configuration because user error is expected.
I can understand that, but if a user is doing things like installing multiple superfluous versions of the same bundle, it's only to be expected that their experience is not going to be perfect. Rather than trying to work around users who don't know how to configure their installation and organise their mods properly, isn't it better to think about how to make it easier for them so they won't/can't make these mistakes in the first place? For example, you say that there is nothing stopping them from (unnecessarily) installing the same bundle twice, but why? First of all, what actually constitutes the fundamental installation unit of a mod? I assume it's either a special bundle (marked as a mod by some particular capability/manifest header or contained file) or just a file containing whatever meta-data describes the mod and a set of requirements for the resolver? Whatever the case, since you say there is a friendly UI I assume users are not forced to manage naked bundles, right? So then they should only have to deal with selecting "mods", with resolution/installation (and conflict reporting) of dependency bundles managed transparently as a side-effect of their mod selection. In this case I'm still convinced there's no point in worrying about superfluous duplicates. Just disallow selecting different versions of the same mod as a primary unit of installation, and trust that any duplicates amongst the set of bundles resolved to satisfy the requirements of those mods are only those duplicates which are necessary. In other words they should avoid the problem described as according to the end of my previous email. On Sat, 22 Jul 2017 at 10:16 Mark Raynsford <list+org.o...@io7m.com> wrote: > On 2017-07-21T20:14:51 +0000 > elias vasylenko <eliasvasyle...@gmail.com> wrote: > > > > As for multiple versions of the same bundle providing the same service, > > well they would probably share the same service-ranking so that's no > longer > > a solution ... but then you have to wonder about the design choices which > > might allow this situation to happen. > > In my case, I'm producing a game engine where the game itself is a set > of bundles, and third party modifications to the game (new levels, new > creatures, etc) are also bundles. Users install new bundles via a > friendly UI, and although I can automate the installation of dependency > bundles via the repository and resolver services, there's nothing to > stop a user from installing two different versions of the same bundle. > > -- > Mark Raynsford | http://www.io7m.com > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
