Re: Re[6]: [equinox-dev] OBR2

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

For the most part.  I believe that
explicit groups are necessary.  It is natural to group things and
then group the groups etc.  Doing this with queries is possible but
ends up being roundabout.  Your point about explosion is valid but
queries don't solve the problem. For example, who is going to manage the
queries? How do I tell you about my group?  Do I send you my query?
 What if someone adds something that matches the query but I did not
intend for that to be part of the group?  How do you compose multiple
query-based groups to make a composite group?

Groups can be done in a way that allows
you to have your groups and me to have mine.  We can share the group
definitions if we want but do not have to.  If shared they can be
inthe repo as first class enties.  They (perhaps) can be versioned
and express dependencies of their own.

Jeff

Peter Kriens <Peter.Kriens@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/25/2005 11:14 AM

Please respond to
Equinox development mailing list

To	Jeff McAffer/Ottawa/IBM@IBMCA
cc	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject	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

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev