I have some ruby scripts that we use to detect all the modules with changes (i.e. the seed set of modules that need a release) and computes the release dependency tree for all the pom.xml files.
Then it will start with the first module with changes and release that (by forking release:prepare release:perform) Once that module is released it updates all the downstream dependencies of that module and continues to the next module in release order with changes. We use that script for the big bang releases (i.e. when we bump a minor version number) Within a minor version number we can just release each module as necessary (when you build a lot of jenkins plugins customers need not upgrade all of them anyway, so you need to allow for mixed versions during development) The helper script can also pull everything together on the latest -SNAPSHOTs of everything. It's not perfect, but it is useful for us. I intend rewriting this set of scripts into the m-release-p so that it can handle aggregation releases like the ruby scripts do only with certainty of correct model construction. (I'd share the ruby scripts only they have subtle parsing issues that could trip you up if you were using outside of our codebase) On 22 September 2015 at 18:47, Kevin Burton <bur...@spinn3r.com> wrote: > We have a multi-module setup whereby we have about 150 independent modules. > > Our build takes a long time and actually slows down development as we have > to do a compile of a LOT of source code to rebuild the project. > > Additionally, we have a lot of code that we want to Open Source. > > This has meant git submodules the IMO git submodules really don’t work when > using branches. They break and require a whole bunch of custom works and > hack and when they DO break it’s confusing how to resolve them. > > This has meant that we’ve not really done a good job of OSSing our code > base as its just too hard. > > What we’ve done to date is just have one major version number across all > our projects. So upgrading them and fixing their dependencies means that I > just have to change a version number everywhere and I’m done. > > What I was thinking of is changing this strategy to use the maven > "versions:use-latest-versions” plugin. > > What i would do is have a parent directory named ‘spinn3r’ which just has a > bunch of git submodules. We NEVER branch in this directory. > > It also means that any of our developers can check it out so that they have > all of our source code. > > At this point I can use a normal development strategy for each project. > They don’t use submodules which enables us to branch/merge easily. > > I can also have a dedicated IntelliJ or Eclipse project for each one and > switch between them. > > Now the main issue I have is how do I bump releases easily and make sure > all my code is using the latest version of its sibling projects. > > In the parent directory I can just run versions:use-latest-versions … on > each one of the projects so that it automatically pulled in the latest > version after a release. > > The only problem here is that there’s a dependency graph that needs to be > considered. > > for example, if project A depends on project B, then we have to bump the > version and push project B into maven before we upgrade dependencies on > project A. > > This is a frustrating issue… > > -- > > We’re hiring if you know of any awesome Java Devops or Linux Operations > Engineers! > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
