I am happy to see this discussion, and so many responses. We have struggled with it for years, and never found a great solution. Sounds like we do what many others are doing:
- We have many shared internal libraries amount multiple products. - We divide each logical set of libraries into their own repos, often multi-module builds themselves. - Each product is in its own repo as well, also often a multi-module build depending on the complexity of the product. We aren't a huge team, despite the number 4-6 products we have, but basically any team can make a change to a library as needed. We do have Pull Requests that are visible to the whole dev team, and we try to maintain some consistency at the library level, but that is a separate discussion. We then have a policy that whenever a PR is merged into a "library", we "release" that "library". We just jgitflow <https://bitbucket.org/atlassian/jgit-flow/wiki/Home> for releasing because, well obviously, we use git flow. It is up to the product teams to update their versions for internal libraries. As others have mentioned, we use versions plugin for that. We always keep our versions in properties so we can use mvn versions:update-properties. We configured it to only update our "internal" repositories by default so that we can quickly do that without worry of bring in some 3rd party/OSS update without vetting it first. This is done with shared corporate parent pom configuration <includes> <include>com.yourcompany*:*</include> </includes> <excludeProperties>jetty.version,servlet-api.version,${moreExcludeProperties></excludeProperties> Note the extra ${moreExcludeProperties> at the end, which allows child poms to add to the list through another property in their own pom as needed. We also automatically build our products every night with the latest of all the internal libraries. While a bit delayed, at least we get a notification if another teams' update of a library will break a separate product - either compile or test. In the old days of subversion, we used to actually automatically update all the poms in our repo whenever we did a release - without a CI server. That was automated through a plugin that scanned all the pom's in the svn repo for use of the released library and auto-updated and commited the new version. If not familiar with svn, you can picture each top-level directory of svn being converted to a git repo (in a svn "repo" meant something different than git, at least practically speaking). This was nice because the author of the library change was the "author" of all the pom updates, and thus easy to "blame"/"praise" for a break (or fix) and because it was an instantaneous update, so CI would run immediately on all the dependent projects. That was possible because with SVN you could do commits without having to actually clone a local copy. With git spread across multiple repos it would require all our devs to have all git repos checked out in a consistent fashion to make this scalable -- so not something we've preserved when we switch to git years ago. Alternatively, we would have to auto-clone all the known repos in our system -- again, not really scalable. Food for thought -- it's great to hear so many other ways of dealing with this problem. -Ben On Thu, Dec 1, 2016 at 8:57 AM Christian Schulte <c...@schulte.it> wrote: > Am 12/01/16 um 10:02 schrieb João Cabrita: > > [...] > > > Each of the applications live in a separate repository > > [...] > > > The libraries also have a repository each > > [...] > > That's due to the SCM in use. Yes. This is something to keep in mind as > well. What can be one (big) repository using subversion, may need to be > split into multiple (tons) of repositories when switching to e.g. git. > Basing something on a concept introduced by the SCM in use will make it > hard to switch to another technology later. Subversion on the server and > git-svn locally is working great here. Commits to the subversion server > are really clean because developers could re-arrange theire commits > (rebase -i, squash, etc.) locally before. Depending on the subversion > revision for anything you'll not change to another SCM technology ever > soon (why would you?). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- -- Ben Tatham Software Architect *Nano**metrics* *Inc.* Ottawa * I* Calgary *I* Houston *I* Beijing T: +1 613 505 5065 *I* bentat...@nanometrics.ca www.nanometrics.ca *I *www.microseismicmonitoring.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, or have been inadvertently and erroneously referenced in the address line, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
