Databases
StackOverflow2013
Postsdbo
POHow do I properly setup a multi-module Maven project with sliding release cycles
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow do I properly setup a multi-module Maven project with sliding release cycles
    primarykey
    data
    text
    <p>I'm trying to work out the best way to setup our multi-module Apache Maven project in a way that allows for disparate release cycles of modules, and doesn't introduce dependency issues when debugging the project.</p> <p>We currently have a setup along the lines of:</p> <ul> <li>bigsystem@1.2 <ul> <li>parent-1.1-SNAPSHOT</li> <li>module a@1.4-SNAPSHOT <ul> <li>parented by parent@1.1-SNAPSHOT</li> </ul></li> <li>module b@1.3-SNAPSHOT <ul> <li>parented by parent@1.1-SNAPSHOT</li> <li>depends on a@1.1</li> </ul></li> <li>module c@1.1-SNAPSHOT <ul> <li>parented by parent@1.1-SNAPSHOT</li> <li>depends on a@1.2</li> <li>depends on b@1.1</li> </ul></li> </ul></li> </ul> <p>The dependencies declared in modules b and c contain the minimum version required to compile the module, which isn't necessarily the current version of the module, or the version of the module being deployed.</p> <p>From a build perspective this works well, each module can be released/updated as needed, however when trying to debug the deployed application under IntelliJ IDEA (versions 8 and 9 EAPs) having opened the top level pom, IDEA decides that since we declared a dependency on a@1.2, that anytime we step into one of a's classes, it should open it from a-1.2-sources.jar rather than the current a@1.4 sources in the project. This is further confused by the fact that stepping into any of b's classes takes us to b@1.1 rather than b@1.3.</p> <p>My initial attempt to work around this was to declare the version numbers in the parent pom's dependencyManagement section and just have the sub-modules inherit the version. This worked to the degree of solving the IDEA debug issue as the dependencyManagement section can point everyone to the current -SNAPSHOT versions.</p> <p>This unfortunately causes a problem when doing a maven release due to having to release the parent pom before releasing the module, but as the parent may refer to multiple in-development -SNAPSHOTS it can't be released and we end up adding version references back to the modules pom to satisfy the release.</p> <p>It would seem that using maven's dependencyManagement section would only really work well if we were releasing ALL bundles at the same time, regardless of if they changed, but as we're wanting to manage releases of each sub module only when needed this model doesn't seem to fit.</p> <p>I have a suspicion I'm missing something, and that a combination of dependencyManagement and version ranges might satisfy out requirements although I've yet to see version ranges work properly.</p> <p>Is there a better way? A proper way?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USAlex B
    1. USMark Derricutt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow do I properly setup a multi-module Maven project with sliding release cycles
      1. USMike Cornell
      1. VTFavorite
    2. VO
      singulars
      1. POHow do I properly setup a multi-module Maven project with sliding release cycles
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POHow do I properly setup a multi-module Maven project with sliding release cycles
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload