maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viktor Sadovnikov <vik...@jv-ration.com>
Subject Re: Premature decomposition of projects
Date Sat, 23 Nov 2013 12:31:08 GMT
Thank you very much for your responses!! It's very supportive!!

@Ziga, your suggestion to limit access to snapshot repository for CI
servers only is a very, very interesting one. I'll give it a thought/try.

However dependency on a snapshot of something, which does not get built
together with your changes, still feels a bit too "agile" (I meant
anarchic). That dependency can be managed by another development team; you
re-run your CI build for a known to be good version of the code and it
suddenly gives different results.

Viktor Sadovnikov @ JV-ration
evolution of Joint Vision
Tuinluststraat 14, 2275XZ Voorburg, The Netherlands
viktor@jv-ration.com <vikor@jv-ration.com> | http://jv-ration.com | +31 6
2466 0736


On Sat, Nov 23, 2013 at 11:53 AM, Jeff MAURY <jeffmaury@jeffmaury.com>wrote:

> Baptiste, you got it.
>
> Jeff
>
>
> On Sat, Nov 23, 2013 at 10:50 AM, Baptiste Mathus <bmathus@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.gregoric@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 <jeffmaury@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 <
> > viktor@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message