2

I've created an Java application and I would like to create an installation RPM for it. The application consists of a set of jar files, a system library file, a script to launch the application, and a directory to store user configuration information. The installation structure I'm trying to achieve looks like this:

/usr/local/[appname]
  /jar
    *.jar
  /lib
    *.so
  /etc
     [future home of user.properties]
  launch.sh

Most of the information I've studied for .spec files and RPM in general, revolves around using make to configure and install an application. I haven't found any good information on packaging Java applications. Currently, my build system arranges all the files into the above structure, copies it to the BUILD directory and the spec file just dumps it. That works but I've found in testing that there are several directives that I need to include for the %files section and I generally feel like I'm having to be more specific than I should for an automated build process.

Is there a correct (or best) way to package a Java applications for RPM?.

OttPrime
  • 1,878
  • 1
  • 15
  • 24
  • 1
    There's an rpm-plugin for maven that works like a charm. RPM doesn't care what you put in it, so "non-compiled" applications doesn't make sense. – Kayaman Jul 16 '14 at 21:24
  • Needing to list files specifically in the `%files` section is correct though if you own that entire hierarchy then a single entry for the toplevel `/usr/local/[appname]` directory might be enough by itself. Packages installing into `/usr/local` is a little odd though. – Etan Reisner Jul 16 '14 at 22:57
  • @Kayaman I'm currently using Ant for my Java builds but I'll look into Maven. I also edited my question to be more specific toward Java. What I meant by "non-compiled" was a non-source RPM that isn't using `make` to be compiled and installed, but that's still a bit ambiguous. – OttPrime Jul 17 '14 at 12:11
  • @EtanReisner, it's not uncommon or odd to package things into `/usr/local`. Though some distributions prefer `/opt` over `/usr/local/` for this purpose, on almost all distros, `/usr/local` is for local builds, not for distribution-provided packages, so it's perfectly fine to put your own, local stuff there, especially if you are concerned about conflicting with official packages. – jayhendren Jul 28 '14 at 22:35
  • @jayhendren There's little reason to use `/usr/local` for "local stuff" if you are building packages to install them. The reason for using `/usr/local` is to not stomp over distribution stuff when manually installing things and to potentially allow for easy/easier removal of the manually installed files (without worrying about gutting system installed stuff). Neither of those things is a concern when packaging and installing an RPM though. It is definitely perfectly fine to do it is just also slightly odd in my experience. – Etan Reisner Jul 29 '14 at 02:07
  • @EtanReisner "Neither of those things is a concern when packaging and installing an RPM though." Of course they can be. At my company, we build packages that conflict with official Red Hat packages, but we can't remove the Red Hat packages either because many things depend on them. So we build packages to install to `/usr/local` when this is the case. `/opt` works too, but for historical reasons we use `/usr/local` instead. – jayhendren Jul 29 '14 at 17:55
  • @jayhendren I meant concern in the overwrite/destroy/conflict sense not the "cannot duplicate" sense. And packaging alternate versions of already packaged software is a special case of packaging in general (especially with the recent addition of the official `SCL`s). – Etan Reisner Jul 29 '14 at 18:10

0 Answers0