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/[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]
