I have got around including config files form modules into an assembly
using repository. I have configured build-helper-maven-plugin to install
the configuration files into repository. The installed config files need
a special classifier to distinguish it from the jar itself. The assembly
module can add the config file as dependency by specifying the
classifier and filetype and then can copy these files wherever required.
Only thing you have to make sure is that to build locally you have to
use mvn install instead of mvn package.
Installing configuration files into repository as artifact is not the
nicest thing to do, but it works.
- Kalpak
Thanks again for all your help, although I've come up with a slightly
different solution. Was not comfortable splitting the config + jars up,
especially as I am going to have a minimum of 20 odd modules in this project
(its fairly large / diverse).
So if anyone is interested / has this problem this is what I did:
I used the src/main/resources folder of each module. In there I have created
3 folders mpApp-root, myApp-config, myApp-otherConfig (well, not those exact
names). Each module / artifact is a jar. with that inside, e.g:
Parent
--ModuleA
----src/main/java
----src/main/resources
------src/main/resources/myApp-config
------src/main/resources/myApp-otherConfig
------src/main/resources/myApp-root
--ModuleB
----src/main/java
----src/main/resources
------src/main/resources/myApp-config
------src/main/resources/myApp-otherConfig
------src/main/resources/myApp-root
I created another module (myApp-dist) and made it depend on all other
modules I want to distribute in my test build (eventually this will probably
be a separate project). Its the pom in this module I define my overall
build.
The build defines 3 custom assemblies:
1. uses dependencySet with exclude "myApp-*/**" to jar up all dependencies
into a monster jar. i.e. I get just a jar of all classes without special
resource folders.
2. uses dependencySet with include "myApp-*/**" to just includes the myApp-*
special folders, this assemble outputs to format "dir".
3. Defines filesets to include in a tar.gz. So the main dist jar created by
the 1st assembler and then all the special folders. The cool thing is you
can define the output directory so myApp-root contents goes to ./,
myApp-config goes ./config etc.
The result is along the lines of a tar.gz with contents:
./myApp-version/config
./myApp-version/otherConfig
./myApp-version/artifact-version-dist.jar
./some.properties
./readme.txt
Sucks a little creating special folders that do magic things in the build
but its not too bad. One odd little side effect is putting a - in the
resource folder name means it cant be used as a java package... handy to
ensure some random java package does not clash with a special folder and
accidentally get its .class excluded from the dist jar.
Also to get this building and packaging locally, mvn install is quite a
useful command :P
Tried gradle, think it had the potential to suit my build better but
ultimately using it with eclipse, defining new modules etc, it was clunky.
Cheers,
Jon
Jon Paynter wrote:
On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe<[email protected]> wrote:
Interesting. I think I have found some unpacking elements in the
assembly
plugin when I write my own descriptor. So it may be possible... needs
more
research.
I think I understand what you are saying about separating the config from
the binaries. But I'm not sold on the idea of creating it in a different
project. The way I'm trying to do it, the code + the config is
completely
separate, i.e. its not jar'ed with the classes and I do not have any
issues
with duplication. The code and the config is a tightly linked enitity so
I
feel uneasy about splitting them into 2 separate projects (albeit linked
by
a dependency).
What concerns me most is I feel that doing it this way would be a work
around for the way maven builds, i.e. I'm starting to think my project
does
not seem to fit nicely with maven way of doing things :/
Thanks again for all you help, I'm not giving up on maven yet but I think
I
need to take a more in depth look at gradle and see if it fits this any
better.
I recently finished solving a very simmilar problem. with trying to
package
things. Before conversion to maven, the structure looked like this (yes
its
using ant)
Parent Project
--Common configs
--Module A
---- moduleA.jar
---- moduleA.ear
---- moduleA.war
---- src/config
---- build.xml
--Module B
---- moduleB.jar
---- moduleB.ear
---- moduleB.war
---- src/config
---- build.xml
/dist/ModuleA/ModuleA.ear
/dist/ModuleA/config/
/dist/ModuleB/ModuleB.ear
/dist/ModuleB/config/
Once all the dust settled, I ended up with a structure like this:
Parent Project
--Common Configs
----src/main/other_resource_directory
--Module A
----src/main/config
----ModuleA_jar
-------src/main/java
----ModuleA_war
-------src/main/webapp
----ModuleA_ear
-------src/main/META-INF
----ModuleA_Package
-------src/main/assembly
-------target/ModuleA.zip
--Module B
----src/main/config
----ModuleB_jar
-------src/main/java
----ModuleB_war
-------src/main/webapp
----ModuleB_ear
-------src/main/META-INF
----ModuleB_Package
-------src/main/assembly
-------target/ModuleB.zip
Packaging_project
---target/dist/ModuleA/ModuleA.ear
---target/dist/ModuleA/config/
---target/dist/ModuleB/ModuleB.ear
---target/dist/ModuleB/config/
The key here was first to seperate things out so each project produces
exactly one _binary_ artifact. Then to seperate the packaging/assembly
from
the compiling.
In moduleA_package and moduleB_package, the resulting zip file is marked
as
attached, so it gets stored in the repository.
the packaging_project then depends on only whats needed to distribute -
which is just the zip file. The zip file is unpacked into its proper
directory.
the moduleA_package and moduleB_package are assemblies that do filtering
and
copying of the config files. its not a very elagant solution to the
common
configs, but it does work.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
