felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OBR RepositoryAdmin content in embeded framework
Date Tue, 29 May 2012 23:42:05 GMT
On 5/29/12 18:31 , Matias SM wrote:
>
>
> On 29/05/12 13:58, Richard S. Hall wrote:
>>
>> On 5/29/12 12:49 , matias san martin wrote:
>>>> ________________________________
>>>> De: Richard S. Hall<heavy@ungoverned.org>
>>>> Para: users@felix.apache.org
>>>> Enviado: martes, 29 de mayo de 2012 0:02
>>>> Asunto: Re: OBR RepositoryAdmin content in embeded framework
>>>>
>>>> On 5/28/12 21:03 , Matias SM wrote:
>>>>> Hi again Richard,
>>>>> I've been investigating further and I realized my confusion came 
>>>>> because it seems that, while OBR takes into account the installed 
>>>>> "by hand" bundles to resolve as requested, it doesn't respond 
>>>>> about those resources (associated to the bundles installed "by 
>>>>> hand").
>>>>> That is, if I try to "resolve()" a bundle by using the 
>>>>> RepositoryAdmin, it knows about the installed by hand bundles. 
>>>>> But, if I try to "getResources()" or "discoverResources(..)", I 
>>>>> get no results.
>>>>>
>>>>> Is there a way of getting the installed "by hand" resources from 
>>>>> the RepositoryAdmin without creating a repository?
>>>> Off the top of my head, I don't know. I would assume that the 
>>>> RepositoryAdmin is only querying actual repositories for 
>>>> discoverResources() et al, so you won't get back resources from the 
>>>> "fake" local repository.
>>>>
>>>> Not sure what is the correct thing here, but I'm inclined to think 
>>>> the current behavior makes sense, since technically installed 
>>>> bundles do *not* form a repository (e.g., it is not possible to 
>>>> download them).
>>>>
>>>
>>> Thank you for the clarifications Richard, I understand your
>>> point and I agree with you. However, I may be wrong but, bundles (I
>>> think) are always installed from a source, so it may be possible to use
>>> that as the URI of the resource.
>>
>> Yes, they are always installed from a source, but that information 
>> isn't saved when installing via OBR, nor can the bundle include its 
>> source in its manifest, since it may come from a number of sources.
>>
> I understand. Also, I think it would be a nice improvement to have 
> some logic capable of fetching this information (maybe intercepting 
> the installation command or something) and creating a full fledged 
> repository with it.

Yes, the would be the approach. The current OBR impl is too simplistic 
to do that, but a beefed up implementation could do something like that.

>
>>> Related to this, now that you mention it, I think that when creating a
>>> repository from bundles (by using the API), the resulting xml doesn't
>>> have a an URI attribute for the resources. Wouldn't that be wrong,
>>> taking into account that the resources should be downloable?
>>
>> Not sure. I've only created repositories using bindex and via the 
>> maven-bundle-plugin and both give a URI attribute.
>>
>
> The case I mention could be reproduced by creating resources from 
> bundles (DataModelHelper#createResource(Bundle)) and then a repository 
> from those resources (DataModelHelper#repository(Resource[])). I think 
> it is related to what you said about OBR being unable to get an URI 
> from the Bundle.

Yes, I'd imagine if it is starting from a Bundle, then there isn't much 
it can do about creating a URI.

> Should I create a JIRA issue to check this case?

I guess the important question is, what would you like to have it do? 
There are valid use cases for modeling bundles as resources in a 
repository as OBR does for deploying against installed bundles, so we 
can't disallow it.

Do you have some other suggestion?

-> richard

>
> Kind regards and thank you for your comments
>
>> -> richard
>>
>>>
>>> Kind regards
>>>
>>>
>>>> ->  richard
>>>>
>>>>> Thank you in advance for your help
>>>>> Kind regards
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message