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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
