Re: OBR RepositoryAdmin content in embeded framework

[Matias SM <ma...@yahoo.com.ar>]

On 29/05/12 23:50, Richard S. Hall wrote:
> On 5/29/12 20:46 , Matias SM wrote:
>>
>>
>> On 29/05/12 20:42, Richard S. Hall wrote:
>>> 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<he...@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?
>>
>> Maybe throwing an exception when calling writeRepository(..) with 
>> resources that doesn't have URI (i.e. avoid invalid persistent 
>> repositories, but allow an abstraction similar like that for 
>> in-memory use).
>> I know this is not a great solution but at least would avoid 
>> (misleading) successful creation of "invalid" repositories.
>
> I don't have a strong opinion on this, but feel free to open a JIRA 
> issue to see if anyone else has an opinion.
>
It took me some time but finally created the JIRA issue
https://issues.apache.org/jira/browse/FELIX-3541
Hope it will create an interesting discussion about the usefulness of my 
recommendation.
Kind regards

> -> richard
>

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