On Mon, Oct 5, 2009 at 10:03 PM, Richard S. Hall <[email protected]> wrote: > > > On 10/5/09 22:54, David Savage wrote: >> >> Hi Matthias, >> >> You may also be interested in looking at the sigil resolver [1] as >> this can be configured to understand both directory based repositories >> and OBR (r)epositories for use in offline environments (in sigil's >> case development environments to satisfy compilation dependencies). >> >> The situation you describe actually sounds similar to one I'm working >> on for runtime support in sigil, i.e. deploy a bundle from an IDE >> development environment along side it's dependencies to an OSGi >> runtime for debug purposes. >> > > I didn't understand that this is what he wants to do. I understand he wants > to deploy from an OBR repository to a local directory, not the framework > (i.e., no installBundle()).
Yep sorry I guess that did confuse things - I just meant that the sigil resolver is used to perform the calculation of dependencies for a given bundle (or set of bundles) based on the set of configured directory and OBR (r)epositories. It's an implementation detail to install them into a running framework in this case. Possibly off target but thought I'd raise it in any case... Regards, Dave > > -> richard > >> Differences in the two approaches which may or may not be important >> for you are that the sigil resolver is currently always starting from >> a clean slate (i.e. it assumes an empty framework - which it has >> control over) where as the felix bundle resolver is embedded within >> the framework so is taking account of already installed bundles. >> >> Regards, >> >> Dave >> >> [1] >> http://svn.apache.org/viewvc/felix/trunk/sigil/common/core/src/org/apache/felix/sigil/repository/IBundleResolver.java?revision=796467&view=markup >> >> On Mon, Oct 5, 2009 at 8:34 PM, Matthias Neubert<[email protected]> >> 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? >>> >>> 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. >>> >>> 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? >>> >>> 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]
