You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "jon.mithe" <jo...@gmail.com> on 2010/11/09 14:14:33 UTC
Custom assembly of multi module project
Hi,
I'm trying to switch over to maven for a project I developing in work, new
to maven and finding packaging it a little tricky.
The app I am writing has a core framework module and then a bunch of other
modules that provide plugin like functionality. The idea being I can
produce different builds with different combinations of modules /
functionality. The confusing bit is each module specifies its own configs +
other config like resources and these must be aggregated together in the
build. So my project:
Parent Project
--Core Module
---- src/main/java
---- src/main/config
---- src/main/other_resource_directory
--Module A
---- src/main/java
---- src/main/config
---- src/main/other_resource_directory
--Module B
---- src/main/java
---- src/main/config
---- src/main/other_resource_directory
needs to go to the final package / zipped artifact:
./core.jar
./moduleA.jar
./moduleB.jar
./config/<all configs accross all modules>
./other_resource_directory/<all other resources accross all modules>
As I understand, I need to use the maven-assembly-plugin to do most of this,
and to include the custom directories I need.
I think I need to define each module artifact as a zip file with the target
jar in it and the 2 folders. Which involves writing an assembly plugin
instance in the plugin management of the parent POM and my own assembly
descriptor. The idea being I can reference the plugin as an artifact in
each of my sub modules, i.e:
<plugin><artifactId>module-bundle</artifactId></plugin>.
So I think that may work for each of my sub-modules, but I have no idea then
how to process these artifacts to aggregate this into a zip in the format
above. I think the artifact is I would get atm is a jar containing all the
zipped artifacts from each modules. So when that artifact is being created
I need to process the zips from the modules / unpackage each module and copy
configs across etc.
Talked to a friend who said maybe this is not quite within the maven way and
he suggested gradle may be worthwhile looking into but am quite interested
to know if this should be possible in maven.
Thanks for any help figuring this out,
Jon
--
View this message in context: http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256773.html
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: Custom assembly of multi module project
Posted by Kalpak Gadre <ka...@gmail.com>.
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<jo...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom assembly of multi module project
Posted by "jon.mithe" <jo...@gmail.com>.
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 <jo...@gmail.com> 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.
>
>
--
View this message in context: http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3262443.html
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: Custom assembly of multi module project
Posted by Jon Paynter <ki...@gmail.com>.
On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe <jo...@gmail.com> 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.
Re: Custom assembly of multi module project
Posted by "jon.mithe" <jo...@gmail.com>.
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.
Thanks,
Jon.
Ron Wheeler wrote:
>
> On 09/11/2010 9:03 AM, Anders Hammar wrote:
>> I think you should start by separating the configurations from your
>> binaries. Then it will be so much easier creating the custom zip you
>> want.
>> You would also avoid having the configuration files duplicated (like
>> outisde
>> the jars as well as inside some of the jars). That will sooner or later
>> get
>> you or someone else into trouble.
> +1 I have been a victim of this practice. Very unpleasant.
>> /Anders
>>
>> On Tue, Nov 9, 2010 at 14:14, jon.mithe<jo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to switch over to maven for a project I developing in work,
>>> new
>>> to maven and finding packaging it a little tricky.
>>>
>>> The app I am writing has a core framework module and then a bunch of
>>> other
>>> modules that provide plugin like functionality. The idea being I can
>>> produce different builds with different combinations of modules /
>>> functionality. The confusing bit is each module specifies its own
>>> configs
>>> +
>>> other config like resources and these must be aggregated together in the
>>> build. So my project:
>>>
>>> Parent Project
>>> --Core Module
>>> ---- src/main/java
>>> ---- src/main/config
>>> ---- src/main/other_resource_directory
>>> --Module A
>>> ---- src/main/java
>>> ---- src/main/config
>>> ---- src/main/other_resource_directory
>>> --Module B
>>> ---- src/main/java
>>> ---- src/main/config
>>> ---- src/main/other_resource_directory
>>>
>>> needs to go to the final package / zipped artifact:
>>>
>>> ./core.jar
>>> ./moduleA.jar
>>> ./moduleB.jar
>>> ./config/<all configs accross all modules>
>>> ./other_resource_directory/<all other resources accross all modules>
>>>
>>> As I understand, I need to use the maven-assembly-plugin to do most of
>>> this,
>>> and to include the custom directories I need.
>>>
>>> I think I need to define each module artifact as a zip file with the
>>> target
>>> jar in it and the 2 folders. Which involves writing an assembly plugin
>>> instance in the plugin management of the parent POM and my own assembly
>>> descriptor. The idea being I can reference the plugin as an artifact in
>>> each of my sub modules, i.e:
>>> <plugin><artifactId>module-bundle</artifactId></plugin>.
>>>
>>> So I think that may work for each of my sub-modules, but I have no idea
>>> then
>>> how to process these artifacts to aggregate this into a zip in the
>>> format
>>> above. I think the artifact is I would get atm is a jar containing all
>>> the
>>> zipped artifacts from each modules. So when that artifact is being
>>> created
>>> I need to process the zips from the modules / unpackage each module and
>>> copy
>>> configs across etc.
>>>
>>> Talked to a friend who said maybe this is not quite within the maven way
>>> and
>>> he suggested gradle may be worthwhile looking into but am quite
>>> interested
>>> to know if this should be possible in maven.
>>>
>>> Thanks for any help figuring this out,
>>> Jon
>>> --
>>> View this message in context:
>>> http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256773.html
>>> 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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3257165.html
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: Custom assembly of multi module project
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 09/11/2010 9:03 AM, Anders Hammar wrote:
> I think you should start by separating the configurations from your
> binaries. Then it will be so much easier creating the custom zip you want.
> You would also avoid having the configuration files duplicated (like outisde
> the jars as well as inside some of the jars). That will sooner or later get
> you or someone else into trouble.
+1 I have been a victim of this practice. Very unpleasant.
> /Anders
>
> On Tue, Nov 9, 2010 at 14:14, jon.mithe<jo...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm trying to switch over to maven for a project I developing in work, new
>> to maven and finding packaging it a little tricky.
>>
>> The app I am writing has a core framework module and then a bunch of other
>> modules that provide plugin like functionality. The idea being I can
>> produce different builds with different combinations of modules /
>> functionality. The confusing bit is each module specifies its own configs
>> +
>> other config like resources and these must be aggregated together in the
>> build. So my project:
>>
>> Parent Project
>> --Core Module
>> ---- src/main/java
>> ---- src/main/config
>> ---- src/main/other_resource_directory
>> --Module A
>> ---- src/main/java
>> ---- src/main/config
>> ---- src/main/other_resource_directory
>> --Module B
>> ---- src/main/java
>> ---- src/main/config
>> ---- src/main/other_resource_directory
>>
>> needs to go to the final package / zipped artifact:
>>
>> ./core.jar
>> ./moduleA.jar
>> ./moduleB.jar
>> ./config/<all configs accross all modules>
>> ./other_resource_directory/<all other resources accross all modules>
>>
>> As I understand, I need to use the maven-assembly-plugin to do most of
>> this,
>> and to include the custom directories I need.
>>
>> I think I need to define each module artifact as a zip file with the target
>> jar in it and the 2 folders. Which involves writing an assembly plugin
>> instance in the plugin management of the parent POM and my own assembly
>> descriptor. The idea being I can reference the plugin as an artifact in
>> each of my sub modules, i.e:
>> <plugin><artifactId>module-bundle</artifactId></plugin>.
>>
>> So I think that may work for each of my sub-modules, but I have no idea
>> then
>> how to process these artifacts to aggregate this into a zip in the format
>> above. I think the artifact is I would get atm is a jar containing all the
>> zipped artifacts from each modules. So when that artifact is being created
>> I need to process the zips from the modules / unpackage each module and
>> copy
>> configs across etc.
>>
>> Talked to a friend who said maybe this is not quite within the maven way
>> and
>> he suggested gradle may be worthwhile looking into but am quite interested
>> to know if this should be possible in maven.
>>
>> Thanks for any help figuring this out,
>> Jon
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256773.html
>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom assembly of multi module project
Posted by Anders Hammar <an...@hammar.net>.
Create a separate project for the config. In Maven, one project = one
artifact. Sure, you can create additional artifacts, but that's the golden
rule.
/Anders
On Tue, Nov 9, 2010 at 15:35, jon.mithe <jo...@gmail.com> wrote:
>
> Thanks for the reply. Yeah that is what I am trying to achieve. So there
> are no configuration files within the jars and I'm trying to keep the
> configs in the extra folder on the side. As far as I'm aware maven can
> only
> produce one artifact from the module during the build, so the only way I
> can
> see it will work would be some sort of zip/jar with all the complied jars
> inside + the extra config directories attached on the side.
>
> Trying to think of ways to simplify the build, but cant see any.
>
> Hmm.
>
> Thanks,
> Jon
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256929.html
> 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: Custom assembly of multi module project
Posted by "jon.mithe" <jo...@gmail.com>.
Thanks for the reply. Yeah that is what I am trying to achieve. So there
are no configuration files within the jars and I'm trying to keep the
configs in the extra folder on the side. As far as I'm aware maven can only
produce one artifact from the module during the build, so the only way I can
see it will work would be some sort of zip/jar with all the complied jars
inside + the extra config directories attached on the side.
Trying to think of ways to simplify the build, but cant see any.
Hmm.
Thanks,
Jon
--
View this message in context: http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256929.html
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: Custom assembly of multi module project
Posted by Anders Hammar <an...@hammar.net>.
I think you should start by separating the configurations from your
binaries. Then it will be so much easier creating the custom zip you want.
You would also avoid having the configuration files duplicated (like outisde
the jars as well as inside some of the jars). That will sooner or later get
you or someone else into trouble.
/Anders
On Tue, Nov 9, 2010 at 14:14, jon.mithe <jo...@gmail.com> wrote:
>
> Hi,
>
> I'm trying to switch over to maven for a project I developing in work, new
> to maven and finding packaging it a little tricky.
>
> The app I am writing has a core framework module and then a bunch of other
> modules that provide plugin like functionality. The idea being I can
> produce different builds with different combinations of modules /
> functionality. The confusing bit is each module specifies its own configs
> +
> other config like resources and these must be aggregated together in the
> build. So my project:
>
> Parent Project
> --Core Module
> ---- src/main/java
> ---- src/main/config
> ---- src/main/other_resource_directory
> --Module A
> ---- src/main/java
> ---- src/main/config
> ---- src/main/other_resource_directory
> --Module B
> ---- src/main/java
> ---- src/main/config
> ---- src/main/other_resource_directory
>
> needs to go to the final package / zipped artifact:
>
> ./core.jar
> ./moduleA.jar
> ./moduleB.jar
> ./config/<all configs accross all modules>
> ./other_resource_directory/<all other resources accross all modules>
>
> As I understand, I need to use the maven-assembly-plugin to do most of
> this,
> and to include the custom directories I need.
>
> I think I need to define each module artifact as a zip file with the target
> jar in it and the 2 folders. Which involves writing an assembly plugin
> instance in the plugin management of the parent POM and my own assembly
> descriptor. The idea being I can reference the plugin as an artifact in
> each of my sub modules, i.e:
> <plugin><artifactId>module-bundle</artifactId></plugin>.
>
> So I think that may work for each of my sub-modules, but I have no idea
> then
> how to process these artifacts to aggregate this into a zip in the format
> above. I think the artifact is I would get atm is a jar containing all the
> zipped artifacts from each modules. So when that artifact is being created
> I need to process the zips from the modules / unpackage each module and
> copy
> configs across etc.
>
> Talked to a friend who said maybe this is not quite within the maven way
> and
> he suggested gradle may be worthwhile looking into but am quite interested
> to know if this should be possible in maven.
>
> Thanks for any help figuring this out,
> Jon
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256773.html
> 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
>
>