On 7 January 2014 09:42, erich8 <eric.herrm...@intermedix.com> wrote: > Barrie Treloar wrote >> When you build Product X the libraries A, B and C should already >> exist. You dont want to rebuild them just to build Product X, that >> will slow down your development process. >> Ideally A, B, and C are released versions, but if you find a bug in >> them then you will be using SNAPSHOT versions, which will need to be >> released separately prior to releasing Product X. >> If developers are rarely touching the libraries then its better to let >> your continuous build system (e.g. Jenkins) build the libraries and >> Maven will automatically pull down the latest SNAPSHOT for you. >> This way Developer D can fix a bug in A and Developer E will >> automatically get the bug fix the next time they pull down the >> SNAPSHOT build of library A, they no longer need to resync and >> manually build. >> You can configure how often Maven will check for a snapshot update >> (see updatePolicy >> http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots) >> >> With a continuous build system in place whenever C changes it will >> automatically schedule a build for A and B, run your unit tests and >> report success or failure. >> It should also then build Product X and Y for you (since a downstream >> dependency changed), again running your unit tests. >> >> You will also want a Repository Manager so that it can keep some >> control over how many SNAPSHOT versions to keep (otherwise you can >> find yourself running out of disk space) >> >> Hope this helps some. > > I understand the need to treat internally-developed dependencies as actual > dependencies rather than forcing them to be modules, but I'm having some > problems with the workflow. > > When the project is relatively new and the internally-developed dependency > "A" is no where near being mature, nearly every change being made to > "Project X" requires a corresponding change to A. At this point in the > development cycle (and for many months in the foreseeable future) I actually > /do/ need to rebuild A every time I build X. > > I can setup our CI system so that A SNAPSHOTS are built and published to > Nexus after every commit, but what about during development, before I'm > ready commit my changes? Am I stuck with what my IDE provides? We have > developers using a wide range of IDEs, or no IDE at all, so I was hoping > that Maven itself would have some way of kicking off builds of downstream > dependency A when X is built, if in fact that's what I want to do.
Ideally you want your development to be only against releases, but as you notice in the early days that just can't happen. One thing I neglected to mention is that publishing SNAPSHOT to a repository can be a pain. The reason is that while you are happily working with your artifacts, if a new SNAPSHOT is published and Maven decides to start downloading it then you can find your local development hosed by bugs in the new SNAPSHOT. Obviously there is a trade-off here. You want to see bugs quickly so that you can get them fixed correctly - either your code, or the dependency. But you can also waste a lot of time if you have people checking in things that cause breakage all the time (perhaps you then need to investigate why that is occurring and deal with that as well). You should be able to manage this with the --no-snapshot-updates option so you can when you want to pull in newer SNAPSHOTS. Just remember that you may have to rebuild your code again so that your local .m2 cache has your code changes in it and not the CI version. The next thing to ask is who is making the changes to A and X. If it is the same person then they dont need Maven yet. They can build via the command line, IDE, whatever. I prefer to let the IDE (Eclipse in my case) handle the incremental build problems. I keep working on whatever projects I need until they are ready to commit into version control and the IDE will ensure that everything is building correctly so I can run my unit tests, etc all in the IDE. I'm not using Maven at all here. Before I commit this to version control, then I break out Maven and build the projects in the correct order and ensure everything works. Once committed to version control then CI will publish the SNAPSHOTS and other developers can then decide when they want to start using the new SNAPSHOTS. > Right now we're simply telling folks to build A, then build X. And this > certainly makes sense when you step back and think about it... it's just not > terribly convenient. If those folks are working on A and X they dont have any other options, they want to build their code with their changes and not suddenly get something from CI (which obviously can not have their changes in it). For those working with IDEs they should be able to just work in the IDE. I'm fairly sure there is Maven integration with m2e like features in NetBeans and IDEA. I dont understand how you can efficiently develop without an IDE and I'm not prepared to spend any of my time trying to help them out :) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
