You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Viktor Sadovnikov <vi...@jv-ration.com> on 2013/11/22 17:11:05 UTC
Premature decomposition of projects
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
Re: Premature decomposition of projects
Posted by Baptiste Mathus <bm...@batmat.net>.
Wasn't it just the mvn -U to force updating snapshots you were looking for?
Cheers
2013/11/22 Russell Gold <ru...@gold-family.us>
> It’s also an attempt to create a modular system, in hopes of minimizing
> codebase size and providing custom functionality. It’s thus closely related
> to a lot of the modularity ideas that have come and gone over time, without
> the judgment of what is properly a “module.” I’ve seen multi-hundred module
> projects.
>
> On Nov 22, 2013, at 1:33 PM, Ron Wheeler <rw...@artifact-software.com>
> wrote:
>
> > Looks like a kludge to get around a poor SOA architecture with too many
> inter-module dependencies and an unwillingness to build mock objects for
> testing.
> >
> > In our house, SNAPSHOTS posted to Nexus come with a warranty that they
> meet a subset of the spec that is known.
> > If someone doesn't like that level of instability, they should make mock
> objects that they understand.
> >
> > Ron
> >
> >
> > On 22/11/2013 11:11 AM, Viktor Sadovnikov 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
> >>
> >
> >
> > --
> > 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
> >
>
> -----------------
> Author, Getting Started with Apache Maven <
> http://www.packtpub.com/getting-started-with-apache-maven/video>
>
> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
> and listen to the Misfile radio play <
> http://www.fuzzyfacetheater.com/misfile/>!
>
>
>
>
>
>
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Premature decomposition of projects
Posted by Russell Gold <ru...@gold-family.us>.
It’s also an attempt to create a modular system, in hopes of minimizing codebase size and providing custom functionality. It’s thus closely related to a lot of the modularity ideas that have come and gone over time, without the judgment of what is properly a “module.” I’ve seen multi-hundred module projects.
On Nov 22, 2013, at 1:33 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
> Looks like a kludge to get around a poor SOA architecture with too many inter-module dependencies and an unwillingness to build mock objects for testing.
>
> In our house, SNAPSHOTS posted to Nexus come with a warranty that they meet a subset of the spec that is known.
> If someone doesn't like that level of instability, they should make mock objects that they understand.
>
> Ron
>
>
> On 22/11/2013 11:11 AM, Viktor Sadovnikov 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
>>
>
>
> --
> 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
>
-----------------
Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video>
Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
and listen to the Misfile radio play <http://www.fuzzyfacetheater.com/misfile/>!
Re: Premature decomposition of projects
Posted by Ron Wheeler <rw...@artifact-software.com>.
Looks like a kludge to get around a poor SOA architecture with too many
inter-module dependencies and an unwillingness to build mock objects for
testing.
In our house, SNAPSHOTS posted to Nexus come with a warranty that they
meet a subset of the spec that is known.
If someone doesn't like that level of instability, they should make mock
objects that they understand.
Ron
On 22/11/2013 11:11 AM, Viktor Sadovnikov 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
>
--
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
Re: Premature decomposition of projects
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <vi...@jv-ration.com> | http://jv-ration.com | +31 6
> 2466 0736
>
>
> On Sat, Nov 23, 2013 at 11:53 AM, Jeff MAURY <je...@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" <zi...@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
Re: Premature decomposition of projects
Posted by Viktor Sadovnikov <vi...@jv-ration.com>.
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 <vi...@jv-ration.com> | http://jv-ration.com | +31 6
2466 0736
On Sat, Nov 23, 2013 at 11:53 AM, Jeff MAURY <je...@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" <zi...@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
>
Re: Premature decomposition of projects
Posted by Jeff MAURY <je...@jeffmaury.com>.
Baptiste, you got it.
Jeff
On Sat, Nov 23, 2013 at 10:50 AM, Baptiste Mathus <bm...@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" <zi...@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
Re: Premature decomposition of projects
Posted by Baptiste Mathus <bm...@batmat.net>.
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" <zi...@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
> >
>
Re: Premature decomposition of projects
Posted by Ziga GREGORIC <zi...@gmail.com>.
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 <je...@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
>
Re: Premature decomposition of projects
Posted by Jeff MAURY <je...@jeffmaury.com>.
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 <vi...@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