Baptiste, you got it. Jeff
On Sat, Nov 23, 2013 at 10:50 AM, Baptiste Mathus <bmat...@batmat.net>wrote: > I guess Jeff is only speaking about version ranges, not snapshots. > > If so, I'm +1 with Jeff. I don't think version ranges should ever be used. > > Cheers > Le 23 nov. 2013 00:18, "Ziga GREGORIC" <ziga.grego...@gmail.com> a écrit : > > > Jeff, maybe I'm missing the point, but to have the possibility to define > a > > SNAPSHOT version of a dependency is the beauty of maven IMHO. > > > > Having said that, I would not feel safe in a large project where lots of > > dependencies are SNAPSHOT dependencies. But when you have a continuous > > integration server, all these SNAPSHOT dependencies will be in 'latest'. > > Ok, it's not really easy, as one might have more than one build agent, > > which implies the need for snapshot maven repository, but this is another > > topic (also on the first link of that thread, but I don't wanna go in > > there). > > > > When a release (with maven-release-plugin) is just a click of a button > > away, you can easily release a milestone version (1.2.03-M1), so the big > > majority of the team can work without the need to build internal SNAPSHOT > > dependencies or mixing own SNAPSHOTS with SNAPSHOTS from team's maven > > repository. Using this approach, you easily get repeatable builds. Only > the > > team, intentionally working on both the main project and the dependency > > 'foo', would set 'foo' to SNAPSHOT in the main project. When 'foo' > becomes > > feature complete, 'foo' get's released and its version incremented in the > > main project. > > > > The other way is to use buildnumber-maven-plugin, which would fetch > source > > control revision number, branch name, which you can put into MANIFEST.MF > - > > have a look at > > http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html > > > > @Viktor, I agree on you last point. When you high cohesion on maven > project > > level, bring the projects together as a multi module maven project and > > versioning is no longer an issue for modules. > > The issue with snapshot repository is that you have to define who can > > publish and who can use these snapshot artifacts. When we need multiple > > build executors (build agents), and we have a project with a SNAPSHOT > > dependency on another project, we must have a snapshot maven repository > and > > build agents configured to publish these SNAPSHOTs with every build. But > > this does not mean that every developer has to use this snapshot maven > > repository. I'd actually try to keep developers away from snapshots > > repository. This automatically forces the 'main' project to be easy on > > number of SNAPSHOT dependencies. If you have one, everyone is aware of > it, > > as it has to be build separately (and one is sure of what revision that > > is). > > > > Sorry for my TL;DR style comment. I just wanted to share my experience > > dealing with non identified versions. > > > > Ziga > > > > > > > > On Fri, Nov 22, 2013 at 10:26 PM, Jeff MAURY <jeffma...@jeffmaury.com > > >wrote: > > > > > Having a build using non identified dependencies (LATEST,...) is a VERY > > bad > > > practice: the build is not reproducible and your team will not have > > > attentions on dependencies versions. > > > A non existing case for me. > > > > > > Jeff > > > > > > > > > On Fri, Nov 22, 2013 at 5:11 PM, Viktor Sadovnikov < > vik...@jv-ration.com > > > >wrote: > > > > > > > Hello, > > > > > > > > Here is an interesting article about dependencies management and > builds > > > > with Maven, which can become unnecessary overcomplicated > > > > http://bit.ly/1dn9ZZL > > > > > > > > With regards, > > > > Viktor > > > > > > > > > > > > > > > > -- > > > Jeff MAURY > > > > > > > > > "Legacy code" often differs from its suggested alternative by actually > > > working and scaling. > > > - Bjarne Stroustrup > > > > > > http://www.jeffmaury.com > > > http://riadiscuss.jeffmaury.com > > > http://www.twitter.com/jeffmaury > > > > > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
