[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re[4]: [equinox-dev] OBR2


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