[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[6]: [equinox-dev] OBR2
|
I think we agree ...
The repo metadata should have no semantic knowledge of its contents.
The requirements/capabilities should be generic. When you import you
translate the specific (import-package, require-bundle, scree=128x256,
etc) requirements to generics. This means that the repo does not need
to have semantic knowledge.
However, a group should be the result of a query and not explicitly
submitted to the repo. If you do that, you always end up in a
combinatorial explosion of groups. The diversity out there is so high
... which en then usually means only 1 configuration is supported.
Works maybe for Windows, but OSGi needs something more flexible imho
because portability is at the root.
Kind regards,
Peter Kriens
JM> Just to clarify what I after is not having to author two sets
JM> of metadata. From a repository USER's point of view I have a
JM> bundle, I add it to the repo. I need a bundle, I query the repo
JM> and get the thing I need/want. When adding a bundle to the repo
JM> the repo itself should interrogate the bundle and find any
JM> dependencies.
JM> There is a challenge in that there may be dependencies that
JM> cannot be detected. For example, we have this in our Help setup
JM> where help needs an appserver. Typically Tomcat is supplied but
JM> there may well be others. You would not want to spec help to
JM> depend on Tomcat. If we were using services then you would spec
JM> Help to need the webapp service. Perhaps when we have declarative
JM> services that will be a possibility but there will still be such
JM> scenarios where the public contract implied by services is not
JM> appropriate and alternative mechanisms (e.g., the extension
JM> registry) are used.
JM> Grouping bundles is an interesting notion that solves this
JM> issue as well as allows function producers to explicitly declare
JM> sets of bundles that go together. A bundle group can simply be
JM> viewed as a bundle that aggregates the constituent parts. However
JM> it is actually represented it is just a unit that exports the
JM> union of the exports in its contents and imports/required the
JM> union of its prerequisites. etc.
JM> Expressing or representing these capabilties and requirements
JM> in an an open, extensible way is goodness.
JM> Jeff
JM> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 09/23/2005 12:16 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Thomas Watson <tjwatson@xxxxxxxxxx>cc
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, heavy@ungoverned.orgSubject
JM> Re[4]: [equinox-dev] OBR2
JM> Good idea, but I assume it can be used to generate the meta data?
JM> I think this is an example where the generic requirements capability
JM> model shines. We will have lots of dependencies that need to be
JM> modeled. Modeling them semantically in the repo format will make the
JM> repo format a major spec work undertaking.
JM> Kind regards,
JM> Peter Kriens
TW>> Can we use SCR's component XML definition for service
TW>> dependancies? Even if the bundle does not use SCR directly can we
TW>> still use this schema to define service dependancies? I would not
TW>> want to define a whole new schema for this.
TW>> Richard, are you subsribed the the equinox-dev mailing list?
TW>> If not, please do so we don't have to keep cc'ing you on the
TW>> mails :)
TW>> Thomas Watson
TW>> Pervasive Development
TW>> Phone: 512-838-4533 Tie: 678-4533
TW>> tjwatson@xxxxxxxxxx
TW>> equinox-dev-bounces@xxxxxxxxxxx wrote on 09/23/2005 08:34:11 AM:
>>> Agree ... if it is not in the manifest, we can't generate it. But it
>>> is nice to populate a repo with only the data from the manifests and
>>> get reasonable results.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> RSH> Peter Kriens wrote:
>>>
>>> >>It absolutely MUST be possible to generate the metadata from the
>>> >>manifest.
>>> >>
>>> >>
>>>
>>> RSH> Well, it is not possible given the current state of bundle manifests to
>>> RSH> generate all repository metadata. For example, there is no way to
>>> RSH> generate service dependencies.
>>>
>>> RSH> If someone invents a new capability/requirement pair, there will be no
>>> RSH> way to generate it either.
>>>
>>> RSH> For the standard package/module-related stuff, we can generate them from
>>> RSH> the manifest.
>>>
>>> ->> richard
>>>
>>> RSH> _______________________________________________
>>> RSH> equinox-dev mailing list
>>> RSH> equinox-dev@xxxxxxxxxxx
>>> RSH> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>>
>>> --
>>> Peter Kriens Mob +33633746480
>>> 9C, Avenue St. Drézéry Tel +33467542167
>>> 34160 Beaulieu, France Tel +15123514821
>>> Tel +33870447986
>>> AOL,Yahoo, Skype pkriens ICQ 255570717
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM> --
JM> Peter Kriens Mob +33633746480
JM> 9C, Avenue St. Drézéry Tel +33467542167
JM> 34160 Beaulieu, France Tel +15123514821
JM> Tel +33870447986
JM> AOL,Yahoo, Skype pkriens ICQ 255570717
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
Tel +33870447986
AOL,Yahoo, Skype pkriens ICQ 255570717
