0

I'm trying to create an assembly for a large (over 100 modules) multi-module Maven project.

Some, but not all, modules have various files that need to be included in the final assembly but I am having difficulty figuring out how to get them there.

Here's the layout of a typical module:

+- pom.xml
+- src
|  +- main
|     +- java
|        +- ...
|     +- resources
|        +- ...
|     +- scripts
|        +- ...

This module has JAR packaging so the primary artifact is a JAR file.

Here's the desired format of the final assembly:

+- bin
|  +- <union of all files from src/main/scripts in the various modules>
+- lib
|  +- <union of all JAR files produced by the various modules>

I know how to do the lib part of the assembly structure but I have no idea how to accomplish the bin part.

This blog post seems to suggest that each module should be creating its own assembly (essentially an assembly fragment) which would all then be aggregated together by my actual assembly component.

Is that the way this is done in Maven? It seems awfully heavyweight & slow. Is there a different/better way?

Before answering, please bear in mind the following facts:

  1. This project is using a flat module structure (if that matters). Changing to a nested structure is not an option.
  2. I can not consolidate the scripts into one module. Even if I could there are other arbitrary files that also need to be packaged in the final assembly that can not be consolidated in one place (I used scripts as a simple example to illustrate the problem).
  3. Yes, I think 100 modules is too many but I have no control over this.
  4. Given the large # of modules I would prefer a solution that does not require modifying each & every POM.
carej
  • 596
  • 1
  • 6
  • 18
  • There are two options: [maven-assembly-plugin](http://maven.apache.org/plugins/maven-assembly-plugin/) and [maven-shade-plugin](http://maven.apache.org/plugins/maven-shade-plugin/) – yegor256 Aug 27 '12 at 19:42
  • @yegor256: yes, I know about using the assembly plugin; as I stated in the question I'm looking for an **alternative** to each module declaring it's own assembly. As for shade, I don't see how that would help me collect arbitrary files from other modules. Can you elaborate? – carej Aug 27 '12 at 20:07

2 Answers2

0

Rather than each module having its own assembly, create a separate module called assembly (name is arbitrary) and have your assembly descriptor grab arbitrary files from the other modules using relative paths. I.e.

<files>
    <file>
      <source>../config-module/target/sample-config.xml</source>
      <outputDirectory>configs</outputDirectory>
    </file>
</files>

The path ../config-module assumes that you have a module of that name. I also assume that you grab the sample-config.xml file out of target/ rather than the src/main/whatever directory.

Note that if your "arbitrary files" are Maven artifacts generated by each module (i.e. WARs), than there could be more idomatic ways of accomplishing the above. See: Maven: The Complete Reference - "Best Practices"

noahlz
  • 10,202
  • 7
  • 56
  • 75
  • is there any way of doing this besides relative paths to each module? I don't want the assembly module (which I already have) to be forced to keep track of which of the 100+ modules have arbitrary files & which don't. Are wildcards accepted in the **source** element? – carej Aug 27 '12 at 20:30
  • Yes - read the section "8.6.2. Distribution (Aggregating) Assemblies" in the linked book. – noahlz Aug 27 '12 at 20:39
  • as I mentioned in the OP I want to avoid an assembly of assemblies. Do you mean to say that there is no other good way to do this besides an assembly of assemblies? – carej Aug 28 '12 at 14:57
  • Per the linked Maven book, an assembly of assemblies is the way to go. The best practice is that each module should generate one artifact (i.e. a JAR or a WAR, but not a WAR + assembly). You then have a module called "distribution" or some such that is your assembly that draws content from all other modules. – noahlz Aug 28 '12 at 16:02
  • thanks for the input. Unfortunately this seems to be another situation where the "Maven way" is butting heads with objective reality: something that I'm discovering is all too familiar in Maven-land. At this point I'm thinking that we'll be writing a custom plugin to handle our requirements. – carej Aug 31 '12 at 16:50
  • Just curious what you mean by "objective reality?" Note that I understand what you mean by "the Maven way." – noahlz Aug 31 '12 at 17:36
  • objective reality being that we have something that doesn't fit neatly into Maven's walled garden & we aren't willing to contort our source tree into something that is more amenable to Maven as doing so wouldn't make sense for how our developers work. – carej Aug 31 '12 at 17:57
0

Unfortunately I couldn't find a better answer besides creating an assembly-of-assemblies. It looks like we'll be writing our own Maven plugins to handle this requirement as using an assembly-of-assemblies is way too cumbersome given our situation.

carej
  • 596
  • 1
  • 6
  • 18