Re: [jetty-users] What is the current status of 7.1.x debian packaging?

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

fwiw, I'll have deb and rpm releases next week and we should be able
to maintain a tighter release schedule with them from here on out

cheers
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Sat, Jul 31, 2010 at 11:53, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> 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.
> See http://svn.codehaus.org/jetty-contrib/packaging/tools/trunk/jetty-linux-packaging-maven-plugin/
> 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)
>
> - Joakim
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>