Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As nico_ekito stated in one of the comments, in my own opinion, you are falling right now into the "dependency management nightmare". As per your scenario... isn't the fact of managing different versions for submodules (as well as different code stability) a symptom of that those submodules are no longer part of the big project?</p> <p>I mean, we, as humans, can clearly state that those modules are part of the big picture, the whole approach for solving a problem. That is quite common when you find that your utility classes have no use outside the scope of that big picture. But, from the Maven point of view I think that you are actually dealing with different projects rather than modules of a big one.</p> <p>So, maybe it's worth to separate the codebases in different structures and just simply reference the utility jars from the modules that actually require it and just use stable builds instead of "last version of that dependency". If working with stable builds it's not feasible because, even though the code for that dependencies is quite stable, it keeps changing at the same time that the code from the other modules, then the solution that Maven gives you is using SNAPSHOTS.</p> <p>I think you will find some benefits when breaking the code base into separate projects:</p> <ul> <li>That way Maven won't trigger a build in those utility modules when it's not needed.</li> <li>If can find a way of just using stable releases for the dependencies you will avoid a lot of hassle.</li> <li>You can also break the team and make the ones to work with just the utility jars do so on a "under-demand basis" from the team that consumes that dependencies.</li> <li>If those utilities are abstract or reusable enough you may find someday another project that may consume them as well without the need of referencing a submodule from a larger project.</li> </ul> <p>There is a lot of discussion in the Internet about the way <a href="http://softwaremavens.blogspot.com/2010/01/top-10-reasons-why-maven-sucksnot.html" rel="nofollow">Maven handles dependencies</a> (and other things) and a lot of people complain about the same problems you are facing. In my own opinion, Maven is a great tool, designed to save us a lot of time when starting new projects but sometimes it can be a bit cumbersome. I started to take a look a other tools like <a href="http://gradle.org/" rel="nofollow">Gradle</a> but now changing the build tool may be worse thing to do. Just giving a though to the idea of breaking the code base, sometimes we can solve a "software problem" just with a bit of "project management" (or "portfolio mangement" in this case).</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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