[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>         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@xxxxxxxxxxxxxxxxxxxxx
 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>>  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>  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