Hi Fabian,
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.
[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
Cheers,
Henrique
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 : Fri Apr 13 2007 - 11:41:38 EDT