[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Premature decomposition of projects
From:       Ron Wheeler <rwheeler () artifact-software ! com>
Date:       2013-11-23 23:51:26
Message-ID: 52913F7E.20604 () artifact-software ! com
[Download RAW message or body]

On 23/11/2013 7:31 AM, Viktor Sadovnikov wrote:
> 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.
That is why SNAPSHOT have to come with a warranty and a spec if they are 
deployed.
No Maven build strategy is going to eliminate the need for project 
management and communication within the team or between teams.
Until you get a warranty from the person producing the SNAPSHOT, you 
need to use mocks (your own or provided by the other team) that have a 
defined behaviour that you can count on and understand.

When you start a new release, you will have everyone working on 
SNAPSHOTs. This is not bad or good, it is just reality.
As modules get completed and have their features tested to a point where 
the authors are ready to release an RC or Mx build or a final release, 
you get to an increasingly stable environment.
The project manager has to organize the resources correctly so that 
resources are not wasted.
That is what the PM gets paid for.
If you need the core libraries updated, the changes made to the 
persistence and the key services in a stable state before you can build 
the UI or reporting or documentation, then you need to allocate 
resources so that this happens.

Ron

>
> 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
>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]