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/[email protected]/msg01905.html
It seems it has been long forgotten but the issue remains for
us. Could someone please take another look at this?
Thanks,
Arjun
Le 10/05/2009 10:25 PM, Richard S. Hall a écrit :
On 10/5/09 21:34, Matthias Neubert wrote:
Hello,
I know
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
already, it helps somehow but the API part is a bit short.
As far as I see the smartness of OBR is mainly located in the
OBRCommandImpl.(e.g. selectNewestVersion() ) Using OBR as part
of my Android app this doen't realy
help me.
So is there a way to tell OBR to use a specified download-folder?
No, you will have to program it yourself using the OBR API.
This shouldn't be that difficult. Just resolve and save the
bundles in the resolve set (except for those that are already
locally installed).
I ask because the approach you mentioned ("Any changes can be
manually downloaded from the OBR repo to your local
directory.") includes
that Bundles are first downloaded by OBR and installed
directly into felix cache, and second I download the same jar
file a second time,
to copy it in my file-install-watched directory. Since I
develop for a mobile device this soultion produces the twice
traffic, which I want to avoid.
Makes sense. Then you need to program the single pass as I
mentioned.
But I like to use the logic in OBR, which avoids downloading a
Bundle which is already installed into the framework (at least
I hope it avoids that ;-) )
I'm shure it's possible to implement some of this existing OBR
behavior on my own, but I liked to avoid reinventing the wheel.
Any hint about that OBR-download-folder approach?
Something like this:
1. Get a Resolver from RepositoryAdmin
2. Resolver.add() resources the resources you want to resolve.
3. Resolver.resolve() to resolve them.
4. If successfully resolved, then download
Resolver.addedResources(),
Resolver.getRequiredResources(), and
Reslver.getOptionalResources().
That's basically it. The only thing you are missing here is
that Resolver.deploy() tries to minimize the number of
installed bundles, so it will try to upgrade/downgrade existing
ones if no one depends on them rather than install another
version.
-> richard
regards
Matthias
Am 05.10.2009 um 20:13 schrieb Richard S. Hall:
On 10/5/09 20:03, Matthias Neubert wrote:
Hello,
today I've got some questions regarding OSGi Bundle
Repository implementation of Apache Felix project.
1.
I read about Peter Kriens tool bindex to generate a
repository.xml for an own bundle repository server from
OSGi-Bundle Infos (Manifest.mf)
This sounds good, but the blog article was quite old and I
didn't found the tool on Mr. Kriens website, it only was
attached
at this blog article.
-> I this tool still working with current OBR version?
-> is there some documentation available
-> if its updated: is there an alternative?
I think that is the version and it still works.
2.
Currently I work with File Install for watching a folder to
install Bundle Jars which are copied in there.
Now I planed to use OBR to resolve all referenced Bundles
from an own Bundle Repository Server.
I want to tell OBR to first download all required Bundles
into the folder file install watches, and let fileinstall do
the installation work.
-> Currently OBR just downloads the Bundle directly into
felix cache,and then installs it (which works proper)
-> Is there some more documentation an usage examples for
the OBR Api?
(I want to write my own Bundle Management GUI as an OBR client)
-> the best thing for my would be i I could tell OBR to use
a given download folder and (in order to avoid conflicts) to
tell OBR not to try to
install and start (because this ist fileinstalls job in my
scenario)
The current documentation is sparse, but probably sufficient:
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
You could just call resolver.resolve() and then get its list
of bundles and make copies of them...of course, this isn't
truly equivalent to doing resolver.deploy(), since deploy()
tries to be smart. Another approach is to record the current
set of installed bundles, then do resolver.resolve() +
resolver.deploy(), then compare the resulting set of bundles.
Any changes can be manually downloaded from the OBR repo to
your local directory.
-> richard
It would be nice if you have some hints for me.
regards
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
