Following up on this. First, thanks for the quick and detailed responses.
I have another colleague that suggested we create a single new GIT repo for the 'library' code that would be a multi-module Maven build, each module being a component. My first thought is that it does solve the 'releasability' of components and applications issue but does it allow granular versioning/releasing of the modules? In all my experience with multi-module builds they all shared the same version from the parent and all were released at the same time with the same version. However is that a Maven requirement? I see in the link below in the multi-module projects section that there is an autoVersionSubmodules flag. So if that is false how does this work on the sub-modules? E.g. it says it will prompt for the new version for each module but does it allow you to skip modules that didn't have any changes so no need to release? E.g. is the release granularity at the module layer? E.g. if I have 10 components in the multi-module Maven build, can I release just one and with a version completely independent of the others? Also just so I know...can the release plugin be run on just one module and not on the parent? https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html Again just looking for best practices here regarding sharing components and how they can be versioned independently. Thanks, -Dave On Mon, Apr 12, 2021 at 12:36 PM Mantas Gridinas <mgridi...@gmail.com> wrote: > Being in similar situation myself I strongly suggest against storing > the "library" component in the same place as your application is > stored, because you will be producing n+1 artifacts every time, where > n is the modules actually required to build for your application. Your > application will be moving faster than that library component and you > will be producing duplicate builds of it, which ultimately just > consumes space in your artifact repository. The upside of this > approach is you don't have to worry about transitive dependency > conflicts. > > In our case we host sonatype, put everything there and reference them > as needed. There are two downsides to this approach, though: > dependency conflicts and bumping the dependency in dependent > applications. > > Dependency conflicts happen because of several reasons: > * developer decided to change its artifact/group id starting with some > version > * you're importing some dependency pom (like spring, camel, or what > ever overarching framework provides it) > * you require several frameworks at the same time > > Maven is perfectly capable of resolving those conflicts if artifacts > actually collide (spring-boot-camel-starter:3.0.0 provides spring boot > 2.2.1 while you're actually using 2.4.4, and since you have shorter > path to spring 2.4.4 maven will use that). Problems arise when > collisions happen between artifacts that contribute to same package > (ex. ehcache changing its group id between ehcache 2 and ehcache 3) or > depend on each other indirectly (ex. cxf switching between blocking > and async calls depending if you have cxf-rt-transports-http-hc on > your classpath). This is solved by using enforcer plugin with > dependency convergence rule. > > Dependency bumping is a pretty tiring process. Whenever you would > release a new library version, you would have to go and bump its > version across all applications and/or libraries that depend on it. > Since we're in the process of splitting our monorepository, we were > looking into solutions to automate that. If you're on github, and use > github as nexus, you can look into dependabot. It's free to use and > has a lot of configuration options. Since we're not so lucky, we might > end up using renovate or something similar. The idea is to create a > pullrequest to dependents whenever a new version of that library is > released with the bumped version. Upside is you won't have to do > manual labor of bumping the version, while downside is having a ton of > noise if you have complicated dependency trees. > > These are issues i've encountered so far. You can start by hosting > your own nexus, uploading artifacts to it and referencing the > artifacts in the pom. Sonatype offers free solution > https://www.sonatype.com/products/repository-oss-download. Take care > of your dependency tree. > > On Mon, Apr 12, 2021 at 6:03 PM David Hoffer <dhoff...@gmail.com> wrote: > > > > Hey just looking for Maven best practices here, want to be sure I'm not > > missing something. > > > > Here is our use case. > > > > We have 10 applications that have duplicate code in each, we want to > create > > component(s) for the duplicate code and not duplicate in the 10 apps/GIT > > any longer. > > > > Each app is in a separate GIT repository & each has a Maven build. > Simple > > single module build in each. > > > > To solve this I am assuming we need a new GIT repo for the duplicate code > > and a Maven build for it. That repo and it's component would be released > > and then the 10 apps would then depend on that released artifact > (SNAPSHOT > > until release). > > > > However I have someone here that is saying he wants to not create any > other > > GIT repo and just make child modules in one of the 10 apps for the shared > > code then have the other 9 apps depend on the child module GAV. > > > > However with this approach we would have to 'release' App 1 to get a > > release version and then update the other 9 apps to use that app's > version > > for the component, right? It seems it causes releasably issues for the > > component as no other app can be released until App1 is released first, > > correct? > > > > What is the normal pattern in the Maven world when a company wants to > share > > components between apps when the applications are in separate GIT repos > and > > therefore have separate Maven builds? > > > > -Dave > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
