You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Barrie Treloar <ba...@gmail.com> on 2007/01/15 04:35:03 UTC
Recommended way to add "config" files?
For files like log4j and EasyConf, I don't want them buried in the jar
file as this makes it difficult to edit the files. I'd like them on
disk and for the jar file to include the directory on the classpath so
that the files can be located without worrying about file paths.
What I have been doing is described below, which works great when you
assembly the binary distribution and run that version. It's not so
great when you are trying to work inside an IDE as the files in
src/main/config aren't on the classpath (whether they should be is
another question, as these files are likely production ready and in
the IDE you probably want "test" versions), for testing I have been
included a copy of these files in src/test/resources.
I'm not happy with the duplication when the files will be identical.
I'm not happy manually changing the classpath as I'd like
eclipse:eclipse to do the right thing.
Has anyone else thought about this scenario and what do they do?
Cheers
Barrie
My files:
src/main/config
- log4j.properties
- <app>.properties (for EasyConf)
In my pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Class-Path>config/</Class-Path>
</manifestEntries>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>assembly:package</id>
<phase>package</phase>
<goals>
<!--
Work around for http://jira.codehaus.org/browse/MASSEMBLY-97
-->
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>src/main/assembly/bin.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
src/main/assembly/bin.xml:
copies the files into the correct directory structure expected for running via
java -jar <app>.jar
e.g
<fileSets>
<fileSet>
<directory>src/main/config</directory>
<outputDirectory>config/</outputDirectory>
<includes>
<include>*</include>
</includes>
<excludes>
<exclude>CVS</exclude>
</excludes>
</fileSet>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Recommended way to add "config" files?
Posted by "John J. Franey" <jj...@verizon.net>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommended way to add "config" files?
Posted by Rahul Thakur <ra...@gmail.com>.
I haven't used the assembly plugin but we have a similar scenario
addressed like this:
1) for Eclipse we have resources with hard-coded values. This works
well for running the app or tests from within IDE.
2) for packaging up using Maven, we use a combination of profiles and
filters to 'patch' configuration resources with values for target env.
I'd be keen if there is a better solution :-)
Cheers,
Rahul
----- Original Message -----
From: "Barrie Treloar" <ba...@gmail.com>
To: "Maven Users List" <us...@maven.apache.org>
Sent: Monday, January 15, 2007 4:35 PM
Subject: Recommended way to add "config" files?
> For files like log4j and EasyConf, I don't want them buried in the jar
> file as this makes it difficult to edit the files. I'd like them on
> disk and for the jar file to include the directory on the classpath so
> that the files can be located without worrying about file paths.
>
> What I have been doing is described below, which works great when you
> assembly the binary distribution and run that version. It's not so
> great when you are trying to work inside an IDE as the files in
> src/main/config aren't on the classpath (whether they should be is
> another question, as these files are likely production ready and in
> the IDE you probably want "test" versions), for testing I have been
> included a copy of these files in src/test/resources.
>
> I'm not happy with the duplication when the files will be identical.
> I'm not happy manually changing the classpath as I'd like
> eclipse:eclipse to do the right thing.
>
> Has anyone else thought about this scenario and what do they do?
>
> Cheers
> Barrie
>
> My files:
>
> src/main/config
> - log4j.properties
> - <app>.properties (for EasyConf)
>
> In my pom.xml:
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <configuration>
> <archive>
> <manifestEntries>
> <Class-Path>config/</Class-Path>
> </manifestEntries>
> <manifest>
> <addClasspath>true</addClasspath>
> <classpathPrefix>lib/</classpathPrefix>
> </manifest>
> </archive>
> </configuration>
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <executions>
> <execution>
> <id>assembly:package</id>
> <phase>package</phase>
> <goals>
> <!--
> Work around for
> http://jira.codehaus.org/browse/MASSEMBLY-97
> -->
> <goal>single</goal>
> </goals>
> <configuration>
> <descriptors>
> <descriptor>src/main/assembly/bin.xml</descriptor>
> </descriptors>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> src/main/assembly/bin.xml:
> copies the files into the correct directory structure expected for
> running via
> java -jar <app>.jar
> e.g
> <fileSets>
> <fileSet>
> <directory>src/main/config</directory>
> <outputDirectory>config/</outputDirectory>
> <includes>
> <include>*</include>
> </includes>
> <excludes>
> <exclude>CVS</exclude>
> </excludes>
> </fileSet>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org