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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Just to clarify what I after is not
having to author two sets of metadata.  From a repository USER's point
of view I have a bundle, I add it to the repo.  I need a bundle, I
query the repo and get the thing I need/want.  When adding a bundle
to the repo the repo itself should interrogate the bundle and find any
dependencies.  

There is a challenge in that there may
be dependencies that cannot be detected.  For example, we have this
in our Help setup where help needs an appserver.  Typically Tomcat
is supplied but there may well be others.  You would not want to spec
help to depend on Tomcat.  If we were using services then you would
spec Help to need the webapp service.  Perhaps when we have declarative
services that will be a possibility but there will still be such scenarios
where the public contract implied by services is not appropriate and alternative
mechanisms (e.g., the extension registry) are used.

Grouping bundles is an interesting notion
that solves this issue as well as allows function producers to explicitly
declare sets of bundles that go together.  A bundle group can simply
be viewed as a bundle that aggregates the constituent parts.  However
it is actually represented it is just a unit that exports the union of
the exports in its contents and imports/required the union of its prerequisites.
etc.  

Expressing or representing these capabilties
and requirements in an an open, extensible way is goodness.

Jeff

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

09/23/2005 12:16 PM

Please respond to
Equinox development mailing list

To	Thomas Watson <tjwatson@xxxxxxxxxx>
cc	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, heavy@xxxxxxxxxxxxxx
Subject	Re[4]: [equinox-dev] OBR2

Good idea, but I assume it can be used to generate
the meta data?

I think this is an example where the generic requirements capability
model shines. We will have lots of dependencies that need to be
modeled. Modeling them semantically in the repo format will make the
repo format a major spec work undertaking.

Kind regards,

     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
  


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