Reponses inline.
On Sat, Jul 31, 2010 at 7:43 AM, mabrek
<mabrek@xxxxxxxxx> wrote:
On 07/29/2010 10:51 PM, Joakim Erdfelt wrote:
> That is true.
> It does use an ant build to build things.
> This decision was made to satisfy the following ...
>
> 1) Upstream compatibility with Debian release process
> This means we can't rely on maven artifacts from central, only those
> present within the debian apt repositories.
> 2) Maximum compatibility between Debian and Redhat builds (redhat rpm
> has poor maven support as well)
These goals are difficult to achieve. I think that 'proper' debian packaging of java software is made nearly impossible by time gap between library appearance in maven central and in debian repositories (if it ever appears as .deb)
My goal is to create working jetty 7 package for our appications running on Ubuntu >= 9.10. Another goal is to maintain exactly the same set of libraries in production and in development environment (maven jetty plugin).
I made it and found quite inconvenient to patch a patch instead of using original .pom with maven deps. I want to use maven and download deps from central to build jetty package. It will decrease maintenance costs and save me from differences between debian packaged jars of 3rd party libs and maven deps.
No need to patch a patch. Generate a new one.
The patch used by the debian (and redhat) builds is built by a maven plugin from the information present in the system + exclusions found in the root of the build environment.
(You don't want to build things irrelevant to the debian and redhat packaging effort like the osgi pieces or the aggregates)
This process also picks up the customizations to the META-INF/MANIFEST.MF that exist in the patch you are (likely) referring to.
and its jetty-linux-packaging:generate-patch goal.
If you want to see a totally different approach, one that doesn't use a patch, but uses maven entirely, we are interested.
But instead of trying to make a patch, how about a whole new debian build branch?
Let those of us on the Jetty project with an interest in the Debian build see the 100% maven approach.
If it works out, I can see quite a bit of enthusiasm for this approach, and it showing up as the main approach.
(Historical note: we did try this approach, but the debbuild provided maven was woefully inadequate last time we tried)
I would be curious to see how you handle the splitup of the distribution directory into the linux server packaging defaults.
/usr/bin
/etc/jetty
/usr/lib/java/jetty
/var/log/jetty
/var/run/jetty
/var/jetty/webapps
etc ...
> (snip rant on awkwardness of servlet containers as root level servers in
> linux)
We have several applications packaged as WAR. Separate servlet container package saves us from maintaining init scripts and bootstrap code for every application.
Yet, know that the WARs are running at the same security context level as Jetty.
Which many sysadmins run as root when provided as a system server.
(snip dozen paragraph rant about how not running jetty as split linux server packaging is actually safer, easier, more stable, etc.
and realizing it could be cleaned up, tone changed, and used as a one of many counterpoints of jetty usage, rather than a
negative attack on 1 specific usage)
