Hi Roland,
On 06/06/2015 12:48 PM, Roland Tepp wrote:
To my experience, the biggest difference between OBR (or P2) and Maven is
that with Maven repositories, you declare explicit dependencies between
modules/artifacts whereas in OBR you only declare what your module needs
(packages and their ver
To my experience, the biggest difference between OBR (or P2) and Maven is
that with Maven repositories, you declare explicit dependencies between
modules/artifacts whereas in OBR you only declare what your module needs
(packages and their version ranges) in order to function, without
explicitly req
On Thursday, 4 June 2015 at 20:10, Simon Kitching wrote:
> Hi,
>
> Yes, being able to derive at least some of the dependencies by
> introspecting the code, and then finding bundles that provide those
> packages via the repo-index is one of the advantages over OBR; it
> reduces the work of a
Maven does not provide anything like the metadata provided by OBR, which boils
down to the requirements and capabilities of every artefact.
As you acknowledge, maven dependency information is frequently wrong,
especially in the runtime scope. This is because it is written manually and
based o
Hi,
Yes, being able to derive at least some of the dependencies by
introspecting the code, and then finding bundles that provide those
packages via the repo-index is one of the advantages over OBR; it
reduces the work of adding such dependencies to the pom manually.
However that's not a _huge
Hi,
A maven pom declares dependencies on a set of artifacts with different
scopes. Maven's dependencies are a pretty generic model, and scopes
include "compile", "provided", "test" and "runtime".
The "runtime" scope is used for example by the exec-maven-plugin which will:
* download all the n
Hi Simon,
Maven is build time, OBR is runtime.
You can also take a look on:
- Karaf and features
- Karaf Cave OBR
Regards
JB
On 06/04/2015 08:27 PM, Simon Kitching wrote:
Hi All,
Can anyone provide me with a link to a comparison of OBR and Maven? I
can find reasonable amounts of information
On Thu, Jun 4, 2015 at 2:32 PM, Raymond Auge
wrote:
> the major difference is that maven cannot tell you what you need based on
> only packages you import. you have to know ahead of time.
>
> bundle aware repositories like OBR or R5 can tell you which bundles you
> need
>
rather, a resolver can
the major difference is that maven cannot tell you what you need based on
only packages you import. you have to know ahead of time.
bundle aware repositories like OBR or R5 can tell you which bundles you need
- Ray
On Thu, Jun 4, 2015 at 2:27 PM, Simon Kitching wrote:
> Hi All,
>
> Can anyone
Well, that’s unfortunate!
I have declared the platform like this (for the example of MacOS):
vtk/libCosmo.jnilib;
[…]
vtk/libvtkzlib.jnilib;
osname=MacOSX;
processor=x86_64, *
But when I deploy the bundle, it loads the Linux 32 bits one (I guess the first
one in the list)…
Welcome to Apache
Sorry I meant osgi.native in the previous message... osgi.ee is another
capability entirely :-)
Both of these will be provided by the framework, i.e. by the system bundle.
On Mon, Mar 31, 2014 at 4:56 PM, Neil Bartlett wrote:
> Okay so here's the thing... if you run this on any pre-R6 framewor
Okay so here's the thing... if you run this on any pre-R6 framework, then
nothing provides this capability. And since R6 is not released, that means
all of them.
But you shouldn't have to explicitly require the osgi.ee capability. Even
on R5 and earlier, the Bundle-NativeCode header creates an imp
I ran the "inspect capability osgi.native" that confirmed no bundle provides it.
Is this a standard OSGi capability or do I have to implement a specific bundle
to provide it?
Kind regards,
Ben
Le 31 mars 2014 à 11:38, Benoît Thiébault a écrit :
> Hi again,
>
> What bundle provides the osgi.n
Hi again,
What bundle provides the osgi.native capability? When running Felix, I have the
following error:
g! org.osgi.framework.BundleException: Unresolved constraint in bundle
org-myapp [42]: Unable to resolve 42.0: missing requirement [42.0]
org.myapp.native; (library=vtk) [caused by: Unabl
Indeed :-)
Here is the correct line:
osgi.native;
filter:="(&(osgi.native.osname=MacOS)(os.native.processor=x86_64))"
Thanks
Le 31 mars 2014 à 11:22, Neil Bartlett a écrit :
> Aha. I wasn't aware you were using the bundle plugin. The XML format
> requires you to escape certain characters wit
Aha. I wasn't aware you were using the bundle plugin. The XML format
requires you to escape certain characters within the filter, for example
"<" should be < and "&" should be & and so on.
On Mon, Mar 31, 2014 at 10:18 AM, Benoît Thiébault wrote:
> OK, I’m back at work and I have been trying you
I also tried with Maven Bundle Plugin 2.4.0 and have the same issue
Kind regards,
Ben
Le 31 mars 2014 à 11:18, Benoît Thiébault a écrit :
> OK, I’m back at work and I have been trying your snippet.
>
> I have a compilation problems… It seems Maven Bundle Plugin has difficulties
> parsing the f
OK, I’m back at work and I have been trying your snippet.
I have a compilation problems… It seems Maven Bundle Plugin has difficulties
parsing the filter.
Here is the error message:
> mvn clean install -DskipTests=true
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project ->
You cannot do this with OBR. If you can use the R5 repository format, along
with the repoindex tool, then you can use Provide- and Require-Capability
headers to ensure the set of libraries you need is resolved. For example
the fragment "org.example.nativelib.osx64" would provide something custom
li
On 29/03/14 10:35, Beno�t Thi�bault wrote:
Hi and thanks for your answer.
Putting everything in one bundle doesn't sound very modular... I would like
each deployment to include only what is necessary for it to work... Isn't it
possible?
How is it not modular?
I'd say it's very modular bec
Hi and thanks for your answer.
Putting everything in one bundle doesn't sound very modular... I would like
each deployment to include only what is necessary for it to work... Isn't it
possible?
Le 29 mars 2014 10:27, Ferry Huberts a écrit :
>
>
>
> On 29/03/14 08:47, Benoît Thiébault wrote:
>
On 29/03/14 08:47, Benoît Thiébault wrote:
Hi everyone,
I’m willing to simplify my application deployment and plan to use an OBR. On
this OBR, I have deployed several bundles, including some containing native
code.
I have a cross-platform bundle, say org.example.nativelib and one fragment f
I would guess so, since I'm not aware of any "host" attribute...perhaps
symbolicname...check in your repository.
-> richard
On 8/23/13 10:01 , Roland wrote:
First, I also thought that it would work that way, but after several tries it
still did not. Is the filter string incorrect?
--
View t
First, I also thought that it would work that way, but after several tries it
still did not. Is the filter string incorrect?
--
View this message in context:
http://apache-felix.18485.x6.nabble.com/OBR-discover-resources-which-have-a-particular-host-tp5004680p5004688.html
Sent from the Apache F
It appears that RepositoryAdmin.discoverResources(filterStr) pretty much
does the same thing as your code below, no?
public synchronized Resource[] discoverResources(String filterExpr) throws
InvalidSyntaxException
{
initialize();
Filter filter = filterExpr != null ? m_
I can show you my workaround to illustrate what I mean:
...
repository = repoAdmin.addRepository(obrfile.toURI().toURL());
resources = repository.getResources();
for(Resource resource : resources) {
Capability[] capabilities = resource.getCapabilities();
for
On 8/23/13 08:45 , Richard S. Hall wrote:
On 8/23/13 05:14 , Roland wrote:
Hello OSGi-experts,
Is it possible to discover those resources who have a particular host?
for example...
String filter = "(host=my.host)";
repoAdmin.discoverResources(filter);
I would guess no, since discovery is inte
On 8/23/13 05:14 , Roland wrote:
Hello OSGi-experts,
Is it possible to discover those resources who have a particular host?
for example...
String filter = "(host=my.host)";
repoAdmin.discoverResources(filter);
I would guess no, since discovery is intended to query against
capabilities, not re
: Richard S. Hall
Para: users@felix.apache.org
Enviado: martes, 29 de mayo de 2012 0:02
Asunto: Re: OBR RepositoryAdmin content in embeded framework
On 5/28/12 21:03 , Matias SM wrote:
Hi again Richard,
I've been investigating further and I realized my confusion
came because it seems that, whil
Enviado: martes, 29 de mayo de 2012 0:02
Asunto: Re: OBR RepositoryAdmin content in embeded framework
On 5/28/12 21:03 , Matias SM wrote:
Hi again Richard,
I've been investigating further and I realized my confusion came
because it seems that, while OBR takes into account the
installed &qu
Asunto: Re: OBR RepositoryAdmin content in embeded framework
On 5/28/12 21:03 , Matias SM wrote:
Hi again Richard,
I've been investigating further and I realized my confusion came
because it seems that, while OBR takes into account the installed
"by hand" bundles to resolve a
On 5/29/12 18:31 , Matias SM wrote:
On 29/05/12 13:58, Richard S. Hall wrote:
On 5/29/12 12:49 , matias san martin wrote:
De: Richard S. Hall
Para: users@felix.apache.org
Enviado: martes, 29 de mayo de 2012 0:02
Asunto: Re: OBR RepositoryAdmin content in
On 29/05/12 13:58, Richard S. Hall wrote:
On 5/29/12 12:49 , matias san martin wrote:
De: Richard S. Hall
Para: users@felix.apache.org
Enviado: martes, 29 de mayo de 2012 0:02
Asunto: Re: OBR RepositoryAdmin content in embeded framework
On 5/28/12 21:03
On 5/29/12 12:49 , matias san martin wrote:
De: Richard S. Hall
Para: users@felix.apache.org
Enviado: martes, 29 de mayo de 2012 0:02
Asunto: Re: OBR RepositoryAdmin content in embeded framework
On 5/28/12 21:03 , Matias SM wrote:
Hi again Richard,
I've
>
> De: Richard S. Hall
>Para: users@felix.apache.org
>Enviado: martes, 29 de mayo de 2012 0:02
>Asunto: Re: OBR RepositoryAdmin content in embeded framework
>
>On 5/28/12 21:03 , Matias SM wrote:
>> Hi again Richard,
>> I&#x
n advance for your help
Kind regards
On 28/05/12 13:59, matias san martin wrote:
Pretty much, but now I know it should be the same behavior, I will
investigate further and let you know.
Thank you for your response
Kind regards
De: Richard S. Hall
Para: users@fe
response
Kind regards
De: Richard S. Hall
Para: users@felix.apache.org
Enviado: lunes, 28 de mayo de 2012 13:29
Asunto: Re: OBR RepositoryAdmin content in embeded framework
I don't believe there should be any difference. Gogo doesn't do anything special. OB
Pretty much, but now I know it should be the same behavior, I will investigate
further and let you know.
Thank you for your response
Kind regards
>
> De: Richard S. Hall
>Para: users@felix.apache.org
>Enviado: lunes, 28 de mayo de 2012 13:29
>
I don't believe there should be any difference. Gogo doesn't do anything
special. OBR simply creates a "repository" for locally installed
bundles. Are you sure you are invoking OBR the same in both situations?
-> richard
On 5/25/12 20:06 , Matias SM wrote:
Hi everybody,
I'm wondering about a
I will, thank you
On 05/04/12 16:12, Richard S. Hall wrote:
Ok, great...watch the issue for any updates...
-> richard
On 4/5/12 15:01 , Matias SM wrote:
I just created it:
Key: FELIX-3446
URL:https://issues.apache.org/jira/browse/FELIX-3446
HTH, Kind Regards
On 05/04/12 15:15, Richard S.
Ok, great...watch the issue for any updates...
-> richard
On 4/5/12 15:01 , Matias SM wrote:
I just created it:
Key: FELIX-3446
URL:https://issues.apache.org/jira/browse/FELIX-3446
HTH, Kind Regards
On 05/04/12 15:15, Richard S. Hall wrote:
Yes, please open a JIRA issue with the example bun
I just created it:
Key: FELIX-3446
URL:https://issues.apache.org/jira/browse/FELIX-3446
HTH, Kind Regards
On 05/04/12 15:15, Richard S. Hall wrote:
Yes, please open a JIRA issue with the example bundles and a
repository.xml file that I can play with.
Thanks.
-> richard
On 4/5/12 12:53 , M
Yes, please open a JIRA issue with the example bundles and a
repository.xml file that I can play with.
Thanks.
-> richard
On 4/5/12 12:53 , Matias SM wrote:
Hi Richard,
I've given this issue some more thought and I realized that my
starting point stands (a copy of the original mail is at the
Hi Richard,
I've given this issue some more thought and I realized that my starting
point stands (a copy of the original mail is at the end of this one).
If I try to execute these steps:
g! deploy -s DA
g! deploy -s A@1.0.0.1
g! refresh
g! deploy -s DexA
The deployment of DexA fails. If I unde
Ok, thank you very much for your comments Richard.
I will keep them in mind and do further experimentation.
On 02/04/12 21:25, Richard S. Hall wrote:
The location string is a deployer assigned persistent identifier, so it cannot
change. Your confusion arises because frameworks use the URL as th
The location string is a deployer assigned persistent identifier, so it cannot
change. Your confusion arises because frameworks use the URL as the default
location string for simple installs, but the two are unrelated in reality.
Matias SM wrote:
>Ok, I see. Shouldn't the location string be re
Ok, I see. Shouldn't the location string be replaced (with the updated
version location) when the bundle is updated? It seems a little confusing.
Thank you very much for the clarification, I will do some more
experimentation keeping in mind what we discussed.
On 02/04/12 19:25, Richard S. Hal
Yes, you are using the same path when you try to install the first bundle the
second time and this will not work since that path is used as a unique key,
which is why it returns the same bundle id as printed in your session since it
did not install anything the second time.
As I suggest you nee
On 02/04/12 18:32, Richard S. Hall wrote:
On 4/2/12 17:05, Matias SM wrote:
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM w
On 4/2/12 17:05, Matias SM wrote:
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everyth
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm faci
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm facing a situation I don't know how to
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm facing a situation I don't know how to
solve.
---
Here is my test scenario:
I have the following bundles in an
El 13/03/12 00:19, Richard S. Hall escribió:
On 3/11/12 12:27 , matias san martin wrote:
Hi Richard,
I want to thank you again for taking the time to analyze my problem.
I attach a .zip file with the following content:
1- Repositories/
2- test.osgi.obr.resolver.main/
3- org.osgi.service.obr-1.
an be satisfied, which is correct.
-> richard
[1] http://felix.apache.org/site/downloads.cgi
- Mensaje original -
De: Richard S. Hall
Para: users@felix.apache.org
CC:
Enviado: sábado, 10 de marzo de 2012 20:32
Asunto: Re: OBR resolver knows about a requirement of a missing re
Execution Environment (|(ee=JavaSE-1.6))
De: Richard S. Hall
Para: users@felix.apache.org
Enviado: sábado, 10 de marzo de 2012 2:02
Asunto: Re: OBR resolver knows about a requiremen
Execution Environment (|(ee=JavaSE-1.6))
>
> De: Richard S. Hall
>Para: users@felix.apache.org
>Enviado: sábado, 10 de marzo de 2012 2:02
>Asunto: Re: OBR resolve
Perhaps you are printing the messages in the wrong spot while recursing...just
a thought. Otherwise, it might be necessary to see your repository.xml file.
"San Martín, Matías" wrote:
>Hi everybody,
>first of all sorry about the odd mail subject, I will try to explain
>myself better.
>
>The
ose to what you want to do?
v/r,
Mike Van
- Original Message -
From: "john dunlap"
To: users@felix.apache.org
Sent: Friday, December 3, 2010 4:36:19 PM
Subject: Re: OBR search and installation
That's very very close to what I want. The only thing that is missing
i
*hits self* If only the docs explained it like that...
Quoting Karl Pauls :
The repository is just an xml file that must be accessible via a url.
So all you have to do is to have your ide move the bundle plus the
repository to a server some place and point obr to that. You can
configure the mav
The repository is just an xml file that must be accessible via a url.
So all you have to do is to have your ide move the bundle plus the
repository to a server some place and point obr to that. You can
configure the maven-bundle-plugin to publish the repository.xml and
the bundle to a remote maven
That's very very close to what I want. The only thing that is missing
is that I want my IDE, the repository, and the OSGI server to be
running on separate physical machines.
Quoting john.dun...@exceter.com:
Is an OBR repository a new concept or is it just difficult to implement?
Quoting Gu
Is an OBR repository a new concept or is it just difficult to implement?
Quoting Guillaume Nodet :
The real problem is that there's no real usable obr repository, so
you're really on your own here. However obr use a url to actually
dowload and install the bundles that you can point to a known
Hi John,
I'm not sure I understand you correctly but if all you want to do is
to have your bundles be available via obr and use obr to deploy a
bundle together with the transitive closure over its dependencies you
first need to create your repository from your available bundles. You
could use bind
:(
Quoting Guillaume Nodet :
The real problem is that there's no real usable obr repository, so
you're really on your own here. However obr use a url to actually
dowload and install the bundles that you can point to a known location
if you manage thoses repositories. What we're using in Karaf
The real problem is that there's no real usable obr repository, so
you're really on your own here. However obr use a url to actually
dowload and install the bundles that you can point to a known location
if you manage thoses repositories. What we're using in Karaf to
remove this absolute url is t
Sure, though you might have to explain how to use the snapshot.
Original-Nachricht
> Datum: Fri, 09 Apr 2010 11:35:57 -0400
> Von: "Richard S. Hall"
> An: users@felix.apache.org
> Betreff: Re: OBR-deploy-proxy-maven repo-issue
> p.s. If I create a s
Thanks for the help.
Yes, I will do that ASAP.
Original-Nachricht
> Datum: Fri, 09 Apr 2010 11:29:21 -0400
> Von: "Richard S. Hall"
> An: users@felix.apache.org
> Betreff: Re: OBR-deploy-proxy-maven repo-issue
> As far as I can tell, this looks like a
p.s. If I create a snapshot of OBR with a fix, will you test it for me?
On 4/9/10 11:29, Richard S. Hall wrote:
As far as I can tell, this looks like a bug in OBR...it sets the
authentication for reading the repo, but not for retrieving the
artifacts. Could you open a JIRA issue for this
(http
As far as I can tell, this looks like a bug in OBR...it sets the
authentication for reading the repo, but not for retrieving the
artifacts. Could you open a JIRA issue for this
(https://issues.apache.org/jira/browse/FELIX)? Thanks!
-> richard
On 4/9/10 11:15, Stephan-Frank Henry wrote:
Hello
It should be fixed now. You need to rebuild the obr repository to avoid the
use of absolute uris.
On Tue, Mar 23, 2010 at 11:22, Guillaume Nodet wrote:
> Ok, i'll investigate that asap. This is certainly a regression caused by
> one of the big refactoring i've done recently.
>
>
> On Tue, Mar
Ok, i'll investigate that asap. This is certainly a regression caused by
one of the big refactoring i've done recently.
On Tue, Mar 23, 2010 at 11:17, Reto Bachmann-Gmuer <
reto.bachm...@trialox.org> wrote:
> Hello
>
> We're using the maven-bundle-plugin to have a repository.xml on our maven
> r
Thanks Richard, I'll add a feature request to JIRA.
Regards,
Nick
-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: 05 March 2010 13:43
To: users@felix.apache.org
Subject: Re: OBR refresh problem
On 3/5/10 6:05, Nick Wilson wrote:
> I'm looking
On 3/5/10 6:05, Nick Wilson wrote:
I'm looking at using OBR for deploying bundles to one of our products.
I've written our own OBR server and I'm using the Felix OBR code to
connect to it. The problem I'm having is that if I upload a new bundle
to the OBR server then RepositoryAdmin will not find
On 1/28/10 5:10, Stéphane Jeanjean wrote:
Hi Richard,
Thank you very much. Now it's ok with http.proxyAuth that contains
login:password.
May be, I can open an issue for the use of http.proxyUser and
http.proxyPassword if you think the project has to keep a trace of that.
Even better, contrib
Hi Richard,
Thank you very much. Now it's ok with http.proxyAuth that contains
login:password.
May be, I can open an issue for the use of http.proxyUser and
http.proxyPassword if you think the project has to keep a trace of that.
Stéphane
Richard S. Hall a écrit :
On 1/27/10 13:01, Stéphane
On 1/27/10 13:23, Stéphane Jeanjean wrote:
Ok, so it seems that I have to use http.proxyAuth instead of
http.proxyUser and http.proxyPassword.
So http.proxyAuth has to contain login:password
Is http.proxyAuth usual variable ?
Why not using http.proxyUser and http.proxyPassword which are standar
Ok, so it seems that I have to use http.proxyAuth instead of
http.proxyUser and http.proxyPassword.
So http.proxyAuth has to contain login:password
Is http.proxyAuth usual variable ?
Why not using http.proxyUser and http.proxyPassword which are standard
variables ?
Thanks !
Stéphane
Richard
On 1/27/10 13:01, Stéphane Jeanjean wrote:
I don't think this is the same issue. FELIX-651 is about an
authentication against the repository server. My issue is about an
authentication against the http proxy between the OSGi platform and
the repository server.
Ok, my bad.
When I use OBR th
I don't think this is the same issue. FELIX-651 is about an
authentication against the repository server. My issue is about an
authentication against the http proxy between the OSGi platform and the
repository server.
When I use OBR through a proxy without authentication, it's ok. So it
see
I believe the following issue discusses this area:
https://issues.apache.org/jira/browse/FELIX-651
We need someone to follow up on the issues raised by Felix Meschberger.
-> richard
On 1/27/10 12:29, Stéphane Jeanjean wrote:
Hi,
My platform tries to access to an OBR repository through a
Hello Teemu,
On Jan 7, 2010, at 0:00 , teemu kanstren wrote:
> I need to create some automated update mechanism for my OSGi services. The
> Felix OSGI Bundle Repository (OBR) service seems to provide some useful
> features that I could use to make my updates happen.
Take a look at Apache ACE, wh
Hi again,
After investigation, it seems the problem is due to a
NullPointerException in bundlerepository.
I therefore created JIRA issue FELIX-1809; please review and comment.
Best regards,
Arjun
Le 10/23/2009 06:57 PM, Arjun Panday a écrit :
Hello everyone,
Can someone please help me with
Richard,
you are totally right. I had my custom obr and the apache felix obr
configured. The resolver seemed to resolve the obr bundle as a depency
of one of my bundles. I removed the felix obr from my config and now it
works.
Thanks,
Henrik
Richard S. Hall schrieb:
> It sounds like OBR is someh
It sounds like OBR is somehow getting updated too.
-> richard
On 10/18/09 11:37, Henrik Niehaus wrote:
Hi *,
I'm struggling with an obr problem. I always get an
java.lang.IllegalStateException: Invalid BundleContext when I call
Resolver.deploy the first time.
The start situation looks like th
On Thu, Oct 8, 2009 at 10:34 AM, 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 ju
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
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
th
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 actua
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) patc
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 interest
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 int
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
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
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?
-> r
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
I
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 solut
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 d
On Mon, Oct 5, 2009 at 10:03 PM, Richard S. Hall 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 us
1 - 100 of 203 matches
Mail list logo
