You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matthias Neubert <su...@onlinehome.de> on 2009/10/05 20:03:29 UTC
OBR, File Install, bindex, repository.xml generation- related questions
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?
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)
It would be nice if you have some hints for me.
regards
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR, File Install, bindex, repository.xml generation- related questions
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
I want to deploy from an OBR repository, but the act of install and
start the new downloaded Bundle shall be done
by FileInstall-Bundle.
Reason: I only want to download the Bundles one time, and then keep
persistant in a directory.
Reason for that: in times of trouble (e.g. crash) I delete felix cache
dir on startup (of the felix-embedding android app)
Doing so will lead standard OBR approach to redownload and install and
start-procedure.
In my scenario, file install will use the already downloaded jar files
to install and start.
short: I wish OBR would have an option to deploy to a local directory,
so that an directory based installer could do the install-job instead
of OBR.
regards
Matthias
Am 05.10.2009 um 23:03 schrieb Richard S. Hall:
>
>
> 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()).
>
> -> 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<su...@onlinehome.de> 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: 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by Toni Menzel <to...@okidokiteam.com>.
Reading about your scenario, you might want to look at Apache Ace [1].Also,
if you are looking for bigger + current obr repositories, you may want to
look at the Sonatype Nexus OSGi Repository at [2].
State of OBR, its currently under review by the alliance. Als Peter keeps
saying "its not a solution, its an enabling technology". See [3]
[1] http://incubator.apache.org/ace/
[2] http://osgi.sonatype.org
[3]
http://www.sonatype.com/people/2009/07/nexus-pro-support-for-osgi-bundle-repositories/#more-2383
Toni
On Tue, Oct 6, 2009 at 6:15 PM, Matthias Neubert <su...@onlinehome.de>wrote:
> Hello,
>
> meanwhile I solved the question by following richards advices. It works
> pretty good. Uninstalling is solved
> by deleting files from the folder FileInstall watches.
>
> One thing is still open: is there a OBR way to update the installed Bundles
> to new Versions?
>
>
> Btw.: I found a BIndex decoumentation here:
> http://www.osgi.org/Repository/BIndex
> a nice blog with many infos here:
> http://www.osgi.org/blog/2007/07/osgi-bundle-repository-indexer-open.html
> and Sourcecode of BIndex here:
> http://www.osgi.org/svn/public/trunk/org.osgi.impl.bundle.bindex/
>
> regards
> Matthias
>
>
> Am 05.10.2009 um 23:33 schrieb David Savage:
>
>
> On Mon, Oct 5, 2009 at 10:03 PM, Richard S. Hall <he...@ungoverned.org>
>> 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<su...@onlinehome.de>
>>>> 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: 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
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: OBR, File Install, bindex, repository.xml generation- related questions
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
meanwhile I solved the question by following richards advices. It
works pretty good. Uninstalling is solved
by deleting files from the folder FileInstall watches.
One thing is still open: is there a OBR way to update the installed
Bundles to new Versions?
Btw.: I found a BIndex decoumentation here:
http://www.osgi.org/Repository/BIndex
a nice blog with many infos here:
http://www.osgi.org/blog/2007/07/osgi-bundle-repository-indexer-open.html
and Sourcecode of BIndex here:
http://www.osgi.org/svn/public/trunk/org.osgi.impl.bundle.bindex/
regards
Matthias
Am 05.10.2009 um 23:33 schrieb David Savage:
> On Mon, Oct 5, 2009 at 10:03 PM, Richard S. Hall
> <he...@ungoverned.org> 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<sureal@onlinehome.de
>>> >
>>> 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: 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by David Savage <da...@paremus.com>.
On Mon, Oct 5, 2009 at 10:03 PM, Richard S. Hall <he...@ungoverned.org> 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<su...@onlinehome.de>
>> 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: 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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()).
-> 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<su...@onlinehome.de> 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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by David Savage <da...@paremus.com>.
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.
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 <su...@onlinehome.de> 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: 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by David Savage <da...@paremus.com>.
On Thu, Oct 8, 2009 at 10:34 AM, Arjun Panday
<ar...@alcatel-lucent.fr> 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/users@felix.apache.org/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: 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/8/09 11:34, Arjun Panday 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?
Yep, something like that.
-> richard
>
> -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/users@felix.apache.org/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: 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
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?
-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/users@felix.apache.org/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: 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
-> richard
>
> -arjun
>
>
>>
>> -> richard
>>
>>>
>>> -arjun
>>>
>>>>
>>>> -> richard
>>>>
>>>> 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/users@felix.apache.org/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: 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
> 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..
-arjun
>
> -> richard
>
>>
>> -arjun
>>
>>>
>>> -> richard
>>>
>>> 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/users@felix.apache.org/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: 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/7/09 18:42, Arjun Panday wrote:
>
>> I don't think the idea is unreasonable, but I just don't have the
>> extra cycles to spend thinking about it and doing it.
> I know.. but talking with Marcel, i realized it may also be something
> Ace is interested in...
> Maybe when Pierre gets all setup with his committer status he can give
> a hand on this.. (right Pierre?!)
>
>> I think one way to achieve what you want, I think, is to have the
>> local repository show up in the list of repositories and just allow
>> you to remove it, right?
> I'm not sure.. the issue i see with this, is that my remote repository
> will then be missing all the JRE packages that are re-exported by the
> framework at runtime (like javax.* and so on...)
> unless there is a way to build a repository that would be aware of
> these, as not being part of a bundle?!....
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.
-> richard
>
> -arjun
>
>>
>> -> richard
>>
>> 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/users@felix.apache.org/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: 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
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/7/09 21:02, Marcel Offermans wrote:
> On Oct 7, 2009, at 18:42 , Arjun Panday wrote:
>
>>> I don't think the idea is unreasonable, but I just don't have the
>>> extra cycles to spend thinking about it and doing it.
>> I know.. but talking with Marcel, i realized it may also be something
>> Ace is interested in...
>
>
> For ACE we are definitely interested in a stand-alone resolver that
> can be used to:
> - import the current wirings of an existing (remote) framework;
> - check if a set of one or more bundles would resolve correctly when
> installed.
Well, OBR wouldn't be able to do that, since its resolver knows nothing
about wires. This is the uber resolver I want to do...currently, the
framework resolver is somewhat separable, but it still needs to be
improved in this area. David brought up this topic too.
-> richard
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> 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
Re: OBR, File Install, bindex, repository.xml generation- related questions
Posted by Marcel Offermans <ma...@luminis.nl>.
On Oct 7, 2009, at 18:42 , Arjun Panday wrote:
>> I don't think the idea is unreasonable, but I just don't have the
>> extra cycles to spend thinking about it and doing it.
> I know.. but talking with Marcel, i realized it may also be
> something Ace is interested in...
For ACE we are definitely interested in a stand-alone resolver that
can be used to:
- import the current wirings of an existing (remote) framework;
- check if a set of one or more bundles would resolve correctly when
installed.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
> I don't think the idea is unreasonable, but I just don't have the
> extra cycles to spend thinking about it and doing it.
I know.. but talking with Marcel, i realized it may also be something
Ace is interested in...
Maybe when Pierre gets all setup with his committer status he can give a
hand on this.. (right Pierre?!)
> I think one way to achieve what you want, I think, is to have the
> local repository show up in the list of repositories and just allow
> you to remove it, right?
I'm not sure.. the issue i see with this, is that my remote repository
will then be missing all the JRE packages that are re-exported by the
framework at runtime (like javax.* and so on...)
unless there is a way to build a repository that would be aware of
these, as not being part of a bundle?!....
-arjun
>
> -> richard
>
> 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/users@felix.apache.org/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: 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Arjun,
I don't think the idea is unreasonable, but I just don't have the extra
cycles to spend thinking about it and doing it.
I think one way to achieve what you want, I think, is to have the local
repository show up in the list of repositories and just allow you to
remove it, right?
-> richard
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/users@felix.apache.org/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: 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
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/users@felix.apache.org/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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: 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
Re: OBR, File Install, bindex, repository.xml generation- related questions
Posted by Matthias Neubert <su...@onlinehome.de>.
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: 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
Re: OBR, File Install, bindex, repository.xml generation- related
questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: 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