[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] OBR2
- From: Peter Kriens <Peter.Kriens@xxxxxxxx>
- Date: Wed, 28 Sep 2005 09:30:19 +0200
- Delivered-to: firstname.lastname@example.org
- Organization: aQute
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.
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> To: Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
OG> cc: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
OG> Subject: Re: [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>> 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>> 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>> Thomas Watson <tjwatson@xxxxxxxxxx>cc
JM>> Equinox development mailing list
JM>> <equinox-dev@xxxxxxxxxxx>, heavy@xxxxxxxxxxxxxxxxxxxxx
JM>> Re: [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>>> 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
>>>> 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
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>> equinox-dev mailing list
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> equinox-dev mailing list
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
AOL,Yahoo, Skype pkriens ICQ 255570717