Charles Moulliard wrote: > > The idea to use OBR resolver api and OBR Server is excellent by > allowing to hide the real repository used behind (maven, obr, ivy, > ....) > > When deploying project into production, we are always faced to > administrators reluctant to use maven. Using an OBR server embedded in > karaf will allow us to achieve this deployment goal in an transparent > way as the user can parameter which repo (local, central, internet) > he/she would like to use. By the way, we can propose one provisioning > mechanism (obr is not required as features commands are similars with > obr except obr:source and obre:find) and use the following file (thx > to JB idea) --> /etc/org.apache.karaf.resolver.cfg to configure > repositories and resolver mechanism. In this case, the file > /etc/org.ops4j.pax.mvn.cfg is not longer required. > > My 4cents > > On Tue, Mar 15, 2011 at 2:06 PM, Jean-Baptiste Onofré > <j...@nanthrax.net> wrote: >> Agree, it's not provisioning (we can use ACE or another tool for >> provisioning). >> My purpose is more to have a central OBR, monitored and administrated by >> a >> admin, which could be used by OBR clients, including Karaf. >> >> Regards >> JB >> >> On 03/15/2011 01:06 PM, Guillaume Nodet wrote: >>> >>> On Tue, Mar 15, 2011 at 10:26, Achim >>> Nierbeck<bcanh...@googlemail.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> did I get that right, you plan to use Karaf as a OBR Server? >>>> Cause right now I think we are more used to use OBR from the client >>>> view, >>>> right? >>>> >>>> Concerning the central Manager for other instances of a clustered >>>> environment. Do we really want to >>>> have a Managing instance like in the "good old days of JEE servers" or >>>> do we want a more P2P approach? >>>> >>>> So I'm unsure if we need that or if we just need a way of >>>> "synchronizing" all instances. For Provisioning inside the "cluster" >>>> it might be a good Idea to use OBR. >>> >>> OBR is not a provisioning system. It's just a resolver API. It only >>> helps finding what actually need to be deployed. >>> >>>> Regards, Achim >>>> >>>> 2011/3/15 Jean-Baptiste Onofré<j...@nanthrax.net>: >>>>> >>>>> Hi Guillaume, >>>>> >>>>> my vision is: >>>>> 1/ only add an optional feature to be able to use Karaf OBR as an >>>>> Enterprise >>>>> OBR (including RESTful, web administration) >>>>> 2/ regarding the Karaf clustering, it could be interesting to have a >>>>> central >>>>> Karaf manager providing a central OBR >>>>> >>>>> The things that you described look good to me. Maybe just more >>>>> documentation >>>>> and more user-friendly tooling (in the WebConsole and with new obr: >>>>> command >>>>> in addition of list) could be enough :) >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 03/15/2011 08:56 AM, Guillaume Nodet wrote: >>>>>> >>>>>> On Fri, Mar 11, 2011 at 17:41,<j...@nanthrax.net> wrote: >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> Correct me if I'm wrong but, currently, we have an OBR into Karaf. >>>>>> >>>>>>> I wonder if it could be interesting to extend this OBR in a more >>>>>>> enterprise oriented way (as an optional feature) with: >>>>>>> - RESTful service to administrate the repo and upload/download >>>>>>> bundle >>>>>> >>>>>> The web console already offer a REST api afaik, but it could be made >>>>>> more formal. >>>>>> I also worked on something related a few months ago: >>>>>> http://gnodet.blogspot.com/2010/09/remoteobr.html >>>>>> More below. >>>>>> >>>>>>> - support of kar and features descriptor >>>>>>> - JNDI lookup support >>>>>> >>>>>> JNDI is kinda legacy in OSGi, so not sure how it relates to OBR. If >>>>>> I >>>>>> have to write new OSGi specific code, I wouldn't use JNDI at all, as >>>>>> it can't really handle the dynamic nature of OSGi well. >>>>>> >>>>>>> - LDAP lookup support >>>>>> >>>>>> LDAP to do what ? >>>>>> >>>>>>> - management/extension of the existing obr page in the web console >>>>>> >>>>>> >>>>>>> I don't know if we need to implement by ourself or embed an existing >>>>>>> project (felix bundlerepository/ace, archiva, aries obr, others ?). >>>>>> >>>>>> Not sure which location would be best, but I would certainly not see >>>>>> that in Karaf trunk, but eventually as a new subproject (if it ever >>>>>> ends up in Karaf). >>>>>> >>>>>>> Anyway I think it could be interesting to turn Karaf into an EBR >>>>>>> supporting remoting, management, etc. >>>>>>> >>>>>>> Wdyt ? >>>>>> >>>>>> OBR is really nice, but repositories could tend to be big and loading >>>>>> the repository internally can consume quite a lot of resources. >>>>>> That's why I've tried to split it in two parts: the client which can >>>>>> connect to a server over a REST protocol. It's far from production >>>>>> ready but that could give us a starting point. >>>>>> At that time, I've also rewritten the OBR plugin for the webconsole >>>>>> so >>>>>> that it can handle complex queries, displaying dependencies and all. >>>>>> >>>>>> I'm not quite sure to understand what your vision is. The webconsole >>>>>> already offer a lot of features to manage the repositories and see >>>>>> the >>>>>> dependencies. I'm sure it could be rewritten to be more user >>>>>> friendly, but in terms of big features, what do you see added to it ? >>>>>> >>>>>> >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> >
Charles, There is a way to get around the whole issue with requiring a client to have access to a maven repository. I use a perl script that creates a local repository with all of the bundles for an application once I get it successfully deployed into Karaf (tested, working, etc). Basically, it parses each bundle's bundle.location file to get the mvn uri, and then drops the bundle into that location in the local repo, under its appropriate name. It also creates a simple features.xml file in that local repository. Then, I add that local repository name to the features.cfg file, tar up the local repo and etc directories, and blammo, instant installation package! Too bad we don't have this sort of functionality built into the karaf console. Something like dev:createDeploymentRepository... ----- Karafman Slayer of the JEE Pounder of the Perl Programmer -- View this message in context: http://karaf.922171.n3.nabble.com/Enterprise-OBR-in-Karaf-tp2665722p2683856.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
