Re: [maven] MyApp.woapplication.tar.gz not preserving executable file mode

From: Fabian Peters (lists.fabia..-lumo.com)
Date: Sat Apr 14 2007 - 08:27:35 EDT

  • Next message: Gavin Eadie: "Re: [maven] MyApp.woapplication.tar.gz not preserving executable file mode"

    Hi Henrique,

    Am 13.04.2007 um 17:41 schrieb Henrique Prange:

    > We are doing exactly the same as you right now. Of course it is not
    > good because requires manual and error prone tasks.
    >
    > We need some kind of "mvn wolifecycle:deploy" or "mvn java-
    > monitor:deploy" to do what you are saying. I'm exploring Maven
    > Tomcat Plug-in [1] to realize how we could do something similar for
    > JavaMonitor.
    >
    > I think it is a TODO for maven-wolifecycle-plugin and you should
    > request an improvement on Jira.
    >
    > On the subject of deploy on remote server, you can use SSH or FTP.
    > See [2][3] for instructions. I have not tried, but I believe it
    > works. Anyway, it only puts your MyApp.woapplication.tar.gz into
    > another server repository and will not solve unzip and change
    > permissions problem.

    My current concern lies only with the fact that the generated
    application archive does not preserve the permissions as it should -
    which makes it impossible to deploy an app by just downloading the
    archive from the maven repo and unpacking it. If this issue could be
    solved, I'd be happy for now.

    However, I wasn't even able to see how the .tar file is created: Is
    it handled by <http://fisheye.codehaus.org/browse/~raw,r=4573/plexus/
    plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/
    plexus/archiver/tar/TarArchiver.java>? Or is maven using a tar binary
    installed on the system? There seems to be a property
    "maven.site.tar.executable" which suggests that the latter is true,
    but then why on earth do the permissions vanish? And where is this
    setting taken up? I spent some time grepping maven sources but to no
    avail.

    In a next step it would certainly be cool to have a possibility to
    deploy apps into a JavaMonitor setup. I read a bit on the tomcat
    plugin and cargo. Christian Pekeler's JavaMonitor patch might be a
    prerequisite for doing this kind of thing with JavaMonitor: <http://
    pekeler.org/software/MonitorPatch/> I'd mainly want to use this to
    completely automate integration testing.

    > [1]http://mojo.codehaus.org/tomcat-maven-plugin/introduction.html
    > [2]http://maven.apache.org/plugins/maven-deploy-plugin/examples/
    > deploy-ssh-external.html
    > [3]http://maven.apache.org/plugins/maven-deploy-plugin/examples/
    > deploy-ftp.html

    In my current setup, I'd grab the app from the maven repository by
    using curl and tar on the deployment server. This works perfectly
    fine, except for the glitch with the permissions...

    cheers,

    Fabian

    > Fabian Peters wrote:
    >> Hi Kieran,
    >> Thanks for your reply.
    >> Am 12.04.2007 um 18:50 schrieb Kieran Kelleher:
    >>> Why not just set permissions and ownership in your deployment
    >>> script? I use bash scripts for deployment and the enabler is my
    >>> machine root user having authorized ssh key access to root on the
    >>> deployment servers. Hence with a script I can build, rename, copy
    >>> to remote, set owner/permissions on remote. When that's all done
    >>> I go into Monitor and change config to new named woa for new
    >>> instances, launch a new instance and refuse sessions on old
    >>> instance.
    >>>
    >>> For example on a project called omega, the dist that is built
    >>> locally on my machine is automatically named to sth like
    >>> omega_20070412_1415.woa before copying to appserver (that's
    >>> project_YYYYMMDD_HHMM.woa). Just change config to select the
    >>> omega executable inside that after the deployment is done.
    >> Well, yes, I have - and still do use, for now - a similar setup.
    >> But with a rising number of projects and dependencies, the various
    >> ant builds have started to be rather hard to maintain and error
    >> prone. So, I took some time and had a thorough look at maven,
    >> which fits the bill for me. Builds that have passed all tests and
    >> that I want to deploy are stored in a maven repo as a tgz archive,
    >> named in a similar fashion like you pointed out above. Checkout
    >> from svn, building, packaging, testing, deploying to the maven
    >> repository etc., is all handled by maven/continuum. In principle,
    >> all I have to do now is use curl and tar to place the app in the
    >> right place and do my work in Monitor. I really don't want to set
    >> up new build scripts for each different project, just to "chmod
    >> +x" the files that need to be executable (I have projects which
    >> have several such files).
    >> What I'm looking for is a solution in the maven realm, which I
    >> reckon should be simple enough. I'm just not really sure whether
    >> this is an issue with the wolifecycle maven plugin or rooted at
    >> some higher level.
    >> Fabian
    >>> On Apr 12, 2007, at 12:19 PM, Fabian Peters wrote:
    >>>
    >>>> Hi,
    >>>>
    >>>> I looked into using maven-generated archives for actual
    >>>> deployment. I'd like to pull the packaged build from an internal
    >>>> maven repository on the build server, unpack it and then
    >>>> gracefully restart the app via JavaMonitor.
    >>>> However, all files (not directories...) get mode 0644 when
    >>>> unpacking the archive. Is this intended? Can it be changed? I
    >>>> could of course make the files in question executable after
    >>>> extraction, but I'd much prefer not having to this.
    >>>>
    >>>> How do others proceed with deployment? Do you build locally on
    >>>> the app-server machine?
    >>>>
    >>>> cheers
    >>>>
    >>>> Fabian
    >>>
    >
    > --
    >
    > \o/ Henrique Prange, Moleque de Idéias Educação e Tecnologia Ltda
    > | Phone: 55-21-2710-0178 E-mail: hprang..oleque.com.br
    > / \ http://www.moleque.com.br



    This archive was generated by hypermail 2.0.0 : Sat Apr 14 2007 - 08:28:00 EDT