If he puts it there then won't it go into the war file, which I thought he
didn't want? I suppose you could add an exclude to the resource section in
the pom.
In my parent project I have src/assemblies and src/main/scripts. I'm building
a zip file that contains a jar file that includes a class with main and all of
the jars it depends on. I'm using the assembly plugin to make a script that
unzips the zip file and automates everything for our production control people
for installing it on the server (it's a cron job). The assembly plugin also
makes two other scripts run by cron. The jars with main are a dependency of
the parent project.
The deploy script starts out as follows; you can see what's being filtered by
maven:
#!/bin/sh
set -e
set -u
PATH=/usr/local/bin:${PATH}
export PATH
REL=${project.version}
LAYER=${layer}
SVNURL=${svn.url}
APP=${project.artifactId}
if test -d cars_runner
then
true ; # already exists
else
echo "creating cars_runner directory"
mkdir cars_runner
fi
echo "cding into cars_runner directory"
cd cars_runner
if test -f ${APP}-${REL}-${LAYER}-both.zip
then
echo "removing previous zip file"
rm ${APP}-${REL}-${LAYER}-both.zip
fi
echo "checking out zip file from subversion"
/opt/csw/bin/svn export ${SVNURL}/deploy/${APP}-${REL}-${LAYER}-both.zip
The assembly descriptor for the deploy script is
<assembly>
<id>deploy-script</id>
<formats>
<format>dir</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<files>
<file>
<source>src/main/scripts/deploy.sh</source>
<destName>deploy-${project.layer}.sh</destName>
<filtered>true</filtered>
<lineEnding>unix</lineEnding>
</file>
</files>
</assembly>
Although I'm hardly a role model to be emulated because I just noticed that the scripts
that cron runs are in src/stuff/scripts. When I get stuck trying to come up with a
meaningful name it seems like "stuff" is the best I can do. Even worse, the
crontab file is in src/stuff/notes. Nevertheless, warts and all, here's the assembly
file that makes the zip:
<?xml version="1.0" encoding="UTF-8"?>
<assembly>
<id>${project.layer}-both</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<baseDirectory>/</baseDirectory>
<moduleSets>
<moduleSet>
<includes>
<include>edu.berkeley.ist.cars:cars_upload</include>
</includes>
<binaries>
<unpack>false</unpack>
<useStrictFiltering>true</useStrictFiltering>
<includeDependencies>true</includeDependencies>
<outputDirectory>upload</outputDirectory>
</binaries>
</moduleSet>
<moduleSet>
<includes>
<include>edu.berkeley.ist.cars:cars_download</include>
</includes>
<binaries>
<unpack>false</unpack>
<useStrictFiltering>true</useStrictFiltering>
<includeDependencies>true</includeDependencies>
<outputDirectory>download</outputDirectory>
</binaries>
</moduleSet>
</moduleSets>
<!--
crontab.txt is put in twice, in both upload and download, just in case.
-->
<files>
<!-- upload files -->
<file>
<source>src/stuff/scripts/cars_upload.sh</source>
<lineEnding>unix</lineEnding>
<filtered>true</filtered>
<outputDirectory>upload</outputDirectory>
</file>
<file>
<source>src/stuff/notes/crontab-${project.layer}.txt</source>
<destName>crontab.txt</destName>
<lineEnding>unix</lineEnding>
<filtered>true</filtered>
<outputDirectory>upload</outputDirectory>
</file>
<!-- download files -->
<file>
<source>src/stuff/scripts/cars_download.sh</source>
<lineEnding>unix</lineEnding>
<filtered>true</filtered>
<outputDirectory>download</outputDirectory>
</file>
<file>
<source>src/stuff/notes/crontab-${project.layer}.txt</source>
<destName>crontab.txt</destName>
<lineEnding>unix</lineEnding>
<filtered>true</filtered>
<outputDirectory>download</outputDirectory>
</file>
</files>
</assembly>
And for some reason I have a filter.properties file containing:
layer=${pom.layer}
svnurl=${pom.developerConnection}
I can't imagine that developerConnection is the right thing to use for that
but, whatever, it was a newbie project of mine. And I think perhaps I should
be using ${project instead of ${pom?
Mick Knutson wrote:
I would use ./src/main/resources/scripts
---
Thank You…
Mick Knutson, President
BASE Logic, Inc.
Enterprise Architecture, Design, Mentoring & Agile Consulting
p. (866) BLiNC-411: (254-6241-1)
f. (415) 685-4233
Website: http://baselogic.com
Linked IN: http://linkedin.com/in/mickknutson
Twitter: http://twitter.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com
---
On Wed, Feb 25, 2009 at 3:52 PM, Steve Cohen <[email protected]> wrote:
What is the general Maven view on where resources like launcher shell
scripts and properties files belong vis-a-vis Maven and Eclipse?
Our application is structurally a web app although it is not primarily
served over the Web. It runs under Tomcat, so that a minor use case,
implemented in terms of servlets, can be handled, although the bulk of
interactions with the application do not come through http. Because of
this, we make little distinction between the Web Application and Tomcat
itself. No other web apps run on this Tomcat instance and we start and stop
it by starting and stopping Tomcat, using a commons-daemon shell script, so
that the application restarts whenever the server might be rebooted, and so
it can also be started and stopped manually. Many configuration parameters
and system properties essential for running this application are defined in
this script, as well as a mechanism that determines which configuration to
launch (dev, test, production) based on the uname of the server. Thus there
is one launch script that works on all tiers.
This shell script should live, in the Maven/Eclipse view, where? Presently
it lives in the Web App project in a non-standard directory that does not
get deployed inside the war file that is generated from the Web App project.
It lives there for conceptual reasons, although its route to deployment is
entirely different and manual. Surely, where it lives is not the right
place, but what is? In a separate Eclipse/Maven project?
A similar question arises with properties files. They are deployed outside
the war, but need to get deployed manually to directories known by code in
the war.
Is there a "maven way" to handle such chicken-egg anomalies?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
