Re: Problem updating to 4.2.7

he features XML with a zip of your resources > repository. > > A simple test should be enough. > > Thanks a lot ! > > Regards > JB > > On 29/10/2019 11:13, David Leangen wrote: >> Hi JB, >> >> Sure! What would be the best way of doing that? >>

Re: Problem updating to 4.2.7

ote: > > Hi David, > > do you think you can have a simple test case you can send to me ? > > It would help to identify the issues between 4.2.0 and 4.2.1. > > Thanks, > Regards > JB > > On 29/10/2019 09:29, David Leangen wrote: >> >> 4.2.1 w

Re: Problem updating to 4.2.7

to figure out why 4.2.7 won’t start up… Cheers, =David > On Oct 29, 2019, at 17:15, David Leangen wrote: > > > Hi, > > FYI it looks like 4.2.0 worked. I am having trouble with resolution of my > bundles now, but at least the problem I was seeing in 4.2.7 is not there. >

Re: Problem updating to 4.2.7

Hi, FYI it looks like 4.2.0 worked. I am having trouble with resolution of my bundles now, but at least the problem I was seeing in 4.2.7 is not there. I will give it a try with 4.2.1 next. Cheers, =David > On Oct 28, 2019, at 20:14, David Leangen wrote: > > > The owner

Re: Problem updating to 4.2.7

? > > Regards > JB > > On 28/10/2019 08:11, David Leangen wrote: >> >> You amaze me! How are you so fast? >> >> Anyway… >> >> Again you’ll have to excuse my ignorance, but… >> >> [root@deimos features]# pwd >> /home/karaf/fea

Re: Problem updating to 4.2.7

Hi, Excuse my ignorance… But given this feature file: >name="enRoute Distribution Features" > xmlns="http://karaf.apache.org/xmlns/features/v1.4.0 > "> > > >

Re: Problem updating to 4.2.7

te to ping me when you can, we will figure it out together. > > Regards > JB > > On 26/10/2019 08:19, David Leangen wrote: >> >> Hi JB, >> >> Thank you for your amazingly fast reply! >> >> Ok, I will try these out, but unfortunate

Re: Problem updating to 4.2.7

Hi JB, Thank you for your amazingly fast reply! Ok, I will try these out, but unfortunately it won’t be today. I’ll let you know. Cheers, =David > On Oct 26, 2019, at 15:10, Jean-Baptiste Onofré wrote: > > Hi David, > > Does Karaf stop or restart ? > > About what you said, it seems to

Problem updating to 4.2.7

Hi! I am trying to update my Karaf to 4.2.7. I was using a snapshot of 4.2.0. Using the default configuration, the container starts up just fine. However, when I attempt to deploy a feature (by placing the file in the deploy directory), the container dies, and then goes into a bad cycle where

Re: Resolving a type from a wrapped jar file

Thanks for this info. Could you please explain more what you mean by: > uses bundle-classpath Is this something different from Conditional-Package? Cheers, =David > On Sep 10, 2018, at 6:31, David Jencks wrote: > > IANAL and I really can’t understand the GPLv3. > > rebundling or

Re: Strange resolution problem

> On Oct 10, 2017, at 3:31 PM, Guillaume Nodet wrote: > > Given it happens at runtime, then it means the import is already in your > net.leangen.expedition.platform.ddd.diag bundle, so it's just the consequence > of a problem happening at build time. Thanks Guillaume et

Re: Strange resolution problem

> On Oct 9, 2017, at 4:23 PM, Achim Nierbeck wrote: > On Oct 9, 2017, at 4:28 PM, Guillaume Nodet wrote: Thanks for the suggestions. You are no doubt right, so I quadruple checked my code, and bumped all versions. Ran the build locally, and

Strange resolution problem

Hi! I am stumped. I am having a resolution issue in Karaf as follows: org.osgi.framework.BundleException: Unable to resolve net.leangen.expedition.platform.ddd.diag [101](R 101.0): missing requirement [net.leangen.expedition.platform.ddd.diag [101](R 101.0)] osgi.wiring.package;

Re: NCDFE org/apache/aries/jmx/codec/BundleEventData

Hi! This only seems to happen if multiple files are placed in the “deploy” directory at about the same time. If I notice the problem again, I will file an issue. Cheers, =David > On Jul 19, 2017, at 7:38 AM, David Leangen <apa...@leangen.net> wrote: > > > Hi! >

NCDFE org/apache/aries/jmx/codec/BundleEventData

Hi! Upon startup, I am seeing this: > 2017-07-18T22:33:31,491 | ERROR | FelixDispatchQueue | Felix > | - - | Bundle org.apache.aries.jmx.core [16] EventDispatcher: > Error during dispatch. (java.lang.NoClassDefFoundError: >

Re: Problem using drop-in deploy feature

Thanks, that worked, and I am up and running again. I plan to file an issue later so that http(s) URLs can also be authenticated. I am thinking an OSGi URL handler (maybe as an extension to pax-url). Cheers, =David > On Jul 4, 2017, at 9:39 PM, David Leangen <apa...@leangen.net&

Re: Problem using drop-in deploy feature

Oh, I just noticed that there is a maven cache located at /root/.m2. I did not realise that. I was looking at /home/karaf and did not see a maven repo. So that is where the settings.xml would go, I suppose… I’ll give that a try. Thanks! =David > On Jul 4, 2017, at 8:48 PM, Da

Re: Problem using drop-in deploy feature

Hi Christian, Thanks for your help. > you will need to configure the authentication in the maven settings.xml. > Either on server or mirror level. > > https://maven.apache.org/settings.html I did not see any settings.xml file. Would I create one in the Karaf etc directory? Are you saying

Re: Problem using drop-in deploy feature

then pax url maven is not involved. > I recommend to switch to mvn urls. It will take care of the download as well > as the caching in the local repo. > > If you want to get authentication working with plain http urls you should > create another issue. > > Christian >

Re: Problem using drop-in deploy feature

to be developed? —> I’m not sure if I need to create a JIRA issue or not... Thanks for your help! :-) Cheers, =David > On Jul 4, 2017, at 3:31 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Thanks, > > let me take a look. > > Regards > JB > > On 0

Re: Problem using drop-in deploy feature

g file. > > Regards > JB > > On 07/04/2017 07:28 AM, David Leangen wrote: >> Hi! >> I worked through the code and noticed that it was just a simple matter of >> the connection not handing the authentication. I will submit a patch. >> However… >> Mo

Re: Problem using drop-in deploy feature

think that is why my resolution is failing. Any advice as to how to implement authentication for my repository?? Thanks! =David > On Jul 4, 2017, at 5:08 AM, David Leangen <apa...@leangen.net> wrote: > > > Hi JB, > > I tried prefixing with “xml:”, but that

Re: Problem using drop-in deploy feature

gt; wrote: > > The resource repository has to be prefixed by json or xml in the URL. > > Let me find an example. > > Regards > JB > > On 07/03/2017 12:14 PM, David Leangen wrote: >> Hi! >> I am trying to follow Guillaume’s advice from this thread: >>

Re: Test -- My messages are not getting through, arg!

Well, my plaintext message got through… Now I know. :-) Again, sorry for the noise… Cheers, =David > On Jul 3, 2017, at 7:13 PM, David Leangen <apa...@leangen.net> wrote: > > > Sorry for the noise, but my messages have not been getting through, and I > have not recei

Re: Test -- My messages are not getting through, arg!

Sorry for the noise, but my messages have not been getting through, and I have not received any error message. Is there something that would impede a message being send? Cheers, =David > On Jul 3, 2017, at 7:10 PM, David Leangen <apa...@leangen.net> wrote: > > > Test test test

Test -- My messages are not getting through, arg!

Test test test

Re: Karaf Feature vs. OBR

>>>>> David Leangen <apa...@leangen.net <mailto:apa...@leangen.net>>: > My current issue is: how can I use Features for Continuous Deployment? > I am having trouble with automation. That is what got me interested in > the idea behind the Features… > On Jun

Re: Karaf Feature vs. OBR

Hi Steiner, Thanks for this information. > On Jun 16, 2017, at 3:53 AM, Steinar Bang wrote: > > It doesn't involve features, except for the installation, but I do this: > 1. Use maven to build the bundles (and the features) > 2. Use a -SNAPSHOT version I’ll look into this

Re: Karaf Feature vs. OBR

Hi Christian, >> I don’t know. I think I rather like the idea of the curated repositories >> that I know won’t shift over time. > You need both. During active development you want to use the newest > dependency .. at least for your own artifacts .. sometimes also for remote > ones. Then once

Re: Karaf Feature vs. OBR

Hi Guillaume, Ok, that gives me a lot to chew on for now. I’ll give it a good try before I make any more speculative comments. :-) Cheers, =David > On Jun 15, 2017, at 5:23 PM, Guillaume Nodet <gno...@apache.org> wrote: > > > > 2017-06-15 9:00 GMT+02:00 David Leange

Re: Karaf Feature vs. OBR

on in a different form and is > usually generated from the manifest. Fwiw, when a feature has a reference to > a bundle, we do generate the OSGi Resource from the manifest directly without > using the OBR xml description, but it's the same. > > I'm really not sure what we could

Re: Karaf Feature vs. OBR

ould do > the same. So a feature could simply point to a pom or when deployed to maven > we could assume to use the pom of the project the feature resides in as > default. This would allow to simply define OBRs by using a pom. > > Christian > > > 2017-06-14 23:58 GMT+0

Re: Karaf Feature vs. OBR

nexus. “At the bottom of this hole, a cave… :-) =David > On Jun 15, 2017, at 4:47 AM, David Leangen <apa...@leangen.net> wrote: > > > Thank you JB and Christian, > > I think that about answers my question. Right now I don’t have time to > actually invest in doing

Re: Karaf Feature vs. OBR

; environments. It is just matter of knowledge and effort to implement this. >> You can see in the CXF-DOSGi SOAP sample what can already be done with OBR >> and a resolver: >> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun#L1-L41 >> The runbundle

Karaf Feature vs. OBR

Hi! I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping. An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for

Re: JAX-RS Annotations and Apache Karaf 4.0.5

Very rudimentary, but I list the 5 implementations suggested so far along with their “dependencies”. I don’t know if it is the entire list (i.e. includes transitive dependencies as well) and if there are optional ones or not. It’s a start. 1. Amdatu Web:

Re: JAX-RS Annotations and Apache Karaf 4.0.5

gt; > 2016-07-02 13:53 GMT+02:00 James Carman <ja...@carmanconsulting.com > <mailto:ja...@carmanconsulting.com>>: > > > On Sat, Jul 2, 2016 at 4:13 AM David Leangen <apa...@leangen.net > <mailto:apa...@leangen.net>> wrote: > > > Question: is there a more light

Re: JAX-RS Annotations and Apache Karaf 4.0.5

Very interesting. Thank you for this. > [1] https://wiki.eclipse.org/Distribution_Providers > [2] https://wiki.eclipse.org/EIG:Remote_Services_Admin > [3] > https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service > [4] https://github.com/ECF/JaxRSProviders > [5]

Re: Replacing SCR at startup

andard/4.0.4/standard-4.0.4-features.xml > > Regards > JB > > On 05/06/2016 08:01 AM, David Leangen wrote: >> >> Hi! >> >> I have a patched version of SCR I would like to use in my Karaf container. >> It is only for testing purposes, but it must

Replacing SCR at startup

Hi! I have a patched version of SCR I would like to use in my Karaf container. It is only for testing purposes, but it must be present at startup, in place of the usual SCR bundle. What is the easiest way to accomplish this? Thanks so much! =David

Re: Bundle startup

test project I could look > at? > > thanks > david jencks > >> On May 4, 2016, at 7:10 PM, David Leangen <apa...@leangen.net >> <mailto:apa...@leangen.net>> wrote: >> >> >> Hi, >> >> Thank you. >> &g

Re: Bundle startup

t >> through remote debugging with your IDE. >> >> You will see if the bundle starts or not (using your filter) >> >> Hope it helps a bit :) >> >> Regards, >> Morgan >> >> 2016-05-04 12:07 GMT+02:00 David Leangen <ap

Re: Bundle startup

Thanks, Morgan, that worked. :-) The output is very long, and I’m not sure what to look for, but here it is… Perhaps this is the relevant line (though I don’t know what it means…): Component can not be activated since it is in state 64 Cheers, =David karaf.log.1:2016-05-04 05:53:23,480 |

Re: Bundle startup

g the way you expect. > > david jencks > >> On May 3, 2016, at 11:08 PM, David Leangen <apa...@leangen.net> wrote: >> >> >> Hi David, >> >> Here are the xmls for the 3 components in the bundle: >> >> >> http://www.osgi.o

Re: Bundle startup

Salut JB, Unfortunately, it is not optional, though. :-) The OAuthUserAdmin simply won’t work without a “normal” UserAdmin present, as it wraps the UA and delegates to it. Cheers, =David > On May 4, 2016, at 3:00 PM, Jean-Baptiste Onofré wrote: > > UserAdmin reference

Re: Bundle startup

Hi David, Here are the xmls for the 3 components in the bundle: http://www.osgi.org/xmlns/scr/v1.3.0; name="net.leangen.expedition.integration.oauth2.credentials" activate="activate"> (I just added in the target filter. I could easily remove it again.)

Re: Bundle startup

Salut JB, Unfortunately, it is not optional, though. :-) The OAuthUserAdmin simply won’t work without a “normal” UserAdmin present, as it wraps the UA and delegates to it. Cheers, =David > On May 4, 2016, at 3:00 PM, Jean-Baptiste Onofré wrote: > > UserAdmin reference

Re: Bundle startup

Hi Christian, Here is an edited excerpt of the generated manifest: Export-Package: mypackage.oauth2;version="0.2.0”, org.osgi.service.useradmin;version="1.1";uses:="org.osgi.framework" Import-Package: javax.net,javax.net.ssl,javax.security.auth.x500,

Re: Bundle startup

Thanks for the tips. This is what I found: FrameworkEvent ERROR - net.leangen.expedition.platform.web.provider org.osgi.framework.ServiceException: ServiceFactory.getService() resulted in a cycle. Unfortunately, this doesn’t really tell me much. I think this may be related to the fact that

Re: Bundle startup

Hi, David, > There must be a lot more going on for this to fail. This kind of situation > normally works fine with scr. If you turn up ds logging, what do you see as > the reason your component won’t start? What does the console say about the > state of the component (assuming the console

Bundle startup

Hi! When I start up Karaf, all my bundles are activated, but a component service is one bundle is not enabled. The service does not start because it is not provided with a UserAdmin. Judging by the ordering, this is surely true when the system starts. When I log into the console (after all

Re: Missing java.util.concurrent.Executor

Never mind. :-) Turns out to be a missing requirement, which I was able to locate. Cheers, =David > On Feb 27, 2016, at 5:28 PM, David Leangen <apa...@leangen.net> wrote: > > > Hi! > > For some reason, java.util.concurrent.Executor does not seem to be in my &

Missing java.util.concurrent.Executor

Hi! For some reason, java.util.concurrent.Executor does not seem to be in my Karaf runtime (scr:info below). Any idea why, and how I can fix the problem? Thanks! =David > Component Description: > Name: osgi.enroute.simple.server > Default State: enabled > Activation: immediate >

Re: Bndtools & Karaf : the right way

> You are correct a plain feature generation out of the resolved bundles would > create this result. > > One way to make it easier is if we provide an index for all or at least the > basic karaf features per karaf version. You could then add this index to you > bndtools workspace and have a >

Re: Bndtools & Karaf : the right way

Hi, >> By the way, bndtools does have a concept of a deployment descriptor >> (bndrun). All it is, really, is just an index of the resolved bundles, i.e. >> the bundles that are available in the workspace, and are therefore available >> to the runtime. The list is simply the output of the

Re: Bndtools & Karaf : the right way

> My understanding is that, as I explained in my earlier mail, you don't need > features at all. > If you have an "application bundle" and the xml repository, that should be > enough, you don't have to wrap them. > > Could you please raise a JIRA and attach the artefacts needed to "reproduce"

Re: Bndtools & Karaf : the right way

Hi Guillaume, Thank you very much for looking into this so quickly! > So i've just experimented a bit with this repository. > I've added the following repository to karaf which could easily be generated. > > http://karaf.apache.org/xmlns/features/v1.4.0 >

Re: Bndtools & Karaf : the right way

>> Try with feature:requirement-add >> ‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle' > > Still trying. I must be doing something wrong… :-( I don’t know if my expectations are correct or not, but I was expecting that requirement-add would also pull in all the declared

Re: Bndtools & Karaf : the right way

Hi, >>> What could be done is a command that would create the features >>> repository, given the resource xml repository generated by bnd. It's >>> just about parsing the repository, finding the "application" bundles, >>> and create the above blob of xml. Nothing very difficult from a >>>

Re: Bndtools & Karaf : the right way

>> Since maven is so widely adopted, it would be foolish to ignore. That is not >> what I am suggesting. However, I think it would not be wise to force Karaf >> users into the maven world, either. > You are right. For OSGi we need a repository with support for OSGi metadata. > Only then can we

Re: Bndtools & Karaf : the right way

> I think something that might work is: > > feature:install [;] That sounds very nice. > We could support this syntax alternatively to a simple feature name. > > Do you think we need a special way to track the installed application/feature > bundles? Or is it good enough that they are

Re: Bndtools & Karaf : the right way

Hi, Wow! This list is really active. :-D I think Christian explains it quite well. Allow me to add in more concrete, low-level details to complement this explanation. First of all, I have a “bootstrapping" bundle, with no dependencies on any of my other bundles, but some dependencies on, for

Re: Bndtools & Karaf : the right way

Hi, > I think the maven repository is also a really nice hand over point between > the developer and deployer roles you defined. The developer builds the > bundles as well as the > index into the maven repository and the deployer installs from there. Perhaps you could explain to me why,

Re: Bndtools & Karaf : the right way

> My understanding is that, as I explained in my earlier mail, > you don't need features at all. > If you have an "application bundle" and the xml repository, that should be > enough, you don't have to wrap them. Indeed, if it is possible to manage the bundles as a unit, like a feature does,

Re: Bndtools & Karaf : the right way

> Anyway, once I'm given a repository and a set of bundles to look at, i'm > willing to look at it. Cool! Thank you very much! I will work on that as soon as I can. :-) Cheers, =David

Re: Bndtools & Karaf : the right way

> >> There is an easy way to install bundles. > >> Just use the feature:requirement-add command. > > Sounds practical. But then again, I really like the idea of “features”. I > like to see which “feature” is installed and running. If my bundle is only > added as a requirement, then I lose that

Re: Bndtools & Karaf : the right way

Hi! >> There is an easy way to install bundles. >> Just use the feature:requirement-add command. Sounds practical. But then again, I really like the idea of “features”. I like to see which “feature” is installed and running. If my bundle is only added as a requirement, then I lose that

Re: Bndtools & Karaf : the right way

> I have written down some ideas here some time ago: > http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf > > Very nice ! > I agree we would need to also bring the

Re: Bndtools & Karaf : the right way

> Do you have pointers about those "application bundles” ? How about this? https://github.com/osgi/osgi.enroute.examples/blob/master/osgi.enroute.examples.cm.application/src/osgi/enroute/examples/cm/application/CmApplication.java

Re: Bndtools & Karaf : the right way

>> I can envision, for instance, configuration parameters on 3 levels: >> >> 1) default parameters (probably provided in the code) >> 2) default parameters for a specific installation / runtime >> 3) maintenance or operational parameters > > I have scoped such a scenario a long time ago here: >

Re: Bndtools & Karaf : the right way

Hi Christian, > In both cases a bndrun or similar is necessary. The bndrun file does not only > contain the runbundles which is the already resolved list. It also contains > the requirements. The minimum thing it would contain in your case is a > pointer to your application bundle. In many

Re: Bndtools & Karaf : the right way

get up and running quickly would be very welcome. :-) Cheers, =David On Nov 26, 2015, at 10:20 PM, Christian Schneider <ch...@die-schneider.net> wrote: > On 26.11.2015 12:54, David Leangen wrote: >> >> Hi Christian, >> >> >> >>> This pa

Re: Bndtools & Karaf : the right way

Hi, If it’s any help, I am also using bndtools in Eclipse/gradle. I am in a greenfield environment, so it is probably easier for me. Thanks to the help of the kind people in this community, I was able to get my release process working. I do this by releasing my bundles from bndtools, then

Re: Bndtools & Karaf : the right way

Hi JB and Christian, I am very interested in this discussion, as it is extremely related to my current top priority (getting a bndtools—>Karaf development+deployment workflow in place). >> We created features instead of using directly OBR as OBR doesn't cover the >> needs (features contain

Re: Bndtools & Karaf : the right way

le to "generate" the features. > > I know that Christian discussed with bndtools guys about that, and I'm also > jumping in bndtools to help. > > WDYT ? > > Regards > JB > > On 11/26/2015 01:36 AM, David Leangen wrote: >> >> Hi, >&g

Re: Populating a Cave Repository from a BND Repo

sitories > > I will take a look to improve support of index.xml in Karaf. > > Regards > JB > > On 11/20/2015 12:57 AM, David Leangen wrote: >> >> Hi! >> >> Thank you very much for all your efforts yesterday! >> >> Could you please confirm

Re: Populating a Cave Repository from a BND Repo

ed OBR > resource, I downgraded the bundlerepository version to avoid this. So, we > should not have this exception in 4.0.3. > > Let me know if the Jira. > > Regards > JB > > On 11/24/2015 06:54 AM, David Leangen wrote: >> >> Hi! >> >> Thanks again

Re: Features vs. Deployment Admin

pository.xml per artifacts (instead of a "global/big" > repository.xml). > > Regards > JB > > On 11/18/2015 11:59 PM, David Leangen wrote: >> >> Or another, maybe better way, is to figure out how to create a feature >> by designating the “application

Re: Karaf ResolveContext

lix Resolver. You can > start your resolver by extended Felix Resolver (but not sure why you need > that). > > Regards > JB > > On 11/19/2015 03:00 AM, David Leangen wrote: >> >> Hi! >> >> If I want to use a Resolver, I need a ResolveContext. I not

Re: Features vs. Deployment Admin

<http://my.repo.com/path/to/repo/index.xml> > > Guillaume > > 2015-11-19 9:41 GMT+01:00 David Leangen <apa...@leangen.net > <mailto:apa...@leangen.net>>: > > Hi JB, > > Thanks again for your help. My bundle requirements are still not getting

Re: Populating a Cave Repository from a BND Repo

gt; Hmmm, weird, the second should ;) > > Let me try ;) > > On 11/19/2015 03:34 PM, David Leangen wrote: >> >> Hi JB, >> >> At first, I did >> cave:repository-proxy foo http://path/to/repo/index.xml >> >> After that, I also tried >> c

Re: Features vs. Deployment Admin

(Bringing back on list…) Hmmm. Ok, I’ll bring this up with the bnd community, since it is the bnd plugin that creates the index. Thanks again so much for your help!!! Greatly appreciated! Cheers, =David On Nov 19, 2015, at 9:01 PM, Jean-Baptiste Onofré wrote: > It

Populating a Cave Repository from a BND Repo

Hi! Based on the recent discussion in bndtools… >>> On 19/11/15 14:33, Timothy Ward wrote: >>> The indexes generated by a LocalIndexedRepo (the type of release repository >>> that you’re talking about) will always use relative URIs to locate the >>> bundles. This is what the Local in

Features vs. Deployment Admin

Hi! Still on my quest to figure out how to deploy my apps on Karaf (without having to write features.xml files manually). I have been looking at the Resolver Spec, but that seems to be more low-level than I’d like. Looks like it is intended more for tool and framework developers. I did come

Karaf ResolveContext

Hi! If I want to use a Resolver, I need a ResolveContext. I noticed that Karaf has one, but it is private. How could I get an instance of the Karaf ResolveContext? Cheers, =David

Re: Features vs. Deployment Admin

way of deploying applications, though we > worked on features quite long > and regard it to be superior, because simplere though more effective. ESA > reminds me to much of an EAR like packaging, > but that's my 2 cents. > > regards, Achim > > > 2015-11-18 19:28

Re: Features vs. Deployment Admin

, based on the declared requirements, to pull in everything needed from the indexed repositories. Everything is there, it’s just creating the features.xml file that is my problem. :-) Cheers, =David On Nov 19, 2015, at 7:27 AM, David Leangen <apa...@leangen.net> wrote: > > Hi,

Karaf Commands - non-OSGi commands

Hi! In the javadoc for org.apache.karaf.shell.api.action.Action, I see this: * In order to make commands available from the non-OSGi shell, * the commands must be listed in a file available at * META-INF/services/org/apache/karaf/shell/commmands. Can anybody help decipher this for me? *

Re: Status of OBR

s the "replacement" of the "old" OBR specification. > > More than OBR, I would recommend to use Feature ResourcesRepository plug to > Cave. > > I'm preparing a blog post about that. > > Regards > JB > > On 11/14/2015 04:41 AM, David Leangen wrote

Re: Custom Shell

> You can also define a Karaf sub-shell. > > Regards > JB > > On 11/14/2015 10:14 AM, David Leangen wrote: >> >> Hi! >> >> Is it possible to create a custom shell environment in addition to the >> existing shell in Karaf? >> >> I woul

Status of OBR

Hi! I noticed that there is not much recent activity in Karaf-Cave. I also have a vague recollection of a recent email on the list saying that "OBR is deprecated". Is anybody able to provide a little more clarity? I was planning on using the OBR feature for provisioning. Thanks! =David

Re: Understanding cave:repository-proxy

(cave:repository-scan) ? Regards JB On 06/01/2015 09:22 AM, David Leangen wrote: Hi, Looks like it is empty: repository name='artifactory' lastmodified='20150601055301.140'/ Cheers, =David On Jun 1, 2015, at 2:52 PM, Jean-Baptiste Onofré j...@nanthrax.net mailto:j

Re: Understanding cave:repository-proxy

Hi, Looks like it is empty: repository name='artifactory' lastmodified='20150601055301.140'/ Cheers, =David On Jun 1, 2015, at 2:52 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi, What do you have in repository.xml ? Regards JB On 05/31/2015 11:00 PM, David Leangen wrote

Re: Understanding cave:repository-proxy

Hi JB, Thank you very much for your reply! you are right: repository-proxy creates the OBR metadata (repository.xml) based on an existing repository (or storage). However, check if the repo is registered in the obr url (obr:url-list). If not, you have to register the repo with obr using

Understanding cave:repository-proxy

Hi! I am using 3.0.3. My understanding is that when running cave:repository-proxy against a Maven-type repository (in this case an internal instance of Artifactory), Cave should create the OBR metadata and store locally. However, when I run: cave:repository-proxy my-repository

Re: Provisioning Problem

Hi, (For some reason, I did not receive your email. I just noticed it on Nabble, and pasted it below.) Thank you. I tried adding that, but no change to the behaviour. What does this tag do, and where is it documented? (My previous questions remain. :-) Results are: 2015-05-27 14:48:48,319

Provisioning Problem

Hi, I am trying to set up my Karaf in my new build+deploy process. I have never used Karaf before, other than playing around with it a little in the past. I have added our company repository to the config, which I can validate by viewing the org.ops4j.pax.url.mvn file in the etc directory.

Re: Cannot start Karaf

: org.apache.karaf.management.boot.KarafMBeanServerBuilder Cheers, =David On 10/13/2014 10:15 AM, David Leangen wrote: Hi! I am new to Karaf. I am trying to set up v3.0.1 on my Mac, but am getting a JMRuntimeException: Failed to load MBeanServerBuilder. I noticed this thread: http://mail-archives.apache.org/mod_mbox/karaf-user/201404

Re: Cannot start Karaf

of Java6) ? I installed Java7. Same problem. :-( Cheers, =David On 10/13/2014 10:39 AM, David Leangen wrote: Wow! Impressive response. :-) Thank you! Can you make a try with 3.0.2 (currently on staging) ? Tried. Same problem. :-( which version of Java are you using? Please note

Re: Cannot start Karaf

that it is in $KARAF_HOME, i.e. the directory where Karaf is installed). Cheers, =David On 10/13/2014 01:47 PM, David Leangen wrote: It looks like the lib folder doesn’t contain the karaf-jmx-boot.jar file (providing the MBeanServerBuilder). Can you check that this jar is in the lib folder

  1   2   >