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