Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of cnauroth@hortonworks.com
 designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50AD8619.6030405@filez.com>
References: 
 <CA+z3+9EGLAyJb-+mpBSrGOczVGVEU6rtg=D=zJ6sFiMMuwFObw@mail.gmail.com>
	<CAJs-t7PE2PhBCkAO1=JmxJCLsyAF3r6q+zJ3Uu4UNfv1Gaq4gw@mail.gmail.com>
	<20121121200006.GX27475@tpx>
	<CABCYYb-=RWswSo6ncwazjVUEWEF-iCdQ4mr6tdtE6Hvua_R3Bg@mail.gmail.com>
	<50AD47E6.1030606@filez.com>
	<CABCYYb8PQitjiU_RVuD2SpbdjrS--6ocJLgTMgyy_OiF65zt4w@mail.gmail.com>
	<50AD607C.1010801@filez.com>
	<CABCYYb_z+a3Wa40d8ZEuc=pqqSch6uZudwqhP-aT_h8HiXLThQ@mail.gmail.com>
	<50AD8619.6030405@filez.com>
Date: Wed, 21 Nov 2012 18:40:08 -0800
Message-ID: 
 <CABCYYb-1hQ5fi3CQFMXFWEdxAh2zZo=h_Rn+4w_rZZguJXE5aA@mail.gmail.com>
Subject: Re: [PROPOSAL] introduce Python as build-time and run-time dependency
 for Hadoop and throughout Hadoop stack
From: Chris Nauroth <cnauroth@hortonworks.com>
To: common-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=f46d043c823cac71ac04cf0c623d

--f46d043c823cac71ac04cf0c623d
Content-Type: text/plain; charset=ISO-8859-1

This predates me, so I don't know the rationale for repackaging Tomcat
inside HTTPFS.  I suspect that there was a desire to create a fully
stand-alone distribution package, including a full web server.  The Maven
Jetty plugin isn't directly applicable to this use case.  I don't know why
it was decided to use Tomcat instead of Jetty.  (If anyone else out there
has the background, please respond.)  Regardless, if the desire is to
package a full web server instead of just the war, then switching to Jetty
would not change the challenges of the build process.  We'd still need to
preserve whatever permissions are present in the Jetty distribution.

In general, when I was working on this, I did not question whether the
current packaging was "correct".  I assumed that whatever changes I made
for Windows compatibility must yield the exact same distribution without
changes on currently supported platforms like Linux.  If there are
questions around actually changing the output of the build process, then
that will steer the conversation in another direction and increase the
scope of this effort.

It seems like the trickiest issue is preservation of permissions and
symlinks in tar files.  I suspect that any JVM-based solution like custom
Maven plugins, Groovy, or jtar would be limited in this respect.  According
to Ant documentation, it's a JDK limitation, so I suspect all of these
would have the same problem.  I haven't tried any of them though.  (If
there was a feasible solution, then Ant likely would have incorporated it
long ago.)  If anyone wants to try though, we might learn something from
that.

Thank you,
--Chris


On Wed, Nov 21, 2012 at 5:55 PM, Radim Kolar <hsn@filez.com> wrote:

> Dne 22.11.2012 1:14, Chris Nauroth napsal(a):
>
>  The trickiest maintenance issue is hadoop-hdfs-httpfs, where we unpack
>> and repack a Tomcat.
>>
> why its not possible to just ship WAR file? Its seems to be special
> purpose app and they needs hand security setup anyway and intergration with
> existing firewall/web infrastructure.
>
> did you considered to use Jetty? it has really good maven support:
> http://wiki.eclipse.org/Jetty/**Feature/Jetty_Maven_Plugin<http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin>
> I am using jetty 8 instead of tomcat and run it with java -jar start.jar
> no extra file permissions like x bit are needed.
>
> If you really need to create tar by hand, there is java library for doing
> it - http://code.google.com/p/jtar/ and it can be used from any JVM based
> script language, you have plenty of choices.
>

--f46d043c823cac71ac04cf0c623d--