Since yours is a recent post and sounds related to something I'm just
finishing off, I'll post here what I have done. Maybe its useful to you or
somebody.
What I wanted to do was create an archive containing my custom pieces
overlaid into publicly available distribution. Specifically, I want to
pepper a jboss distribution server/default directory with my custom
libraries and configuration files, and wrap the thing into a single zip.
Then my customer could unzip my custom jboss server into his
jboss-home/server directory and fire it up.
Here is the flow:
1) copy down a clean jboss installation into target/jboss
2) assemble the following into a single archive
a) default server (a subdirectory) from jboss distribution
b) dependencies of the project
c) filtered configuration files
Step 1: copy down a clean jboss
This was done using the cargo plugin. I configured it to run in package
phase. I believe I can reuse this configuration in some way when I setup
for integration tests. I sure wish the destination directory was available
as a parameter to the assemble descriptor (used later); for now, I hardwire
'target/jboss-3.n.n/jboss-3.n.n' in the assembly descriptor.
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>0.3-SNAPSHOT</version>
<configuration>
<container>
<containerId>jboss3x</containerId>
<zipUrlInstaller>
<url>file:////home/jfraney/jboss-3.2.6.zip</url>
<installDir>target</installDir>
</zipUrlInstaller>
</container>
</configuration>
<executions>
<execution>
<!-- cargo will download jboss dist prior to assembly -->
<id>download</id>
<phase>package</phase>
<goals>
<goal>install</goal>
</goals>
</execution>
</executions>
</plugin>
2a) assemble default server from jboss distribution
This is the first fileSet in my assembly descriptor and it assembles the
default server directory. The thorn on this is that any config files which
we customize must be excluded in this fileSet because, as I've observed, if
a file of the same name is assembled more than once, the version I don't
want is selected. In other words, without the exclusion, the stock
configuration files, not my customizations, will be selected by the assembly
plugin.
<fileSet>
<!-- server/custom is based from jboss' server/default -->
<directory>target/jboss-3.2.6/jboss-3.2.6/server/default</directory>
<outputDirectory>custom</outputDirectory>
<excludes>
<!-- we customize the following, so exclude them here -->
<exclude>**/deploy/properties-service.xml</exclude>
<exclude>**/deploy/jms/jbossmq-destinations-service.xml</exclude>
<!-- elided -->
</excludes>
</fileSet>
We also wanted to copy some jboss cabability that is in the 'all' server but
not the 'default' server. In this case, snmp-adaptor. Here are the next
fileSets for this:
<fileSet>
<!-- server/custom also jboss' snmp-adaptor.sar -->
<directory>target/jboss-3.2.6/jboss-3.2.6/server/all/deploy/snmp-adaptor.sar</directory>
<outputDirectory>custom/deploy/snmp-adaptor.sar</outputDirectory>
</fileSet>
<fileSet>
<!-- server/custom also jboss' snmp-adaptor.jar -->
<directory>target/jboss-3.2.6/jboss-3.2.6/server/all/lib</directory>
<outputDirectory>custom/lib</outputDirectory>
<includes>
<include>snmp-adaptor.jar</include>
</includes>
</fileSet>
At this point, we have a 'barebones' jboss server based on 'default' server.
We are ready to assemble in some customization files and archives.
2b) assemble archive dependencies of the project
This is straightforward with dependencySets, here is an example of one:
<dependencySet>
<unpack>false</unpack>
<outputDirectory>custom/lib</outputDirectory>
<includes>
<include>com.microsoft:jdbc-microsoft</include>
</includes>
</dependencySet>
2c) assemble configuration files
In my observation, filtering fileSet does NOT work. The assembly plugin
will only filter 'file' elements in the descriptor. So, assemblying config
files were broken into two parts: assembling non-filtered files as a
fileSet, and assembling filtered files one at a time in a files element. As
with step one, with these separated steps, care must be taken to exclude any
file in the first fileSet that may be filtered in later file elements. Here
is a sample fileSet and file, jboss.config.in.dir is directory under src
that contains configuration files with directory structure acceptable to
jboss.
<fileSet>
<directory>${jboss.config.in.dir}</directory>
<outputDirectory>custom</outputDirectory>
<excludes>
<!-- These are filtered (see below) -->
<exclude>deploy/custom-config-A.xml</exclude>
<exclude>deploy/http-invoker.sar/META-INF/jboss-service.xml</exclude>
<!-- elided -->
</excludes>
</fileSet>
Now a sample of filtering a file:
<file>
<!-- copy and filter this config file -->
<source>${jboss.config.in.dir}/deploy/custom-config-A.xml</source>
<filtered>true</filtered>
<outputDirectory>custom/deploy</outputDirectory>
</file>
Looking back, I think I can make this easier using components. For example,
creating the barebones jboss could be done in a component, I think.
The nuisances I had are:
1) Filtering fileSets didn't work for me. This would eliminate the need to
enumerate all filterable configuration files. In fact, the entirety of all
custom config files could be done in the single fell swoop of one fileSet.
2) I wish I knew the algorithm the assembly plugin uses for selecting a file
of the same destination name. A quick example is a 'fileSet' puts a
config.xml in outputDirectory conf, and a 'file' puts a different config.xml
into the same outputDirectory conf. I think then I could leverage the
algorithm so I don't have to edit the assembly descriptor in three places to
add a new file to be filtered.
3) I wish cargo would give me a project parameter that points to the
directory location which is unziped the jboss distribution. I would prefer
to use the parameter instead of hardwiring the directory.
Regards,
John
--
View this message in context:
http://www.nabble.com/Recommended-way-to-add-%22config%22-files--tf3012459s177.html#a8973610
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
