I think you misunderstood JB. He wasn't talking about providing the
artifacts afaik.
But yeah, if you want to avoid each karaf instance going to maven
central you could deploy a nexus and change the
etc/org.ops4j.pax.url.mvn.cfg config to point to it
On Wed, Mar 16, 2011 at 08:07, Charles Moullia
Hi JB,
What you propose looks like a nexus - sonatype repository management
platform for Karaf. Do we need that ? What could be the benefit to use
JNDI or LDAP to find features/bundles ?
Regards,
Charles
On Fri, Mar 11, 2011 at 5:41 PM, wrote:
> Hi guys,
>
> Correct me if I'm wrong but, curre
On Mar 15, 2011, at 2:10 PM, karafman wrote:
>
> 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
>>
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.
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 achi
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
On Tue, Mar 15, 2011 at 10:26, Achim Nierbeck 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
I can see that being really useful in many ways!
+1
On Tue, Mar 15, 2011 at 11:37 AM, Achim Nierbeck wrote:
> Hi JB,
>
> You are right the discussion about clustering this should be discussed
> somewhere else :)
>
> I can see your point about the OBR provisioning for Client instances
> and so for
Hi JB,
You are right the discussion about clustering this should be discussed
somewhere else :)
I can see your point about the OBR provisioning for Client instances
and so forth, so +1 from me for finding a good solution for this. :)
Regards, Achim
2011/3/15 Jean-Baptiste Onofré :
> Hi Achim,
Hi Achim,
my comments inline:
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?
Exactly. Karaf acts more as a OBR "client" right now, but it ships also
an OBR. My purpose is to be able (optionally) to
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
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
On Fri, Mar 11, 2011 at 17:41, 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 up
Hey JB,
On Fri, Mar 11, 2011 at 5:41 PM, wrote:
> Hi guys,
>
> Correct me if I'm wrong but, currently, we have an OBR into Karaf.
Well, I would rather say we have an Felix OBR integration in Karaf :)
> I wonder if it could be interesting to extend this OBR in a more enterprise
> oriented way
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
- support of kar and features
15 matches
Mail list logo
