[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[8]: [equinox-dev] OBR2
|
JSR 124 ... the requirements capability model is used here. I am
however not sure what the progress is. JSR 233 is also involved. I
think it is the successor of JSR 124.
Kind regards,
Peter Kriens
OG> How does this discussion on OBR2 relate to what SUN is doing
OG> for server-side modelling of services?
OG> Can't remember the JSR though... but I remember talking with
OG> SUN people at some of the OSGi meetings.
OG> Peter, remember, we talked about this about a year ago at
OG> your house, during a MEG discussion about deployment packages...
OG> With a generic framework for resources providing and requiring capabilities.
OG> The server-side framework has a plug-in approach where anyone
OG> can define its own capabilities and how to match them...
OG> I am not saying that they have solved it, I don't know enough
OG> about the current state, but the goals are very similar and
OG> they have been working at this for quite a while.
OG> Just a thought...
OG> Best regards,
OG> Olivier Gruber, Ph.D.
OG> Persistent & Distributed Object Platforms and Frameworks
OG> IBM TJ Watson Research Center
OG> Peter Kriens <Peter.Kriens@xxxxxxxx>
OG> Sent by: equinox-dev-bounces@xxxxxxxxxxx
OG> 09/25/2005 12:14 PM
OG> Please respond to Equinox development mailing list
OG>
OG> To: Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
OG> cc: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
OG> Subject: Re[6]: [equinox-dev] OBR2
OG> I think we agree ...
OG> The repo metadata should have no semantic knowledge of its contents.
OG> The requirements/capabilities should be generic. When you import you
OG> translate the specific (import-package, require-bundle, scree=128x256,
OG> etc) requirements to generics. This means that the repo does not need
OG> to have semantic knowledge.
OG> However, a group should be the result of a query and not explicitly
OG> submitted to the repo. If you do that, you always end up in a
OG> combinatorial explosion of groups. The diversity out there is so high
OG> ... which en then usually means only 1 configuration is supported.
OG> Works maybe for Windows, but OSGi needs something more flexible imho
OG> because portability is at the root.
OG> Kind regards,
OG> 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
JM>> <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
OG>
OG> --
OG> Peter Kriens Mob +33633746480
OG> 9C, Avenue St. Drézéry Tel +33467542167
OG> 34160 Beaulieu, France Tel +15123514821
OG> Tel +33870447986
OG> AOL,Yahoo, Skype pkriens ICQ 255570717
OG> _______________________________________________
OG> equinox-dev mailing list
OG> equinox-dev@xxxxxxxxxxx
OG> 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
