Home/ Questions/Q 839611
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T05:29:34+00:00

For educational purposes I have set up a project layout like so (flat in

  • 0

For educational purposes I have set up a project layout like so (flat in order to suite eclipse better):

-product
 |
 |-parent
 |-core
 |-opt
 |-all

Parent contains an aggregate project with core, opt and all. Core implements the mandatory part of the application. Opt is an optional part. All is supposed to combine core with opt, and has these two modules listed as dependencies.

I am now trying to make the following artifacts:

  1. product-core.jar
  2. product-core-src.jar
  3. product-core-with-dependencies.jar
  4. product-opt.jar
  5. product-opt-src.jar
  6. product-opt-with-dependencies.jar
  7. product-all.jar
  8. product-all-src.jar
  9. product-all-with-dependencies.jar

Most of them are fairly straightforward to produce. I do have some problem with the aggregating artifacts though. I have managed to make the product-all-src.jar with a custom assembly descriptor in the ‘all’ module which downloads the sources for all non-transitive deps, and this works fine. This technique also allows me to make the product-all-with-dependencies.jar.

I however recently found out that you can use the source:aggregate goal in the source plugin to aggregate sources of the entire aggregate project. This is also true for the javadoc plugin, which also aggregates through the usage of the parent project.

So I am torn between my ‘all’ module approach and ditching the ‘all’ module and just use the ‘parent’ module for all aggregation. It feels unclean to have some aggregate artifacts produced in ‘parent’, and others produced in ‘all’. Is there a way of making an ‘product-all’ jar in the parent project, or to aggregate javadoc in the ‘all’ project? Or should I just keep both?

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Flattened trees are not often used anymore. This was done several years ago to deal with how Eclipse handled projects and the lack of good Maven and Eclipse integration. If you use m2eclipse to import Maven projects into Eclipse, you won’t have any problems with a maven-typical nested tree.

    As far as what is a good example of how to structure a Maven build? The Maven project source itself. It has all the pieces you desire, including the final assembly that packages up the bundles.

    The typical nested structure has a top down hierarchy where the parent is doing the aggregation of the modules below it, and the children are inheriting values from the parent. Although these can and sometimes are separate, this is not the norm.

    • 0