felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matias SM <matias...@yahoo.com.ar>
Subject Re: OBR RepositoryAdmin content in embeded framework
Date Sat, 09 Jun 2012 15:44:01 GMT

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<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
>>>>>>>> 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(..)",
>>>>>>>> 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
>>>>>> 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
Hope it will create an interesting discussion about the usefulness of my 
Kind regards

> -> richard

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

View raw message