You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Graham Leggett <mi...@sharp.fm> on 2013/01/15 17:53:54 UTC
Karaf RPMs - what options are out there?
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?
Posted by mikevan <mv...@comcast.net>.
Jamie,
Once you're clear on the methodology, I will volunteer test it for the
project in CentOS 6.3 (building it, then deploying it as an RPM package).
On 1/16/2013 12:39 AM, jgoodyear [via Karaf] wrote:
> The concept of providing an RPM/Deb release option is perfectly fine
> from my POV, this would require opening issues in Jira to add these
> release targets. A quick search turns up a Maven rpm plugin
> (http://mojo.codehaus.org/rpm-maven-plugin/) that may be used to keep
> our release process streamlined. There may be other methodologies
> available that we should consider as well
> (http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html).
>
> A couple of things we'd also have to check is how we can sign these
> artifacts in accordance with ASF procedures, update release process to
> reflect any new steps, and test our new RPMs.
>
> One thing I would like to do before hand however is see how other
> Apache projects provide RPMs. Far as I can tell RPMs are being
> provided by other groups (i.e., HTTPD and Tomcat can be found as RPMs
> but the project pages do not have links for obtaining them, OpenOffice
> seems to be one of the few to list these other packages
> http://www.openoffice.org/download/other.html). We need to check if
> there are any guidance from the ASF regarding their standards for
> RPM/Deb/DMG/etc package releases.
>
> Cheers,
> Jamie
>
> On Tue, Jan 15, 2013 at 10:54 PM, Andreas Pieber <[hidden email]
> </user/SendEmail.jtp?type=node&node=4027307&i=0>> wrote:
>
> > TBH I'm still not against the idea of having deb/rpm for Karaf. So the
> > release manager would
> >
> > a) run "mvn release:prepare ... "
> > b) scripts/rpmPackaging.sh
> > c) deploy the final artifact to a rpm repo? Or simply provide it for
> > download with the rest of the distribution in hope someone will pick
> > up the package and distribute it to their favorite repos?
> >
> > Feel free to correct me, but it sounds reasonable to me. BUT the
> > decision need to be made by our release managers:
> >
> > @Jamie: WDYT?
> >
> > Kind regards,
> > Andreas
> >
> > p.s.: yes, please create an issue with this script anyway. Would make
> > it ways easier to find later on.
> >
> > On Tue, Jan 15, 2013 at 6:37 PM, [hidden email]
> </user/SendEmail.jtp?type=node&node=4027307&i=1> <[hidden email]
> </user/SendEmail.jtp?type=node&node=4027307&i=2>> wrote:
> >> 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, [hidden email]
> </user/SendEmail.jtp?type=node&node=4027307&i=3> 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
> <tarball>" and it "just works". All that is required is that a file
> called <package>.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 <[hidden email]
> </user/SendEmail.jtp?type=node&node=4027307&i=4>>
> >> 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%{karaf_data}/log
> >>
> >> # Tanuki wrapper configuration
> >> cp -v %{SOURCE1}/karaf-wrapper.conf
> $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf
> >>
> >> # init.d script
> >> cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf
> >>
> >> # Java to support Wrapper operation
> >> cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib}
> >>
> >> %post
> >> # install Karaf service (but don't activate)
> >> /sbin/chkconfig --add karaf
> >>
> >> %preun
> >> # turn off Karaf and remove it from the init.d services before
> uninstalling
> >> if [ $1 = 0 ]; then
> >> /etc/init.d/karaf stop
> >> /sbin/chkconfig --del karaf
> >> fi
> >>
> >> %files
> >> %doc %{karaf_home}/karaf-manual-2.2.7.pdf
> >> %doc %{karaf_home}/karaf-manual-2.2.7.html
> >>
> >> # Karaf startup script (uses Tanuki wrapper)
> >> %attr(755, root, root) /etc/init.d/karaf
> >>
> >> # Karaf configuration
> >> %config(noreplace) %attr(775, root, karaf) %{karaf_config}
> >>
> >> # Karaf bundle cache, ActiveMQ data, etc. This is the real location
> of KARAF_DATA
> >> %attr(775, karaf, karaf) %{karaf_data}
> >>
> >> # Karaf hot deploy directory
> >> %attr(775, karaf, karaf) %{karaf_deploy}
> >>
> >> # Karaf logs
> >> %attr(775, karaf, karaf) %{karaf_logs}
> >>
> >> # Karaf startup libraries
> >> %attr(755, root, root) %{karaf_startuplib}
> >>
> >> # Karaf packaged Maven repo. Most of Karaf code is here, not in the
> startup libraries
> >> %attr(755, root, root) %{karaf_systemlib}
> >>
> >> # Full of symlinks to files above, plus demos, a README or two,
> etc.: this is treated as KARAF_HOME and KARAF_BASE
> >> # we have to leave it writeable by the karaf group in order for
> user karaf to create the Karaf lockfile
> >> # (which should eventually move to KARAF_DATA: see
> https://issues.apache.org/jira/browse/KARAF-579)
> >> %attr(775, root, karaf) %{karaf_home}
> >>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://karaf.922171.n3.nabble.com/Karaf-RPMs-what-options-are-out-there-tp4027284p4027307.html
>
> To start a new topic under Karaf - User, email
> ml-node+s922171n930749h71@n3.nabble.com
> To unsubscribe from Karaf - User, click here
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=930749&code=bXZhbmdlZXJ0cnV5QGNvbWNhc3QubmV0fDkzMDc0OXwtNjA0ODc4OTY2>.
> NAML
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
-----
Mike Van (All links open in new tabs)
Committer - Kalumet
Atraxia Technologies
Mike Van's Open Source Technologies Blog
--
View this message in context: http://karaf.922171.n3.nabble.com/Karaf-RPMs-what-options-are-out-there-tp4027284p4027350.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Karaf RPMs - what options are out there?
Posted by "Jamie G." <ja...@gmail.com>.
The concept of providing an RPM/Deb release option is perfectly fine
from my POV, this would require opening issues in Jira to add these
release targets. A quick search turns up a Maven rpm plugin
(http://mojo.codehaus.org/rpm-maven-plugin/) that may be used to keep
our release process streamlined. There may be other methodologies
available that we should consider as well
(http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html).
A couple of things we'd also have to check is how we can sign these
artifacts in accordance with ASF procedures, update release process to
reflect any new steps, and test our new RPMs.
One thing I would like to do before hand however is see how other
Apache projects provide RPMs. Far as I can tell RPMs are being
provided by other groups (i.e., HTTPD and Tomcat can be found as RPMs
but the project pages do not have links for obtaining them, OpenOffice
seems to be one of the few to list these other packages
http://www.openoffice.org/download/other.html). We need to check if
there are any guidance from the ASF regarding their standards for
RPM/Deb/DMG/etc package releases.
Cheers,
Jamie
On Tue, Jan 15, 2013 at 10:54 PM, Andreas Pieber <an...@gmail.com> wrote:
> TBH I'm still not against the idea of having deb/rpm for Karaf. So the
> release manager would
>
> a) run "mvn release:prepare ... "
> b) scripts/rpmPackaging.sh
> c) deploy the final artifact to a rpm repo? Or simply provide it for
> download with the rest of the distribution in hope someone will pick
> up the package and distribute it to their favorite repos?
>
> Feel free to correct me, but it sounds reasonable to me. BUT the
> decision need to be made by our release managers:
>
> @Jamie: WDYT?
>
> Kind regards,
> Andreas
>
> p.s.: yes, please create an issue with this script anyway. Would make
> it ways easier to find later on.
>
> On Tue, Jan 15, 2013 at 6:37 PM, ajs6f@virginia.edu <aj...@virginia.edu> wrote:
>> 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, ajs6f@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 <tarball>" and it "just works". All that is required is that a file called <package>.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 <aj...@virginia.edu>
>> 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%{karaf_data}/log
>>
>> # Tanuki wrapper configuration
>> cp -v %{SOURCE1}/karaf-wrapper.conf $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf
>>
>> # init.d script
>> cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf
>>
>> # Java to support Wrapper operation
>> cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib}
>>
>> %post
>> # install Karaf service (but don't activate)
>> /sbin/chkconfig --add karaf
>>
>> %preun
>> # turn off Karaf and remove it from the init.d services before uninstalling
>> if [ $1 = 0 ]; then
>> /etc/init.d/karaf stop
>> /sbin/chkconfig --del karaf
>> fi
>>
>> %files
>> %doc %{karaf_home}/karaf-manual-2.2.7.pdf
>> %doc %{karaf_home}/karaf-manual-2.2.7.html
>>
>> # Karaf startup script (uses Tanuki wrapper)
>> %attr(755, root, root) /etc/init.d/karaf
>>
>> # Karaf configuration
>> %config(noreplace) %attr(775, root, karaf) %{karaf_config}
>>
>> # Karaf bundle cache, ActiveMQ data, etc. This is the real location of KARAF_DATA
>> %attr(775, karaf, karaf) %{karaf_data}
>>
>> # Karaf hot deploy directory
>> %attr(775, karaf, karaf) %{karaf_deploy}
>>
>> # Karaf logs
>> %attr(775, karaf, karaf) %{karaf_logs}
>>
>> # Karaf startup libraries
>> %attr(755, root, root) %{karaf_startuplib}
>>
>> # Karaf packaged Maven repo. Most of Karaf code is here, not in the startup libraries
>> %attr(755, root, root) %{karaf_systemlib}
>>
>> # Full of symlinks to files above, plus demos, a README or two, etc.: this is treated as KARAF_HOME and KARAF_BASE
>> # we have to leave it writeable by the karaf group in order for user karaf to create the Karaf lockfile
>> # (which should eventually move to KARAF_DATA: see https://issues.apache.org/jira/browse/KARAF-579)
>> %attr(775, root, karaf) %{karaf_home}
>>
Re: Karaf RPMs - what options are out there?
Posted by Andreas Pieber <an...@gmail.com>.
TBH I'm still not against the idea of having deb/rpm for Karaf. So the
release manager would
a) run "mvn release:prepare ... "
b) scripts/rpmPackaging.sh
c) deploy the final artifact to a rpm repo? Or simply provide it for
download with the rest of the distribution in hope someone will pick
up the package and distribute it to their favorite repos?
Feel free to correct me, but it sounds reasonable to me. BUT the
decision need to be made by our release managers:
@Jamie: WDYT?
Kind regards,
Andreas
p.s.: yes, please create an issue with this script anyway. Would make
it ways easier to find later on.
On Tue, Jan 15, 2013 at 6:37 PM, ajs6f@virginia.edu <aj...@virginia.edu> wrote:
> 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, ajs6f@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 <tarball>" and it "just works". All that is required is that a file called <package>.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 <aj...@virginia.edu>
> 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%{karaf_data}/log
>
> # Tanuki wrapper configuration
> cp -v %{SOURCE1}/karaf-wrapper.conf $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf
>
> # init.d script
> cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf
>
> # Java to support Wrapper operation
> cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib}
>
> %post
> # install Karaf service (but don't activate)
> /sbin/chkconfig --add karaf
>
> %preun
> # turn off Karaf and remove it from the init.d services before uninstalling
> if [ $1 = 0 ]; then
> /etc/init.d/karaf stop
> /sbin/chkconfig --del karaf
> fi
>
> %files
> %doc %{karaf_home}/karaf-manual-2.2.7.pdf
> %doc %{karaf_home}/karaf-manual-2.2.7.html
>
> # Karaf startup script (uses Tanuki wrapper)
> %attr(755, root, root) /etc/init.d/karaf
>
> # Karaf configuration
> %config(noreplace) %attr(775, root, karaf) %{karaf_config}
>
> # Karaf bundle cache, ActiveMQ data, etc. This is the real location of KARAF_DATA
> %attr(775, karaf, karaf) %{karaf_data}
>
> # Karaf hot deploy directory
> %attr(775, karaf, karaf) %{karaf_deploy}
>
> # Karaf logs
> %attr(775, karaf, karaf) %{karaf_logs}
>
> # Karaf startup libraries
> %attr(755, root, root) %{karaf_startuplib}
>
> # Karaf packaged Maven repo. Most of Karaf code is here, not in the startup libraries
> %attr(755, root, root) %{karaf_systemlib}
>
> # Full of symlinks to files above, plus demos, a README or two, etc.: this is treated as KARAF_HOME and KARAF_BASE
> # we have to leave it writeable by the karaf group in order for user karaf to create the Karaf lockfile
> # (which should eventually move to KARAF_DATA: see https://issues.apache.org/jira/browse/KARAF-579)
> %attr(775, root, karaf) %{karaf_home}
>
Re: Karaf RPMs - what options are out there?
Posted by "ajs6f@virginia.edu" <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, ajs6f@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 <tarball>" and it "just works". All that is required is that a file called <package>.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 <aj...@virginia.edu>
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%{karaf_data}/log
# Tanuki wrapper configuration
cp -v %{SOURCE1}/karaf-wrapper.conf $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf
# init.d script
cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf
# Java to support Wrapper operation
cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib}
%post
# install Karaf service (but don't activate)
/sbin/chkconfig --add karaf
%preun
# turn off Karaf and remove it from the init.d services before uninstalling
if [ $1 = 0 ]; then
/etc/init.d/karaf stop
/sbin/chkconfig --del karaf
fi
%files
%doc %{karaf_home}/karaf-manual-2.2.7.pdf
%doc %{karaf_home}/karaf-manual-2.2.7.html
# Karaf startup script (uses Tanuki wrapper)
%attr(755, root, root) /etc/init.d/karaf
# Karaf configuration
%config(noreplace) %attr(775, root, karaf) %{karaf_config}
# Karaf bundle cache, ActiveMQ data, etc. This is the real location of KARAF_DATA
%attr(775, karaf, karaf) %{karaf_data}
# Karaf hot deploy directory
%attr(775, karaf, karaf) %{karaf_deploy}
# Karaf logs
%attr(775, karaf, karaf) %{karaf_logs}
# Karaf startup libraries
%attr(755, root, root) %{karaf_startuplib}
# Karaf packaged Maven repo. Most of Karaf code is here, not in the startup libraries
%attr(755, root, root) %{karaf_systemlib}
# Full of symlinks to files above, plus demos, a README or two, etc.: this is treated as KARAF_HOME and KARAF_BASE
# we have to leave it writeable by the karaf group in order for user karaf to create the Karaf lockfile
# (which should eventually move to KARAF_DATA: see https://issues.apache.org/jira/browse/KARAF-579)
%attr(775, root, karaf) %{karaf_home}
Re: Karaf RPMs - what options are out there?
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Jan 2013, at 7:09 PM, ajs6f@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 <tarball>" and it "just works". All that is required is that a file called <package>.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
--
Re: Karaf RPMs - what options are out there?
Posted by "ajs6f@virginia.edu" <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, ajs6f@virginia.edu <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?
Posted by Andreas Pieber <an...@gmail.com>.
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, ajs6f@virginia.edu <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?
Posted by "ajs6f@virginia.edu" <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
> --
>