Re: Karaf RPMs - what options are out there?

[aj...@virginia.edu]

That's simpler than distributing an RPM to the repos, by a long ways. With that 
approach, all we'd need would be the spec (build) script. I append the example 
at the end of this email. As you can see, it's not very much. I'm sure it could 
be better written (I'm no RPM "maven" {grin}) but it's a place to start. I used 
the Tanuki Java wrapper as part of the dependency, because that software is 
commonly available for almost any Linux distro.  I also included a separate 
body of source for the package (shown below as "wrapper-gear") which is just 
the files that Karaf creates from its "wrapper: " commands. These two 
inclusions allow the RPM to install Karaf as a Linux system service using the 
Tanuki wrapper.

Graham-- I'll send you a tarball of "wrapper-gear" off-list, just so you can 
see what I did.

It's this worthy of opening an issue?

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Jan 15, 2013, at 12:26 PM, Graham Leggett wrote:

> On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote:
> 
>> I have, for local consumption. I based the build on an ActiveMQ RPM script. 
>> It wasn't too difficult and I can send you the example, if you like.
> 
> If you can, I would hugely appreciate it.
> 
>> There has been discussion before on this list about maintaining a 
>> semi-"blessed" RPM of Karaf directly from the project. I'd be happy to work 
>> on that, if I could get guidance and help integrating it into the release 
>> process.
> 
> I maintain the spec file that is shipped with Apache httpd, the idea is that 
> you can download a httpd tarball and run "rpmbuild -tb " and it 
> "just works". All that is required is that a file called .spec 
> exists in the root of the tarball. (It might also work if the spec file is 
> elsewhere in the tree, but I've not tried).
> 
> I am busy looking at the jpackage version of karaf, and it seems to have a 
> significantly different structure to that shipped by Apache. Still need to 
> get my head around it.
> 
> Regards,
> Graham
> --
> 

[ajs6f@esbdev2 SPECS]$ cat apache-karaf.spec 

# turn off Red Hat's jar repacking macro
%define __jar_repack %{nil}

#
# Spec file for packaging Apach Karaf
#
Summary: Apache Karaf
Name: apache-karaf
Version: 2.2.7
Release: 1
License: Apache
Group: Networking/Daemons
Source0: 
http://www.apache.org/dyn/closer.cgi/karaf/2.2.7/apache-karaf-2.2.7.tar.gz
Source1: wrapper-gear

URL: http://karaf.apache.org/
Vendor: Apache Foundation
Packager: A. Soroka 
BuildArch: noarch
Requires: java
Requires: tanukiwrapper

%description
Apache Karaf is a small OSGi runtime which provides a lightweight container 
into which various components and applications can be deployed.

%define karaf_home /usr/share/karaf
%define karaf_data /var/cache/karaf
%define karaf_config /etc/karaf
%define karaf_deploy /var/local/karaf-deploy
%define karaf_startuplib /usr/local/lib/karaf
%define karaf_systemlib /usr/local/lib/karaf-system
%define karaf_logs /var/log/karaf

%prep
%setup

%build
# No build needed for a pure-Java application like Karaf
/bin/true

%install

# Add the "karaf" user and group
# the "|| :" ("or NOP") on the end allows for the condition that this user and 
group already exist
/usr/sbin/groupadd --system karaf 2> /dev/null || :
/usr/sbin/useradd --comment "Apache Karaf"  -g karaf \
--shell /bin/bash --system --home-dir %{karaf_home} karaf 2> /dev/null || :

# We put the various pieces of Karaf into FHS-appropriate places, then symln 
them
# together in /usr/share/karaf. 

# First copy all of the Karaf tree into %{karaf_home} (should be 
/usr/share/karaf)
mkdir -p $RPM_BUILD_ROOT%{karaf_home}
mv --verbose * $RPM_BUILD_ROOT%{karaf_home}/

# Now we make the FHS locations for Karaf stuff
mkdir -p $RPM_BUILD_ROOT%{karaf_config} $RPM_BUILD_ROOT%{karaf_deploy} 
$RPM_BUILD_ROOT%{karaf_deploy} \
$RPM_BUILD_ROOT%{karaf_startuplib} $RPM_BUILD_ROOT%{karaf_systemlib} 
$RPM_BUILD_ROOT%{karaf_data} \
$RPM_BUILD_ROOT%{karaf_logs} $RPM_BUILD_ROOT/etc/init.d

# Now we move pieces of the tree out of there into FHS-appropriate spots and 
re-symln them

pushd $RPM_BUILD_ROOT%{karaf_home}
mv etc/* $RPM_BUILD_ROOT%{karaf_config}
rmdir etc
ln -s %{karaf_config} etc
mv deploy/* $RPM_BUILD_ROOT%{karaf_deploy}
rmdir deploy
ln -s %{karaf_deploy} deploy
mv lib/* $RPM_BUILD_ROOT%{karaf_startuplib}
rmdir lib
ln -s %{karaf_startuplib} lib
mv system/* $RPM_BUILD_ROOT%{karaf_systemlib}
rmdir system
ln -s %{karaf_systemlib} system
popd

# Karaf logs show up in the data dir by default, so we make a symlink
ln -s %{karaf_logs} $RPM_BUILD_ROOT%{k

Re: Karaf RPMs - what options are out there?

[aj...@virginia.edu]

I can't speak to DEB, but a RPM is made by running a build script over a 
distribution. The script explains any prerequisites (in Karaf's case, just 
Java) where to put files, what permissions to use, what files are marked as to 
be deleted on uninstall, that kind of thing. Distribution varies, but there are 
a handful of large RPM repositories (mostly associated with different Linux 
distros) that we could target. They fulfill much the same role as Maven repos. 

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Jan 15, 2013, at 12:14 PM, Andreas Pieber wrote:

> What would we need to do to provide a RPM/DEB package? Where/how would
> we need to distribute it?
> 
> Kind regards,
> Andreas
> 
> On Tue, Jan 15, 2013 at 6:09 PM, aj...@virginia.edu  
> wrote:
>> I have, for local consumption. I based the build on an ActiveMQ RPM script. 
>> It wasn't too difficult and I can send you the example, if you like.
>> 
>> There has been discussion before on this list about maintaining a 
>> semi-"blessed" RPM of Karaf directly from the project. I'd be happy to work 
>> on that, if I could get guidance and help integrating it into the release 
>> process.
>> 
>> ---
>> A. Soroka
>> Software & Systems Engineering :: Online Library Environment
>> the University of Virginia Library
>> 
>> On Jan 15, 2013, at 11:53 AM, Graham Leggett wrote:
>> 
>>> Hi all,
>>> 
>>> I am currently packaging an application stack as RPMs for deployment to a 
>>> production system, and am looking for RPM packages for karaf.
>>> 
>>> JPackage provide a set of RPMs, but these RPMs depend on unstable (from 
>>> package's perspective) packages, and weigh in at an eye watering 274MB of 
>>> RPM dependencies.
>>> 
>>> Has anyone other than package packaged karaf as an RPM?
>>> 
>>> Regards,
>>> Graham
>>> --
>>> 
>> 

Re: Karaf RPMs - what options are out there?

[aj...@virginia.edu]

I have, for local consumption. I based the build on an ActiveMQ RPM script. It 
wasn't too difficult and I can send you the example, if you like.

There has been discussion before on this list about maintaining a 
semi-"blessed" RPM of Karaf directly from the project. I'd be happy to work on 
that, if I could get guidance and help integrating it into the release process.

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Jan 15, 2013, at 11:53 AM, Graham Leggett wrote:

> Hi all,
> 
> I am currently packaging an application stack as RPMs for deployment to a 
> production system, and am looking for RPM packages for karaf.
> 
> JPackage provide a set of RPMs, but these RPMs depend on unstable (from 
> package's perspective) packages, and weigh in at an eye watering 274MB of RPM 
> dependencies.
> 
> Has anyone other than package packaged karaf as an RPM?
> 
> Regards,
> Graham
> --
> 

Re: same feature name exists in multi feature repo url

[aj...@virginia.edu]

That's what I meant by "ordering behavior undefined". The order of search is 
what you seem to be asking about.

To my understanding (I welcome correction) it isn't defined and you just 
shouldn't rely on it (for example, it could change between versions of Karaf). 
If you want to make sure a certain feature is loaded and no other, you have to 
distinguish it (by name or version) from every other. Perhaps you might try 
using your FQDN or the like as a prefix.

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Oct 23, 2012, at 11:03 PM, XiLai Dai wrote:

> Hi,
> My question is not about the version of feature, there is only one feature of 
> version 1.0 (name='myfeature' version='1.0') defined in both two different 
> features xml which I provided in the mail.
> 
> My question is: if a feature (same name and same version) exists in multi 
> features repo xml, and all these features urls have been installed into karaf 
> (using features:addurl), then, when I run: 
>> features:install myfeature/1.0
> Which one will be installed? The one from features_a xml? or the one from 
> features_b xml?
> 
> From the result of my test, no matter the order of features:addurl commands 
> executed, the last one from the features:listurl will be installed into 
> karaf.  Is it right? How to allow user to select his preferred myfeatu.re/1.0 
> to install?
> 
> Thanks.
> Xilai
> -Original Message-
> From: aj...@virginia.edu [mailto:aj...@virginia.edu] 
> Sent: Tuesday, October 23, 2012 10:01 PM
> To: user@karaf.apache.org
> Subject: Re: same feature name exists in multi feature repo url
> 
> To be clear, if I understand you correctly, you're pointing out that the 
> version attribute in feature XML _defines_ the version of the feature that 
> the XML describes. The version of the feature that you offer when installing 
> via Maven protocol (say, via command-line features:install) is what Karaf 
> _searches_ for in available repositories, with ordering behavior undefined 
> (howsoever the feature-version in Maven was defined). If you don't give a 
> version in your install operation, it'll search for the latest non-snapshot 
> in available repositories, with ordering behavior undefined. And just to be 
> complete, if you use a feature version in a feature declared as a 
> _dependency_ in feature XML, it has the second meaning.
> 
> Is that right? Two different meanings, the first of which (defining the 
> feature version) _only_ applies to the attribute in XML?
> 
> ---
> A. Soroka
> Software & Systems Engineering :: Online Library Environment
> the University of Virginia Library
> 
> On Oct 23, 2012, at 9:50 AM, Andreas Pieber wrote:
> 
>> Well, since you're using the mvn (maven) Protokoll this need to be installed 
>> at least in your lokal maven repository. The version of the features you've 
>> defined in the xml is of NO relevance here. Only the version you've given it 
>> in your maven repo is relevant. For starting using the file: protocol, 
>> directly pointing to your features in your file system might be the easier 
>> option. You can still switch to mvn there once you get familiar with the 
>> concepts.
>> 
>> Kind regards, Andreas
>> 
>> On Oct 23, 2012 5:36 AM, "XiLai Dai"  wrote:
>> Hi,
>> 
>> 
>> 
>> One feature xml named feature-a-1.0
>> 
>> 
>> 
>> 
>> 
>> > xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
>> 
>> 
>> 
>>  
>> 
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jdom/1.1_4
>> 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> The other feature xml named feature-b-1.0
>> 
>> 
>> 
>> > xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
>> 
>> 
>> 
>>  
>> 
>> mvn:commons-dbcp/commons-dbcp/1.4
>> 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Both of them have a feature named "myfeature"/"1.0". then add feature url to 
>> karaf:
>> 
>> 
>> 
>> karaf@root>features:addurl mvn:org.test/features_a/1.0/xml
>> 
>> karaf@root>features:addurl mvn:org.test/features_b/1.0/xml
>> 
>> 
>> 
>> then install myfeature:  karaf@root>features:install myfeature
>> 
>> 
>> 
>> which is the expected search order for myfeature?  I did some test but 
>> sometimes myfeature which from the first features xml installed, sometimes 
>> from the second features.
>> 
>> 
>> 
>> Thanks.
>> 
>> Xilai
>> 
> 

Re: same feature name exists in multi feature repo url

[aj...@virginia.edu]

I'd be honored. {grin}

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Oct 23, 2012, at 10:04 AM, Andreas Pieber wrote:

> Yep. Exactly to the point! Would you mind if I include your summary into the 
> user manual? :-)
> 
> Kind regards, Andreas
> 
> On Oct 23, 2012 4:02 PM, "aj...@virginia.edu"  wrote:
> To be clear, if I understand you correctly, you're pointing out that the 
> version attribute in feature XML _defines_ the version of the feature that 
> the XML describes. The version of the feature that you offer when installing 
> via Maven protocol (say, via command-line features:install) is what Karaf 
> _searches_ for in available repositories, with ordering behavior undefined 
> (howsoever the feature-version in Maven was defined). If you don't give a 
> version in your install operation, it'll search for the latest non-snapshot 
> in available repositories, with ordering behavior undefined. And just to be 
> complete, if you use a feature version in a feature declared as a 
> _dependency_ in feature XML, it has the second meaning.
> 
> Is that right? Two different meanings, the first of which (defining the 
> feature version) _only_ applies to the attribute in XML?
> 
> ---
> A. Soroka
> Software & Systems Engineering :: Online Library Environment
> the University of Virginia Library
> 
> On Oct 23, 2012, at 9:50 AM, Andreas Pieber wrote:
> 
> > Well, since you're using the mvn (maven) Protokoll this need to be 
> > installed at least in your lokal maven repository. The version of the 
> > features you've defined in the xml is of NO relevance here. Only the 
> > version you've given it in your maven repo is relevant. For starting using 
> > the file: protocol, directly pointing to your features in your file system 
> > might be the easier option. You can still switch to mvn there once you get 
> > familiar with the concepts.
> >
> > Kind regards, Andreas
> >
> > On Oct 23, 2012 5:36 AM, "XiLai Dai"  wrote:
> > Hi,
> >
> >
> >
> > One feature xml named feature-a-1.0
> >
> >
> >
> > 
> >
> >  > xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
> >
> >
> >
> >   
> >
> > 
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jdom/1.1_4
> >
> >   
> >
> >
> >
> > 
> >
> >
> >
> > The other feature xml named feature-b-1.0
> >
> >
> >
> >  > xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
> >
> >
> >
> >   
> >
> >  mvn:commons-dbcp/commons-dbcp/1.4
> >
> >   
> >
> >
> >
> > 
> >
> >
> >
> > Both of them have a feature named “myfeature”/”1.0”. then add feature url 
> > to karaf:
> >
> >
> >
> > karaf@root>features:addurl mvn:org.test/features_a/1.0/xml
> >
> > karaf@root>features:addurl mvn:org.test/features_b/1.0/xml
> >
> >
> >
> > then install myfeature:  karaf@root>features:install myfeature
> >
> >
> >
> > which is the expected search order for myfeature?  I did some test but 
> > sometimes myfeature which from the first features xml installed, sometimes 
> > from the second features.
> >
> >
> >
> > Thanks.
> >
> > Xilai
> >
> 

Re: same feature name exists in multi feature repo url

[aj...@virginia.edu]

To be clear, if I understand you correctly, you're pointing out that the 
version attribute in feature XML _defines_ the version of the feature that the 
XML describes. The version of the feature that you offer when installing via 
Maven protocol (say, via command-line features:install) is what Karaf 
_searches_ for in available repositories, with ordering behavior undefined 
(howsoever the feature-version in Maven was defined). If you don't give a 
version in your install operation, it'll search for the latest non-snapshot in 
available repositories, with ordering behavior undefined. And just to be 
complete, if you use a feature version in a feature declared as a _dependency_ 
in feature XML, it has the second meaning.

Is that right? Two different meanings, the first of which (defining the feature 
version) _only_ applies to the attribute in XML?

---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Oct 23, 2012, at 9:50 AM, Andreas Pieber wrote:

> Well, since you're using the mvn (maven) Protokoll this need to be installed 
> at least in your lokal maven repository. The version of the features you've 
> defined in the xml is of NO relevance here. Only the version you've given it 
> in your maven repo is relevant. For starting using the file: protocol, 
> directly pointing to your features in your file system might be the easier 
> option. You can still switch to mvn there once you get familiar with the 
> concepts.
> 
> Kind regards, Andreas
> 
> On Oct 23, 2012 5:36 AM, "XiLai Dai"  wrote:
> Hi,
> 
>  
> 
> One feature xml named feature-a-1.0
> 
>  
> 
> 
> 
>  xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
> 
>  
> 
>   
> 
> 
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jdom/1.1_4
> 
>   
> 
>  
> 
> 
> 
>  
> 
> The other feature xml named feature-b-1.0
> 
>  
> 
>  xmlns="http://karaf.apache.org/xmlns/features/v1.0.0";>
> 
>  
> 
>   
> 
>  mvn:commons-dbcp/commons-dbcp/1.4
> 
>   
> 
>  
> 
> 
> 
>  
> 
> Both of them have a feature named “myfeature”/”1.0”. then add feature url to 
> karaf:
> 
>  
> 
> karaf@root>features:addurl mvn:org.test/features_a/1.0/xml
> 
> karaf@root>features:addurl mvn:org.test/features_b/1.0/xml
> 
>  
> 
> then install myfeature:  karaf@root>features:install myfeature
> 
>  
> 
> which is the expected search order for myfeature?  I did some test but 
> sometimes myfeature which from the first features xml installed, sometimes 
> from the second features.
> 
>  
> 
> Thanks.
> 
> Xilai
> 

Re: What would be the right way to develop Web console just for PID props changes?

[aj...@virginia.edu]

You can see a nice example of one way of setting up Karaf shell commands here:

http://svn.apache.org/viewvc/karaf/trunk/shell/console/src/test/java/org/apache/karaf/shell/commands/

I found that useful-- perhaps you will.

---
A. Soroka
Online Library Environment
the University of Virginia Library

On Fri, Jul 20, 2012 at 3:00 PM, mikek753  wrote:
> hello,
>
> thank you for the reply.
> Would you provide a little more info? Please.
>
> How to make karaf command call from my code?
> how to process response to extract list of CM by PID  properties , key-value
> pairs?
>
> Any link to example code would help me a lot.
>
> Mike.
>
>
>
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/What-would-be-the-right-way-to-develop-Web-console-just-for-PID-props-changes-tp4025258p4025260.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Karaf child instance auto-start and Wrapper

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've got a question about Karaf child instances and how they start (or don't).

My use case is as follows: I'd like to have a Karaf instance with one or more 
child instances, and I'd like the child instances to automatically start when 
the parent instance starts. The motivation is failure recovery. In the event of 
an OS or hardware failure, I'd like all the instances to come back up, without 
human intervention.

- From what I've seen of the behavior, child instances do _not_ automatically 
start when a parent instance does.

Is there a setting I can throw to influence this behavior (e.g. in the 
"instance.properties" file), or is it something I'll need to script at the OS 
level using the "admin" shell script?

Also, I'm wondering if anyone can tell me about the interaction of the Wrapper 
service and child instances. In other words, does the Wrapper watch and 
heartbeat child instances as well as the parent instance?

- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPvpNaAAoJEATpPYSyaoIkeYsIAI4t7Go2zmuumFcHOy05+xr6
JkS4NKnYobbtdlgj4+rde00RedY5lV8x90Vl4fBVlzANPKcRHhIc+P1e+0wJdCMn
4WGxukJPcNGob1PAdFXXqQgILJ6emyuAdK9CW5LvinjZnoKDwKr2tn5XsjeecTiR
BMyz+dq+9h57Xr3es6NuqwpaB/9vA9rhekyxkH6tQMZnLbk/ijZulrlQpVmSiqGW
n4exHvt5QJ/MeIOylz/9woRez8Yi8OtP7NsniV7LxWpbw5Qcmp6v7ONr5B9sir9N
x+Uuz9GheYpvU0unxPiMB6Yebz1tPfeERtb8gQL2gkP6hBoZAGxd0QxVIdF/iSU=
=YFjp
-END PGP SIGNATURE-

Karaf RPM and DEB distribution WAS: Re: Convenient way of using karaf features-maven-plugin to include also *.pom

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How would you like to go about assembling "blessed" RPM/DEB versions? It sounds 
like several sites have already built them for their own use.

I'm guessing most of us used the pre-integrated "wrapper" functionality and 
just added machinery to adjust the filesystem and add appropriate contents, and 
start a system service. That's what we did.


- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Apr 19, 2012, at 12:35 PM, Christoph Emmersberger wrote:

> Hi,
> 
> good idea to distribute an RPM and DEB version. Currently we are also 
> building our own karaf RPM (which is Talend branded, but anyway) and I can 
> install this one without any issues.
> 
> The other issue I'm trying to solve by now, is the distribution of our 
> application, not of the infrastructure. Since the IT service provider has 
> certain standards on software delivery, all application artifacts must be 
> delivered as RPM as well. Therefore we created in the past our own local-repo 
> and simply copied it with an RPM to the karaf container. This worked quite 
> well.
> 
> In addition to this, we need to integrate now some of the further management 
> tools, like archiva which runs on a proper environment with differen disk 
> backup, etc. It would be quite simple to do a mvn deploy to a different repo 
> when I'd be sitting in the same network domain. Since it is not the case, and 
> I need to deliver all my software as RPM, I'm trying to package the archives 
> also as RPM and add them in a "manual / copy" style via the RPM script to 
> archiva.
> 
> That's the whole point why I am looking at this *.pom functionality.
> 
> Happy to share some experience in creating an RPM for karaf.
> 
> Many greets and kind regards,
> 
> Christoph
> 
> On 19.04.2012, at 18:20, Jean-Baptiste Onofré wrote:
> 
>> Hi,
>> 
>> RPM/DEB files could be provided on karaf-extra, and we can provide it to 
>> some distributions.
>> 
>> I would be happy to manage it with you all guys.
>> 
>> Regards
>> JB
>> 
>> On 04/19/2012 06:16 PM, aj...@virginia.edu wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> 
>>> Speaking as someone unrelated to Christoph, I'd like to cheer for the 
>>> notion of a "blessed" (i.e. examined or built by a core developer) RPM for 
>>> Karaf.
>>> 
>>> We roll our own here, but it would be much better to rely on one we share 
>>> with the community. I know that Apache projects don't often distribute 
>>> artifacts like DEB or RPM files as official, but I'd be happy to help in 
>>> any way I can.
>>> 
>>> - ---
>>> A. Soroka
>>> Software&  Systems Engineering :: Online Library Environment
>>> the University of Virginia Library
>>> 
>>> On Apr 19, 2012, at 12:10 PM, Jean-Baptiste Onofré wrote:
>>> 
>>>> Hi Christoph,
>>>> 
>>>> Some time ago (in far galaxy ;)), I thought about:
>>>> - a RPM/DEB package to install Karaf instance
>>>> - a RPM/DEB package to populate the Karaf system directory and update the 
>>>> etc configuration files
>>>> 
>>>> It doesn't require a Archiva (or other Maven repository manager), the 
>>>> Karaf system folder is already a Maven structure.
>>>> 
>>>> WDYT ?
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 04/19/2012 06:06 PM, Emmersberger, Christoph wrote:
>>>>> Hi Jean-Baptiste,
>>>>> 
>>>>> thank's for your response.
>>>>> 
>>>>> I'll give it a try with the maven-metadata-local.xml since calling a REST 
>>>>> Service (I assume you shortened the long term by RS) might become 
>>>>> difficult from the RPM process on an environment where JAVA_HOME might 
>>>>> not be standardized set across all environments.
>>>>> 
>>>>> Many greets and kind regards,
>>>>> 
>>>>> Christoph
>>>>> 
>>>>> On 19.04.2012, at 16:04, Jean-Baptiste Onofré wrote:
>>>>> 
>>>>>> Hi Christoph,
>>>>>> 
>>>>>> The "efficient" way is to mimic the maven-deploy-plugin.
>>>>>> 
>>>>>> The maven-deploy-plugin (in deploy or deploy-file goals) create all the 
>>>>>> maven metadat

Re: Convenient way of using karaf features-maven-plugin to include also *.pom

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Speaking as someone unrelated to Christoph, I'd like to cheer for the notion of 
a "blessed" (i.e. examined or built by a core developer) RPM for Karaf. 

We roll our own here, but it would be much better to rely on one we share with 
the community. I know that Apache projects don't often distribute artifacts 
like DEB or RPM files as official, but I'd be happy to help in any way I can.

- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Apr 19, 2012, at 12:10 PM, Jean-Baptiste Onofré wrote:

> Hi Christoph,
> 
> Some time ago (in far galaxy ;)), I thought about:
> - a RPM/DEB package to install Karaf instance
> - a RPM/DEB package to populate the Karaf system directory and update the etc 
> configuration files
> 
> It doesn't require a Archiva (or other Maven repository manager), the Karaf 
> system folder is already a Maven structure.
> 
> WDYT ?
> 
> Regards
> JB
> 
> On 04/19/2012 06:06 PM, Emmersberger, Christoph wrote:
>> Hi Jean-Baptiste,
>> 
>> thank's for your response.
>> 
>> I'll give it a try with the maven-metadata-local.xml since calling a REST 
>> Service (I assume you shortened the long term by RS) might become difficult 
>> from the RPM process on an environment where JAVA_HOME might not be 
>> standardized set across all environments.
>> 
>> Many greets and kind regards,
>> 
>> Christoph
>> 
>> On 19.04.2012, at 16:04, Jean-Baptiste Onofré wrote:
>> 
>>> Hi Christoph,
>>> 
>>> The "efficient" way is to mimic the maven-deploy-plugin.
>>> 
>>> The maven-deploy-plugin (in deploy or deploy-file goals) create all the 
>>> maven metadata (pom.properties, maven-metadata.xml, etc) that Archiva use.
>>> 
>>> On karaf-maven-plugin (trunk), I implemented the generation of 
>>> maven-metadata-local.xml.
>>> 
>>> Archiva provide a RS interface to upload artifact and generate the metadata 
>>> on the fly (using the RS provided info).
>>> 
>>> Regards
>>> JB
>>> 
>>> On 04/19/2012 03:37 PM, Christoph Emmersberger wrote:
 Dear all,
 
 I'm looking currently for a convenient way of using the
 features-maven-plugin to create an offline repo and deploy it as an RPM.
 
 What I've already achieved is the creation of the RPM package and the
 inclusion of the created bundels (see also my feature-repo target folder)
 
 [cemmersb@localhost repo-snapshot]$ tree
 .
 |-- commons-io
 | `-- commons-io
 | |-- 1.4
 | | |-- commons-io-1.4.jar
 | | |-- commons-io-1.4.jar.md5
 | | |-- commons-io-1.4.jar.sha1
 | | |-- maven-metadata.xml
 | | |-- maven-metadata.xml.md5
 | | `-- maven-metadata.xml.sha1
 | |-- maven-metadata.xml
 | |-- maven-metadata.xml.md5
 | `-- maven-metadata.xml.sha1
 `-- org
 `-- apache
 |-- karaf
 | `-- assemblies
 | `-- features
 | |-- enterprise
 | | `-- 2.2.2
 | | `-- enterprise-2.2.2-features.xml
 | `-- standard
 | `-- 2.2.2
 | `-- standard-2.2.2-features.xml
 `-- servicemix
 `-- bundles
 `-- org.apache.servicemix.bundles.ehcache
 |-- 2.5.0_1
 | |-- maven-metadata.xml
 | |-- maven-metadata.xml.md5
 | |-- maven-metadata.xml.sha1
 | |-- org.apache.servicemix.bundles.ehcache-2.5.0_1.jar
 | |-- org.apache.servicemix.bundles.ehcache-2.5.0_1.jar.md5
 | `-- org.apache.servicemix.bundles.ehcache-2.5.0_1.jar.sha1
 |-- maven-metadata.xml
 |-- maven-metadata.xml.md5
 `-- maven-metadata.xml.sha1
 
 My RPM does basically nothing else than copying the repo into the
 Archiva repository data folder that I chose for that operation.
 Generally the processing works well whey Karaf adds Archiva as a
 repository, features and bundles can be installed that way. The only
 missing point for me is, that Archiva complains about incomplete
 metadata, which is correct since there is no pom file included to the
 feature-repo.
 
 Archiva screen output:
 
 
 
 
 2.0-rc3-SNAPSHOT
 
 
 
 Artifact metadata is incomplete.
 
 Does anyone of you know about a convenient way, to include the pom files
 as well?
 
 Many thanks and kind regards,
 
 Christoph
>>> 
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPkDpiAAoJEATpPYSyaoIk0+IH/jHOaIqvRiBmHViZ9i9TO+TR
8KlAW3OrZEcq4WNafB1V+3J9plzDA54lWjP3pd/DeqN0znw+SBB39E0CpcEX43sI
+7SgNkUlJTk2lJlHzb9VQNeMxk65B3Es/DTla++l6T99iML2EGxDwKZoQLtVkYj6
JD+8l3Ok/Zfh6BtcY2wI5BQNjTV1FCdUkNMSKvWrg8KBlC2ZSmeCHORJMzG7nQE2
anjUcOkr3H6brSmFGf6UqdXdNhRRDfUd1xGctPoosGxjKazpCy2pNpVwaSBWdqeM
sePl/x8Yj9WnffKKcTJoQmgx

Re: Deploying data sources

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've had good success with just this style of deployment, and it's very nice to 
be able simply to add a OSGi Metatype annotation document and have your 
configuration properties appear in the Felix Web Console with labels and 
descriptions and default values.

- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Apr 16, 2012, at 8:51 AM, Jean-Baptiste Onofré wrote:

> Username/password/URL could be in  and so handle in the 
> "application" config oriented file in etc.
> 
> Regards
> JB
> 
> On 04/16/2012 02:47 PM, Christian Schneider wrote:
>> I would simply deploy the blueprint xml by hand. Just treat it like a
>> config file you would have to add.
>> This is of course not everyone´s favorite style.
>> 
>> The problem with adding the blueprint to the feature is that it would
>> have to be in the maven repo. As the username and password are in this
>> file this is not recommended.
>> 
>> So another way to achieve what I did is separate the things that should
>> be configured per server or stage from the things that keep the same like
>> driver class name. You could use the config admin service in the
>> blueprint file to move the username / password to a separate config file.
>> This would make the whole thing a bit more complex though but you could
>> then safely put the blueprint file into a feature.
>> 
>> Christian
>> 
>> 
>> 2012/4/16 Borut Bolčina > >
>> 
>>Hello,
>> 
>>my first post here, so bare with me please - newbie on board.
>> 
>>I am trying to deploy my first camel route to Karaf and this route
>>must be configurable (html address) and must persist some data with
>>jpa component. This route is happily persisting in my test (outside
>>osgi container).
>> 
>>Now I am reading
>>
>> https://github.com/cschneider/Karaf-Tutorial/blob/master/db/datasource/datasource-mysql.xml
>>  where
>>it says I should copy the file to Karaf's deploy folder.
>> 
>>And the question: What is the practice of deploying data sources?
>>Should I create a features project which includes a blueprint for my
>>route's data source?
>> 
>>Let's say my route needs connection to mysql database, so the
>>feature project would include features.xml
>> 
>>
>>http://karaf.apache.org/xmlns/features/v1.0.0";
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0
>>http://karaf.apache.org/xmlns/features/v1.0.0";>
>> 
>>
>>
>> mvn:mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.9.0
>>mvn:mvn:mysql/mysql-connector-java/5.1.18
>>mvn:my.company/route-weather-current/${pom.version}
>>*my datasource blueprint*
>>>
>> finalname="/etc/weather.cfg">mvn:my.company/features-weather/${pom.version}/cfg
>>
>>
>> 
>>I guess then the only command to install my Camel route to Karaf
>>would then be feature:install and all the dependencies including
>>datasource and configuration would be installed before. And how to
>>package the "my datasource blueprint"?
>> 
>>Or is there some other practice?
>> 
>>Thanks,
>>borut
>> 
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPjBicAAoJEATpPYSyaoIkAnAIAIiVH4OsOLPbhMKxUxUhSBbP
2//XLJm3hODlaDtf99S6JraqRT51nU95WwSVyufui1KSK2gnOWw+HU638F1dKliQ
WnqcLOaT0iUpxTsnt/eQSKDtbEd3iVqFC2uDTZtqitD1IM19stqHjsaNbpRAfWEZ
Ni5TAKV0NRWfOM82d+3RF6Fxyp86imT1sWB8qlyYDKMmJPeavjFpnCycJ9Alkt1d
XFlhBHDBBM9/3Xkdt1Kh37UB+6uLeZaR8hcJRw1lJKEvrceciRUy+vzRQAnZlUCn
mjWyOjw2GrjjUVg8DiD23+1wH1Mp9gB5ckOF44ghVwX8JYGqgn4/8so3G7cauXg=
=Lhx2
-END PGP SIGNATURE-

Re: Convert Virgo PLAN to Karaf Feature files

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems to me that you might use the "config" element as shown at this link, 
but I welcome correction.

https://felix.apache.org/site/46-provisioning.html#4.6.Provisioning-Configurations

- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Mar 29, 2012, at 11:02 AM, James Gartner wrote:

> Folks,
> I have a Virgo PLAN file that i am trying to convert to a Feature file.
> Are there any guidelines for this? The plan file has this:
> 
> 
> 
> 
> I"m a bit unsure how to convert the configuration file artifact into an item
> in the feature file.
> Would it be something like this:
> mvn:com.example.service1./com.example.service1.properties
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Convert-Virgo-PLAN-to-Karaf-Feature-files-tp3867950p3867950.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPdHqlAAoJEATpPYSyaoIk8t4H/i31AKfjs2Cih9K4xHF+ImRK
kJUu/I6sHhPcPal9CGGXunJL8r4+X6yHAY8qrIVX1mePws2oysdStcquMfW2fMy5
INkou4hDkAd17ewZXWO5GEO+VmpLAH+Mk6K6JAhKQum6WEK8LLEoHRUCk/8P4apU
L2qQqw00Fhi1mcpD+Ir6NaTAlQabdYsn8L6/p/apjcbu0DTst2v/5WRXyzTvmj0B
kI6DKEhGIq4JWIcsQDvGZUXGNPx6DN6oNuR94LKDu4ruuS5nEX70X038gqVIW+As
L79NLuxIxITK4eHhxZ7ge301XXJ5pmkXeo7d5dIdnX7HquzDPFiTKv9mIE5RLZ0=
=ULUa
-END PGP SIGNATURE-