On Thu, Oct 8, 2009 at 10:34 AM, Arjun Panday
<[email protected]> wrote:
> Le 10/08/2009 11:21 AM, Richard S. Hall a écrit :
>>
>> On 10/8/09 10:54, Arjun Panday wrote:
>>>
>>>> Hmm. So maybe two local repositories, one for the system bundle and one
>>>> for everyone else or just special case the system bundle and just have one
>>>> local repo for the other bundles that gets included in the repo list.
>>>
>>> yes, that's more like it..
>>> it's actually what i was doing in my (dirty) patch where the local
>>> repository was specifically ignoring anything not coming fom the system
>>> bundle.. so your idea enables wrapping this behaviour behind a clean
>>> interface.
>>> So if i understand it right, instead of one local repository and one
>>> remote repository, we'd have
>>> - one "LocalSystemRepository"
>>> - one "LocalInstalledRepository"
>>> - one "RemoteRepository"
>>> and the API to remove one or the other (or at least the
>>> LocalInstalledRepository) from the resolver..
>>
>> We already have that API, in RepositoryAdmin, but it might need to be
>> tweaked.
>
> indeed there is:
> boolean removeRepository(URL repository);
>
> so either we'd need to define URLs for the "system" and "installed"
> repositories, or add a new method
> boolean removeRepository(Repository repository);
> that could take an instance returned by
> Repository[] listRepositories();
> filtering somehow on Repository.getName()...
>
> is this what you have in mind?
In the sigil resolver we manage this via the concept of repository
sets. In the headless build the set is defined via the static
configuration of repositories for the build environment, i.e.
more felix/sigil/bldcommon/sigil-repos.properties
# repository config
-repositories: system, project, spring
system;provider: system
system;level: -1
project;provider: project
project;level: 0
project;pattern: \
${..}/common/**/[sigilproject] \
${..}/eclipse/**/[sigilproject] \
bld-ant;provider: filesystem
bld-ant;level: 1
bld-ant;recurse: true
bld-ant;dir: ${cache.dir:-${..}/cache}/ant/lib
spring;provider: obr
spring;level: 2
spring;url: http://sigil.codecauldron.org/spring-external.obr
spring;index: ${..}/build/spring-external.obr
spring;cache: ${..}/build/obr-cache
Note in this case the system repository is doing the job of providing
javax.* etc classes, the project repository is providing the yet to be
built bundles from the build workspace, and the other two repos are
providing preexisting bundles (from the file system or an obr index
respectively).
The "<repo-name>;level" property in the repository config defines the
order in which the resolver should search repos for dependencies, so
in this case the build will look first in system, then in the local
workspace, then in a cached file system directory and finally in the
spring enterprise bundle repository.
In the IDE we define names sets of repositories in a similar way and
then you can configure your project to chose which set of repositories
you want to use to resolve your dependencies.
Possibly a similar mechanism could work at runtime, i.e. instead of
having one global obr configuration you can pick and choose at resolve
time to pick up a predefined set?
>
> -arjun
>
>
>
> On 10/7/09 17:37, Arjun Panday wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> May I take the opportunity of this thread to bring some attention
>>>>>>> back to a JIRA issue I opened a bit over a year ago on pretty much the
>>>>>>> same
>>>>>>> subject (resolve vs install):
>>>>>>> https://issues.apache.org/jira/browse/FELIX-692
>>>>>>> http://www.mail-archive.com/[email protected]/msg01905.html
>>>>>>>
>>>>>>> It seems it has been long forgotten but the issue remains for us.
>>>>>>> Could someone please take another look at this?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Arjun
>>>>>>>
>>>>>>>
>>>>>>> Le 10/05/2009 10:25 PM, Richard S. Hall a écrit :
>>>>>>>>
>>>>>>>> On 10/5/09 21:34, Matthias Neubert wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I know
>>>>>>>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
>>>>>>>>> already, it helps somehow but the API part is a bit short.
>>>>>>>>> As far as I see the smartness of OBR is mainly located in the
>>>>>>>>> OBRCommandImpl.(e.g. selectNewestVersion() ) Using OBR as part of my
>>>>>>>>> Android
>>>>>>>>> app this doen't realy
>>>>>>>>> help me.
>>>>>>>>>
>>>>>>>>> So is there a way to tell OBR to use a specified download-folder?
>>>>>>>>
>>>>>>>> No, you will have to program it yourself using the OBR API. This
>>>>>>>> shouldn't be that difficult. Just resolve and save the bundles in the
>>>>>>>> resolve set (except for those that are already locally installed).
>>>>>>>>
>>>>>>>>> I ask because the approach you mentioned ("Any changes can be
>>>>>>>>> manually downloaded from the OBR repo to your local directory.")
>>>>>>>>> includes
>>>>>>>>> that Bundles are first downloaded by OBR and installed directly
>>>>>>>>> into felix cache, and second I download the same jar file a second
>>>>>>>>> time,
>>>>>>>>> to copy it in my file-install-watched directory. Since I develop
>>>>>>>>> for a mobile device this soultion produces the twice traffic, which I
>>>>>>>>> want
>>>>>>>>> to avoid.
>>>>>>>>
>>>>>>>> Makes sense. Then you need to program the single pass as I
>>>>>>>> mentioned.
>>>>>>>>
>>>>>>>>> But I like to use the logic in OBR, which avoids downloading a
>>>>>>>>> Bundle which is already installed into the framework (at least I hope
>>>>>>>>> it
>>>>>>>>> avoids that ;-) )
>>>>>>>>> I'm shure it's possible to implement some of this existing OBR
>>>>>>>>> behavior on my own, but I liked to avoid reinventing the wheel.
>>>>>>>>>
>>>>>>>>> Any hint about that OBR-download-folder approach?
>>>>>>>>
>>>>>>>> Something like this:
>>>>>>>>
>>>>>>>> 1. Get a Resolver from RepositoryAdmin
>>>>>>>> 2. Resolver.add() resources the resources you want to resolve.
>>>>>>>> 3. Resolver.resolve() to resolve them.
>>>>>>>> 4. If successfully resolved, then download
>>>>>>>> Resolver.addedResources(),
>>>>>>>> Resolver.getRequiredResources(), and
>>>>>>>> Reslver.getOptionalResources().
>>>>>>>>
>>>>>>>> That's basically it. The only thing you are missing here is that
>>>>>>>> Resolver.deploy() tries to minimize the number of installed bundles,
>>>>>>>> so it
>>>>>>>> will try to upgrade/downgrade existing ones if no one depends on them
>>>>>>>> rather
>>>>>>>> than install another version.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 05.10.2009 um 20:13 schrieb Richard S. Hall:
>>>>>>>>>
>>>>>>>>>> On 10/5/09 20:03, Matthias Neubert wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> today I've got some questions regarding OSGi Bundle Repository
>>>>>>>>>>> implementation of Apache Felix project.
>>>>>>>>>>>
>>>>>>>>>>> 1.
>>>>>>>>>>> I read about Peter Kriens tool bindex to generate a
>>>>>>>>>>> repository.xml for an own bundle repository server from OSGi-Bundle
>>>>>>>>>>> Infos
>>>>>>>>>>> (Manifest.mf)
>>>>>>>>>>> This sounds good, but the blog article was quite old and I didn't
>>>>>>>>>>> found the tool on Mr. Kriens website, it only was attached
>>>>>>>>>>> at this blog article.
>>>>>>>>>>> -> I this tool still working with current OBR version?
>>>>>>>>>>> -> is there some documentation available
>>>>>>>>>>> -> if its updated: is there an alternative?
>>>>>>>>>>
>>>>>>>>>> I think that is the version and it still works.
>>>>>>>>>>
>>>>>>>>>>> 2.
>>>>>>>>>>> Currently I work with File Install for watching a folder to
>>>>>>>>>>> install Bundle Jars which are copied in there.
>>>>>>>>>>> Now I planed to use OBR to resolve all referenced Bundles from an
>>>>>>>>>>> own Bundle Repository Server.
>>>>>>>>>>> I want to tell OBR to first download all required Bundles into
>>>>>>>>>>> the folder file install watches, and let fileinstall do
>>>>>>>>>>> the installation work.
>>>>>>>>>>>
>>>>>>>>>>> -> Currently OBR just downloads the Bundle directly into felix
>>>>>>>>>>> cache,and then installs it (which works proper)
>>>>>>>>>>> -> Is there some more documentation an usage examples for the OBR
>>>>>>>>>>> Api?
>>>>>>>>>>> (I want to write my own Bundle Management GUI as an OBR client)
>>>>>>>>>>> -> the best thing for my would be i I could tell OBR to use a
>>>>>>>>>>> given download folder and (in order to avoid conflicts) to tell OBR
>>>>>>>>>>> not to
>>>>>>>>>>> try to
>>>>>>>>>>> install and start (because this ist fileinstalls job in my
>>>>>>>>>>> scenario)
>>>>>>>>>>
>>>>>>>>>> The current documentation is sparse, but probably sufficient:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
>>>>>>>>>>
>>>>>>>>>> You could just call resolver.resolve() and then get its list of
>>>>>>>>>> bundles and make copies of them...of course, this isn't truly
>>>>>>>>>> equivalent to
>>>>>>>>>> doing resolver.deploy(), since deploy() tries to be smart. Another
>>>>>>>>>> approach
>>>>>>>>>> is to record the current set of installed bundles, then do
>>>>>>>>>> resolver.resolve() + resolver.deploy(), then compare the resulting
>>>>>>>>>> set of
>>>>>>>>>> bundles. Any changes can be manually downloaded from the OBR repo to
>>>>>>>>>> your
>>>>>>>>>> local directory.
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It would be nice if you have some hints for me.
>>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> Matthias
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
