You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "javadevdave@googlemail.com" <ja...@googlemail.com> on 2009/09/04 09:38:17 UTC
dependency / version problem
Hi all!
My problem is not easy to describe :-) But i try it...
I have add a picture to this mail, where the situation is painted..
The Situation:
There are two versions of my project.
- Version 3: This version is in production and has been frozen. (the
repository for V3 is offline, that no changes from dependencies can make
trouble...)
- Version 4: This is the actual developed Version. It usees another remote
Repository because some dependencies changed.
Using eclipse M2 plugin for developing.
The Problem:
All dependencies (from V3 and V4) are at the same time in the local
repository. And there is one special dependency (can also be transitive)
with no fixed version. (red circle in painting)
In V4 there was created a new Version for that dependency (from a third
party! But i didn't recocnize, because maven fetch it automaticly!!)
Now, there is also a new Version of that dependeny in the local repository.
Suddenly there should be a bug fixing in V3! (So the frozen version should
be used to change something...)
But, the changed dependency, described above, is in the local repository and
is also be used from V3, what is wrong, because the frozen state used
another version!
(Another version can have some differences, where the build doesn't break,
but some different behaoviours can be in the software... so there are
unpredictable bugs!)
Some possible solutions, and why they aren't real solutions:
1) clean the local repository before bug fixing V3:
To fetch all dependencies from remote Repository V3 needs some time. And the
developer must be able to switch beetween V3 and V4 very fast. To clean and
"reload" the local repository is to time-intensive, and if some changes are
made in V4, and after that again in V3, the clean should be made again and
again....
2) change dependencies version-range to one version only:
I have to look for all dependencies, transitive dependencies etc. where some
version ranges can be defined. This is to much to look for!
So... If anythink is not described properly, please ask :-)
I hope there is any solution for that problem...
Thanks if you are a this point! :-)
Re: dependency / version problem
Posted by "javadevdave@googlemail.com" <ja...@googlemail.com>.
2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>
> there is no picture? I added it to the first mail.. and i can see it as an
> attachment... I try it again with that mail...
>
> I already use Maven for complete Version Management.
>
> >Use in this global POM a dependencyMgmt section and define there
> >all your deps with fix versions.
>
> And here is the problem. This is not possible because the problem I
> described is a transitive dependency, I don't know! (Because its in any
> dependency of another dependency...) So defining fix versions of the
> "first"-direct dependency is ok (DEP_A). But if there are dependencies in
> DEP_A (DEP_A->DEP_B) and DEP_B has some dependeny with open version-ranges
> (DEP_Copen)...
> then I cant influence this. And there is suddenly a new version of the
> dependency (DEP_Copen) used by all versions of my project (V3,V4 etc.).. and
> then there can be unpredictable bugs... (in an older tested version of my
> project)
>
> I think the picture is very important to understand this use case, so I add
> it again...
>
> thanks...
>
> Dave
>
>
>
>
> 2009/9/4 Stephen Connolly <st...@gmail.com>
>
> 1. you refer to a non-existant picture
>>
>> 2. Jorg's solution is the way to go.
>>
>> -Stephen
>>
>> 2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>
>>
>> > Hi!
>> >
>> > Thanks for the complete answer.
>> > I think i described it a bit inconclusive. But the approach you
>> described
>> > will also not solve the problem:
>> > because:
>> > the dependency i described can be transitive! (I dont know every
>> dependency
>> > - for example - of spring, so it's impossible for me to check every
>> > version-range of every dependency of spring ...)
>> > So.. if I have one parent pom for all the different versions of the
>> > project,
>> > there is still the problem, that some version range in any dependency
>> (like
>> > in the sample of my picture)
>> > - not defined by myself (a transitive from any third party) -
>> > influence all versions!! (because the newest version is used, and the
>> > newest
>> > version is first searched in the local repo - for all project versions)
>> >
>> > To define different local repos for every project Version is possible,
>> but
>> > then there are some problems with automatic build (after storing changed
>> > code) in M2Eclipse, because you cant give maven-parameters with it.
>> >
>> > I hope it's a bit clearer...
>> >
>> > thanks
>> >
>> >
>> > 2009/9/4 Jörg Schaible <jo...@gmx.de>
>> >
>> > > Hi,
>> > >
>> > > javadevdave@googlemail.com wrote at Freitag, 4. September 2009 09:38:
>> > >
>> > > > Hi all!
>> > > >
>> > > > My problem is not easy to describe :-) But i try it...
>> > > > I have add a picture to this mail, where the situation is painted..
>> > > >
>> > > > The Situation:
>> > > >
>> > > > There are two versions of my project.
>> > > > - Version 3: This version is in production and has been frozen. (the
>> > > > repository for V3 is offline, that no changes from dependencies can
>> > make
>> > > > trouble...)
>> > > > - Version 4: This is the actual developed Version. It usees another
>> > > remote
>> > > > Repository because some dependencies changed.
>> > > >
>> > > > Using eclipse M2 plugin for developing.
>> > > >
>> > > > The Problem:
>> > > >
>> > > > All dependencies (from V3 and V4) are at the same time in the local
>> > > > repository. And there is one special dependency (can also be
>> > transitive)
>> > > > with no fixed version. (red circle in painting)
>> > > > In V4 there was created a new Version for that dependency (from a
>> third
>> > > > party! But i didn't recocnize, because maven fetch it automaticly!!)
>> > > > Now, there is also a new Version of that dependeny in the local
>> > > > repository.
>> > > >
>> > > > Suddenly there should be a bug fixing in V3! (So the frozen version
>> > > should
>> > > > be used to change something...)
>> > > > But, the changed dependency, described above, is in the local
>> > repository
>> > > > and is also be used from V3, what is wrong, because the frozen state
>> > used
>> > > > another version!
>> > > > (Another version can have some differences, where the build doesn't
>> > > break,
>> > > > but some different behaoviours can be in the software... so there
>> are
>> > > > unpredictable bugs!)
>> > > >
>> > > > Some possible solutions, and why they aren't real solutions:
>> > > >
>> > > > 1) clean the local repository before bug fixing V3:
>> > > > To fetch all dependencies from remote Repository V3 needs some time.
>> > And
>> > > > the developer must be able to switch beetween V3 and V4 very fast.
>> To
>> > > > clean and "reload" the local repository is to time-intensive, and if
>> > some
>> > > > changes are made in V4, and after that again in V3, the clean should
>> be
>> > > > made again and again....
>> > > > 2) change dependencies version-range to one version only:
>> > > > I have to look for all dependencies, transitive dependencies etc.
>> where
>> > > > some version ranges can be defined. This is to much to look for!
>> > > >
>> > > > So... If anythink is not described properly, please ask :-)
>> > >
>> > > Maybe you should reconsider your complete approach and start using
>> Maven
>> > > for
>> > > the version management instead of managing the versions by exchanging
>> > > repositories on your own. In this case Maven cannot help you and you
>> > > already face the problem. See, we use M2 now since years and we're now
>> -
>> > > compared to your numbering scheme - at V10. However, I don't have to
>> > clear
>> > > my local repo to switch between different code lines.
>> > >
>> > > Basically start using a parent POM that is global for your project
>> i.e.
>> > > every POM of your project will inherit either directly or indirectly
>> from
>> > > that one. Use in this global POM a dependencyMgmt section and define
>> > there
>> > > all your deps with fix versions. That's it. This global POM will
>> define
>> > > that for your complete project all the used versions everytime.
>> There's
>> > no
>> > > possibility anymore to get suddenly something else and this is
>> completely
>> > > independent from the stuff in your local repo.
>> > >
>> > > > I hope there is any solution for that problem...
>> > >
>> > > The location of the local repo is defined in the settings.xml. You can
>> > use
>> > > a
>> > > separate settings.xml, its name and location can be defined from the
>> > > command line.
>> > >
>> > > > Thanks if you are a this point! :-)
>> > >
>> > > No, I won't get there, because we take a different approach. You
>> should
>> > > really reconsider yours.
>> > >
>> > > - Jörg
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: users-help@maven.apache.org
>> > >
>> > >
>> >
>>
>
>
Re: dependency / version problem
Posted by Ketil Aasarød <ke...@gmail.com>.
Sorry for overlooking the version range for dep C in my earlier post.
Stephen is right. You should lock down the version of C from your pom
using dependencyManagement.
-ketil
2009/9/4 Stephen Connolly <st...@gmail.com>:
> Some help is available:
> http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html
>
> Just prior to doing a release, you will do the following:
>
> mvn versions:resolve-ranges
>
> This will turn all the ranges into the current version (it does not handle
> transitive... but if you file a JIRA, we can see about adding support in a
> later release)
>
> That will at least help somewhat.
>
> Then you use dependency:tree to find any extra transitives, and add those
> into your dependencyMgnt section...
>
> -Stephen
>
> 2009/9/4 Ketil Aasarød <ke...@gmail.com>
>
>> 2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>:
>> > sorry, that i'm so annoying ;-)
>> >
>> >>because this implies that at least one of the "fix" versions must have
>> been
>> >>changed.
>> >
>> > Thats not right (I think). Example:
>> >
>> > My dependency: DEP_A:1.0
>> > Dependency of DEP_A => DEP_B:2.3
>> > Dependency of DEP_B:2.3 => DEP_C:[1.0,)
>> >
>> > My dependency is fixed, and nothing changed.
>> > Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
>> > version, because the dependency allows newer versions.
>>
>> As long as your project depends on A:1.0, B:2.3 and C:1.0 will be
>> transitive dependencies. If C comes in a new version 1.1, your project
>> will still get C:1.0 as a transitive dependency. If B wants to use
>> C:1.1, B will come in a new version, say 2.4 that depends on C:1.1.
>> The only way for your project to be affected by the release of C:1.1
>> is that A has a new release that depends on B:2.4, and your project is
>> updated to depend on this new version of A.
>>
>> Do you understand the picture?
>>
>> -ketil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency / version problem
Posted by Stephen Connolly <st...@gmail.com>.
Some help is available:
http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html
Just prior to doing a release, you will do the following:
mvn versions:resolve-ranges
This will turn all the ranges into the current version (it does not handle
transitive... but if you file a JIRA, we can see about adding support in a
later release)
That will at least help somewhat.
Then you use dependency:tree to find any extra transitives, and add those
into your dependencyMgnt section...
-Stephen
2009/9/4 Ketil Aasarød <ke...@gmail.com>
> 2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>:
> > sorry, that i'm so annoying ;-)
> >
> >>because this implies that at least one of the "fix" versions must have
> been
> >>changed.
> >
> > Thats not right (I think). Example:
> >
> > My dependency: DEP_A:1.0
> > Dependency of DEP_A => DEP_B:2.3
> > Dependency of DEP_B:2.3 => DEP_C:[1.0,)
> >
> > My dependency is fixed, and nothing changed.
> > Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
> > version, because the dependency allows newer versions.
>
> As long as your project depends on A:1.0, B:2.3 and C:1.0 will be
> transitive dependencies. If C comes in a new version 1.1, your project
> will still get C:1.0 as a transitive dependency. If B wants to use
> C:1.1, B will come in a new version, say 2.4 that depends on C:1.1.
> The only way for your project to be affected by the release of C:1.1
> is that A has a new release that depends on B:2.4, and your project is
> updated to depend on this new version of A.
>
> Do you understand the picture?
>
> -ketil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: dependency / version problem
Posted by Ketil Aasarød <ke...@gmail.com>.
2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>:
> sorry, that i'm so annoying ;-)
>
>>because this implies that at least one of the "fix" versions must have been
>>changed.
>
> Thats not right (I think). Example:
>
> My dependency: DEP_A:1.0
> Dependency of DEP_A => DEP_B:2.3
> Dependency of DEP_B:2.3 => DEP_C:[1.0,)
>
> My dependency is fixed, and nothing changed.
> Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
> version, because the dependency allows newer versions.
As long as your project depends on A:1.0, B:2.3 and C:1.0 will be
transitive dependencies. If C comes in a new version 1.1, your project
will still get C:1.0 as a transitive dependency. If B wants to use
C:1.1, B will come in a new version, say 2.4 that depends on C:1.1.
The only way for your project to be affected by the release of C:1.1
is that A has a new release that depends on B:2.4, and your project is
updated to depend on this new version of A.
Do you understand the picture?
-ketil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency / version problem
Posted by Stephen Connolly <st...@gmail.com>.
DepB should not use a range, or else you should lock down depC in your
parent pom to a fixed version.
if your dependency: dep A has a fixed dependency on depB, then depB cannot
change, so you can sigure out all your current dependencies (dependency:tree
is your friend)
All you do is before you release, you add a depMgnt section locking down the
versions to the versions currently displayed using dependency:tree.
Now everything is locked down and no new transitive deps can be added
2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>
> sorry, that i'm so annoying ;-)
>
> >because this implies that at least one of the "fix" versions must have
> been
> >changed.
>
> Thats not right (I think). Example:
>
> My dependency: DEP_A:1.0
> Dependency of DEP_A => DEP_B:2.3
> Dependency of DEP_B:2.3 => DEP_C:[1.0,)
>
> My dependency is fixed, and nothing changed.
> Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
> version, because the dependency allows newer versions.
>
> U say, that this use case will neber happen? So Maven ignores version Range
> from DEP_B:2.3 to DEP_C ?
>
> If this is right, than thanks for all the comments ;-) And the my use case
> is really impossible...
>
>
> dave
>
Re: dependency / version problem
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Dave,
javadevdave@googlemail.com wrote at Freitag, 4. September 2009 12:10:
> sorry, that i'm so annoying ;-)
Hehehe ..
>>because this implies that at least one of the "fix" versions must have
>>been changed.
>
> Thats not right (I think). Example:
>
> My dependency: DEP_A:1.0
> Dependency of DEP_A => DEP_B:2.3
> Dependency of DEP_B:2.3 => DEP_C:[1.0,)
>
> My dependency is fixed, and nothing changed.
> Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
> version, because the dependency allows newer versions.
>
> U say, that this use case will neber happen? So Maven ignores version
> Range from DEP_B:2.3 to DEP_C ?
No, because DEP_C has not been fixed in fist place.
> If this is right, than thanks for all the comments ;-) And the my use case
> is really impossible...
Rule of thumb: All dependencies that end up somewhere in a war, ear or
assembly should have been locked down in the project's global POM. As
Stephen already suggested, use dependency:tree to get the current versions
in use.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency / version problem
Posted by "javadevdave@googlemail.com" <ja...@googlemail.com>.
sorry, that i'm so annoying ;-)
>because this implies that at least one of the "fix" versions must have been
>changed.
Thats not right (I think). Example:
My dependency: DEP_A:1.0
Dependency of DEP_A => DEP_B:2.3
Dependency of DEP_B:2.3 => DEP_C:[1.0,)
My dependency is fixed, and nothing changed.
Some day, there is a new Version of DEP_C, so DEP_B:2.3 use this new
version, because the dependency allows newer versions.
U say, that this use case will neber happen? So Maven ignores version Range
from DEP_B:2.3 to DEP_C ?
If this is right, than thanks for all the comments ;-) And the my use case
is really impossible...
dave
Re: dependency / version problem
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Dave,
javadevdave@googlemail.com wrote at Freitag, 4. September 2009 11:25:
> But all you described implies, that I know about this dependency. But I
> dont know the dependency, it can happen in any transitive dependency.
If you use fix versions for your dependencies in the depMgmt section, it is
no longer possible to introduce new/other transitive dependencies, because
this implies that at least one of the "fix" versions must have been
changed.
> Because attachements are not shown, i loaded the image to
> http://goliatmesh.go.funpic.de/mavenDependencyProblem.jpg
>
> Perhaps there is really something I didn't figure out, but I had a
> problem, similar to this already :-(
If your global project POM declares "a group:b:1.1.4" in the depMgmt
section, nothing else will be used - never.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency / version problem
Posted by "javadevdave@googlemail.com" <ja...@googlemail.com>.
But all you described implies, that I know about this dependency. But I dont
know the dependency, it can happen in any transitive dependency.
Because attachements are not shown, i loaded the image to
http://goliatmesh.go.funpic.de/mavenDependencyProblem.jpg
Perhaps there is really something I didn't figure out, but I had a problem,
similar to this already :-(
thanks...
2009/9/4 Jörg Schaible <jo...@gmx.de>
> Hi Dave,
>
> javadevdave@googlemail.com wrote at Freitag, 4. September 2009 10:53:
>
> > there is no picture? I added it to the first mail.. and i can see it as
> an
> > attachment... I try it again with that mail...
>
> Maybe you did not realize yet, that versions defined in a depMgmt section
> do
> always take precedence - even for transitive deps!
>
> > I already use Maven for complete Version Management.
> >
> >>Use in this global POM a dependencyMgmt section and define there
> >>all your deps with fix versions.
> >
> > And here is the problem. This is not possible because the problem I
> > described is a transitive dependency, I don't know! (Because its in any
> > dependency of another dependency...) So defining fix versions of the
> > "first"-direct dependency is ok (DEP_A). But if there are dependencies in
> > DEP_A (DEP_A->DEP_B) and DEP_B has some dependeny with open
> version-ranges
> > (DEP_Copen)...
> > then I cant influence this. And there is suddenly a new version of the
> > dependency (DEP_Copen) used by all versions of my project (V3,V4 etc.)..
> > and then there can be unpredictable bugs... (in an older tested version
> of
> > my project)
> >
> > I think the picture is very important to understand this use case, so I
> > add it again...
>
> That's the whole point, the problem you describe in your use case does not
> exist in this way.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: dependency / version problem
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Dave,
javadevdave@googlemail.com wrote at Freitag, 4. September 2009 10:53:
> there is no picture? I added it to the first mail.. and i can see it as an
> attachment... I try it again with that mail...
Maybe you did not realize yet, that versions defined in a depMgmt section do
always take precedence - even for transitive deps!
> I already use Maven for complete Version Management.
>
>>Use in this global POM a dependencyMgmt section and define there
>>all your deps with fix versions.
>
> And here is the problem. This is not possible because the problem I
> described is a transitive dependency, I don't know! (Because its in any
> dependency of another dependency...) So defining fix versions of the
> "first"-direct dependency is ok (DEP_A). But if there are dependencies in
> DEP_A (DEP_A->DEP_B) and DEP_B has some dependeny with open version-ranges
> (DEP_Copen)...
> then I cant influence this. And there is suddenly a new version of the
> dependency (DEP_Copen) used by all versions of my project (V3,V4 etc.)..
> and then there can be unpredictable bugs... (in an older tested version of
> my project)
>
> I think the picture is very important to understand this use case, so I
> add it again...
That's the whole point, the problem you describe in your use case does not
exist in this way.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency / version problem
Posted by "javadevdave@googlemail.com" <ja...@googlemail.com>.
there is no picture? I added it to the first mail.. and i can see it as an
attachment... I try it again with that mail...
I already use Maven for complete Version Management.
>Use in this global POM a dependencyMgmt section and define there
>all your deps with fix versions.
And here is the problem. This is not possible because the problem I
described is a transitive dependency, I don't know! (Because its in any
dependency of another dependency...) So defining fix versions of the
"first"-direct dependency is ok (DEP_A). But if there are dependencies in
DEP_A (DEP_A->DEP_B) and DEP_B has some dependeny with open version-ranges
(DEP_Copen)...
then I cant influence this. And there is suddenly a new version of the
dependency (DEP_Copen) used by all versions of my project (V3,V4 etc.).. and
then there can be unpredictable bugs... (in an older tested version of my
project)
I think the picture is very important to understand this use case, so I add
it again...
thanks...
Dave
2009/9/4 Stephen Connolly <st...@gmail.com>
> 1. you refer to a non-existant picture
>
> 2. Jorg's solution is the way to go.
>
> -Stephen
>
> 2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>
>
> > Hi!
> >
> > Thanks for the complete answer.
> > I think i described it a bit inconclusive. But the approach you described
> > will also not solve the problem:
> > because:
> > the dependency i described can be transitive! (I dont know every
> dependency
> > - for example - of spring, so it's impossible for me to check every
> > version-range of every dependency of spring ...)
> > So.. if I have one parent pom for all the different versions of the
> > project,
> > there is still the problem, that some version range in any dependency
> (like
> > in the sample of my picture)
> > - not defined by myself (a transitive from any third party) -
> > influence all versions!! (because the newest version is used, and the
> > newest
> > version is first searched in the local repo - for all project versions)
> >
> > To define different local repos for every project Version is possible,
> but
> > then there are some problems with automatic build (after storing changed
> > code) in M2Eclipse, because you cant give maven-parameters with it.
> >
> > I hope it's a bit clearer...
> >
> > thanks
> >
> >
> > 2009/9/4 Jörg Schaible <jo...@gmx.de>
> >
> > > Hi,
> > >
> > > javadevdave@googlemail.com wrote at Freitag, 4. September 2009 09:38:
> > >
> > > > Hi all!
> > > >
> > > > My problem is not easy to describe :-) But i try it...
> > > > I have add a picture to this mail, where the situation is painted..
> > > >
> > > > The Situation:
> > > >
> > > > There are two versions of my project.
> > > > - Version 3: This version is in production and has been frozen. (the
> > > > repository for V3 is offline, that no changes from dependencies can
> > make
> > > > trouble...)
> > > > - Version 4: This is the actual developed Version. It usees another
> > > remote
> > > > Repository because some dependencies changed.
> > > >
> > > > Using eclipse M2 plugin for developing.
> > > >
> > > > The Problem:
> > > >
> > > > All dependencies (from V3 and V4) are at the same time in the local
> > > > repository. And there is one special dependency (can also be
> > transitive)
> > > > with no fixed version. (red circle in painting)
> > > > In V4 there was created a new Version for that dependency (from a
> third
> > > > party! But i didn't recocnize, because maven fetch it automaticly!!)
> > > > Now, there is also a new Version of that dependeny in the local
> > > > repository.
> > > >
> > > > Suddenly there should be a bug fixing in V3! (So the frozen version
> > > should
> > > > be used to change something...)
> > > > But, the changed dependency, described above, is in the local
> > repository
> > > > and is also be used from V3, what is wrong, because the frozen state
> > used
> > > > another version!
> > > > (Another version can have some differences, where the build doesn't
> > > break,
> > > > but some different behaoviours can be in the software... so there are
> > > > unpredictable bugs!)
> > > >
> > > > Some possible solutions, and why they aren't real solutions:
> > > >
> > > > 1) clean the local repository before bug fixing V3:
> > > > To fetch all dependencies from remote Repository V3 needs some time.
> > And
> > > > the developer must be able to switch beetween V3 and V4 very fast. To
> > > > clean and "reload" the local repository is to time-intensive, and if
> > some
> > > > changes are made in V4, and after that again in V3, the clean should
> be
> > > > made again and again....
> > > > 2) change dependencies version-range to one version only:
> > > > I have to look for all dependencies, transitive dependencies etc.
> where
> > > > some version ranges can be defined. This is to much to look for!
> > > >
> > > > So... If anythink is not described properly, please ask :-)
> > >
> > > Maybe you should reconsider your complete approach and start using
> Maven
> > > for
> > > the version management instead of managing the versions by exchanging
> > > repositories on your own. In this case Maven cannot help you and you
> > > already face the problem. See, we use M2 now since years and we're now
> -
> > > compared to your numbering scheme - at V10. However, I don't have to
> > clear
> > > my local repo to switch between different code lines.
> > >
> > > Basically start using a parent POM that is global for your project i.e.
> > > every POM of your project will inherit either directly or indirectly
> from
> > > that one. Use in this global POM a dependencyMgmt section and define
> > there
> > > all your deps with fix versions. That's it. This global POM will define
> > > that for your complete project all the used versions everytime. There's
> > no
> > > possibility anymore to get suddenly something else and this is
> completely
> > > independent from the stuff in your local repo.
> > >
> > > > I hope there is any solution for that problem...
> > >
> > > The location of the local repo is defined in the settings.xml. You can
> > use
> > > a
> > > separate settings.xml, its name and location can be defined from the
> > > command line.
> > >
> > > > Thanks if you are a this point! :-)
> > >
> > > No, I won't get there, because we take a different approach. You should
> > > really reconsider yours.
> > >
> > > - Jörg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: dependency / version problem
Posted by Stephen Connolly <st...@gmail.com>.
1. you refer to a non-existant picture
2. Jorg's solution is the way to go.
-Stephen
2009/9/4 javadevdave@googlemail.com <ja...@googlemail.com>
> Hi!
>
> Thanks for the complete answer.
> I think i described it a bit inconclusive. But the approach you described
> will also not solve the problem:
> because:
> the dependency i described can be transitive! (I dont know every dependency
> - for example - of spring, so it's impossible for me to check every
> version-range of every dependency of spring ...)
> So.. if I have one parent pom for all the different versions of the
> project,
> there is still the problem, that some version range in any dependency (like
> in the sample of my picture)
> - not defined by myself (a transitive from any third party) -
> influence all versions!! (because the newest version is used, and the
> newest
> version is first searched in the local repo - for all project versions)
>
> To define different local repos for every project Version is possible, but
> then there are some problems with automatic build (after storing changed
> code) in M2Eclipse, because you cant give maven-parameters with it.
>
> I hope it's a bit clearer...
>
> thanks
>
>
> 2009/9/4 Jörg Schaible <jo...@gmx.de>
>
> > Hi,
> >
> > javadevdave@googlemail.com wrote at Freitag, 4. September 2009 09:38:
> >
> > > Hi all!
> > >
> > > My problem is not easy to describe :-) But i try it...
> > > I have add a picture to this mail, where the situation is painted..
> > >
> > > The Situation:
> > >
> > > There are two versions of my project.
> > > - Version 3: This version is in production and has been frozen. (the
> > > repository for V3 is offline, that no changes from dependencies can
> make
> > > trouble...)
> > > - Version 4: This is the actual developed Version. It usees another
> > remote
> > > Repository because some dependencies changed.
> > >
> > > Using eclipse M2 plugin for developing.
> > >
> > > The Problem:
> > >
> > > All dependencies (from V3 and V4) are at the same time in the local
> > > repository. And there is one special dependency (can also be
> transitive)
> > > with no fixed version. (red circle in painting)
> > > In V4 there was created a new Version for that dependency (from a third
> > > party! But i didn't recocnize, because maven fetch it automaticly!!)
> > > Now, there is also a new Version of that dependeny in the local
> > > repository.
> > >
> > > Suddenly there should be a bug fixing in V3! (So the frozen version
> > should
> > > be used to change something...)
> > > But, the changed dependency, described above, is in the local
> repository
> > > and is also be used from V3, what is wrong, because the frozen state
> used
> > > another version!
> > > (Another version can have some differences, where the build doesn't
> > break,
> > > but some different behaoviours can be in the software... so there are
> > > unpredictable bugs!)
> > >
> > > Some possible solutions, and why they aren't real solutions:
> > >
> > > 1) clean the local repository before bug fixing V3:
> > > To fetch all dependencies from remote Repository V3 needs some time.
> And
> > > the developer must be able to switch beetween V3 and V4 very fast. To
> > > clean and "reload" the local repository is to time-intensive, and if
> some
> > > changes are made in V4, and after that again in V3, the clean should be
> > > made again and again....
> > > 2) change dependencies version-range to one version only:
> > > I have to look for all dependencies, transitive dependencies etc. where
> > > some version ranges can be defined. This is to much to look for!
> > >
> > > So... If anythink is not described properly, please ask :-)
> >
> > Maybe you should reconsider your complete approach and start using Maven
> > for
> > the version management instead of managing the versions by exchanging
> > repositories on your own. In this case Maven cannot help you and you
> > already face the problem. See, we use M2 now since years and we're now -
> > compared to your numbering scheme - at V10. However, I don't have to
> clear
> > my local repo to switch between different code lines.
> >
> > Basically start using a parent POM that is global for your project i.e.
> > every POM of your project will inherit either directly or indirectly from
> > that one. Use in this global POM a dependencyMgmt section and define
> there
> > all your deps with fix versions. That's it. This global POM will define
> > that for your complete project all the used versions everytime. There's
> no
> > possibility anymore to get suddenly something else and this is completely
> > independent from the stuff in your local repo.
> >
> > > I hope there is any solution for that problem...
> >
> > The location of the local repo is defined in the settings.xml. You can
> use
> > a
> > separate settings.xml, its name and location can be defined from the
> > command line.
> >
> > > Thanks if you are a this point! :-)
> >
> > No, I won't get there, because we take a different approach. You should
> > really reconsider yours.
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: dependency / version problem
Posted by "javadevdave@googlemail.com" <ja...@googlemail.com>.
Hi!
Thanks for the complete answer.
I think i described it a bit inconclusive. But the approach you described
will also not solve the problem:
because:
the dependency i described can be transitive! (I dont know every dependency
- for example - of spring, so it's impossible for me to check every
version-range of every dependency of spring ...)
So.. if I have one parent pom for all the different versions of the project,
there is still the problem, that some version range in any dependency (like
in the sample of my picture)
- not defined by myself (a transitive from any third party) -
influence all versions!! (because the newest version is used, and the newest
version is first searched in the local repo - for all project versions)
To define different local repos for every project Version is possible, but
then there are some problems with automatic build (after storing changed
code) in M2Eclipse, because you cant give maven-parameters with it.
I hope it's a bit clearer...
thanks
2009/9/4 Jörg Schaible <jo...@gmx.de>
> Hi,
>
> javadevdave@googlemail.com wrote at Freitag, 4. September 2009 09:38:
>
> > Hi all!
> >
> > My problem is not easy to describe :-) But i try it...
> > I have add a picture to this mail, where the situation is painted..
> >
> > The Situation:
> >
> > There are two versions of my project.
> > - Version 3: This version is in production and has been frozen. (the
> > repository for V3 is offline, that no changes from dependencies can make
> > trouble...)
> > - Version 4: This is the actual developed Version. It usees another
> remote
> > Repository because some dependencies changed.
> >
> > Using eclipse M2 plugin for developing.
> >
> > The Problem:
> >
> > All dependencies (from V3 and V4) are at the same time in the local
> > repository. And there is one special dependency (can also be transitive)
> > with no fixed version. (red circle in painting)
> > In V4 there was created a new Version for that dependency (from a third
> > party! But i didn't recocnize, because maven fetch it automaticly!!)
> > Now, there is also a new Version of that dependeny in the local
> > repository.
> >
> > Suddenly there should be a bug fixing in V3! (So the frozen version
> should
> > be used to change something...)
> > But, the changed dependency, described above, is in the local repository
> > and is also be used from V3, what is wrong, because the frozen state used
> > another version!
> > (Another version can have some differences, where the build doesn't
> break,
> > but some different behaoviours can be in the software... so there are
> > unpredictable bugs!)
> >
> > Some possible solutions, and why they aren't real solutions:
> >
> > 1) clean the local repository before bug fixing V3:
> > To fetch all dependencies from remote Repository V3 needs some time. And
> > the developer must be able to switch beetween V3 and V4 very fast. To
> > clean and "reload" the local repository is to time-intensive, and if some
> > changes are made in V4, and after that again in V3, the clean should be
> > made again and again....
> > 2) change dependencies version-range to one version only:
> > I have to look for all dependencies, transitive dependencies etc. where
> > some version ranges can be defined. This is to much to look for!
> >
> > So... If anythink is not described properly, please ask :-)
>
> Maybe you should reconsider your complete approach and start using Maven
> for
> the version management instead of managing the versions by exchanging
> repositories on your own. In this case Maven cannot help you and you
> already face the problem. See, we use M2 now since years and we're now -
> compared to your numbering scheme - at V10. However, I don't have to clear
> my local repo to switch between different code lines.
>
> Basically start using a parent POM that is global for your project i.e.
> every POM of your project will inherit either directly or indirectly from
> that one. Use in this global POM a dependencyMgmt section and define there
> all your deps with fix versions. That's it. This global POM will define
> that for your complete project all the used versions everytime. There's no
> possibility anymore to get suddenly something else and this is completely
> independent from the stuff in your local repo.
>
> > I hope there is any solution for that problem...
>
> The location of the local repo is defined in the settings.xml. You can use
> a
> separate settings.xml, its name and location can be defined from the
> command line.
>
> > Thanks if you are a this point! :-)
>
> No, I won't get there, because we take a different approach. You should
> really reconsider yours.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: dependency / version problem
Posted by Jörg Schaible <jo...@gmx.de>.
Hi,
javadevdave@googlemail.com wrote at Freitag, 4. September 2009 09:38:
> Hi all!
>
> My problem is not easy to describe :-) But i try it...
> I have add a picture to this mail, where the situation is painted..
>
> The Situation:
>
> There are two versions of my project.
> - Version 3: This version is in production and has been frozen. (the
> repository for V3 is offline, that no changes from dependencies can make
> trouble...)
> - Version 4: This is the actual developed Version. It usees another remote
> Repository because some dependencies changed.
>
> Using eclipse M2 plugin for developing.
>
> The Problem:
>
> All dependencies (from V3 and V4) are at the same time in the local
> repository. And there is one special dependency (can also be transitive)
> with no fixed version. (red circle in painting)
> In V4 there was created a new Version for that dependency (from a third
> party! But i didn't recocnize, because maven fetch it automaticly!!)
> Now, there is also a new Version of that dependeny in the local
> repository.
>
> Suddenly there should be a bug fixing in V3! (So the frozen version should
> be used to change something...)
> But, the changed dependency, described above, is in the local repository
> and is also be used from V3, what is wrong, because the frozen state used
> another version!
> (Another version can have some differences, where the build doesn't break,
> but some different behaoviours can be in the software... so there are
> unpredictable bugs!)
>
> Some possible solutions, and why they aren't real solutions:
>
> 1) clean the local repository before bug fixing V3:
> To fetch all dependencies from remote Repository V3 needs some time. And
> the developer must be able to switch beetween V3 and V4 very fast. To
> clean and "reload" the local repository is to time-intensive, and if some
> changes are made in V4, and after that again in V3, the clean should be
> made again and again....
> 2) change dependencies version-range to one version only:
> I have to look for all dependencies, transitive dependencies etc. where
> some version ranges can be defined. This is to much to look for!
>
> So... If anythink is not described properly, please ask :-)
Maybe you should reconsider your complete approach and start using Maven for
the version management instead of managing the versions by exchanging
repositories on your own. In this case Maven cannot help you and you
already face the problem. See, we use M2 now since years and we're now -
compared to your numbering scheme - at V10. However, I don't have to clear
my local repo to switch between different code lines.
Basically start using a parent POM that is global for your project i.e.
every POM of your project will inherit either directly or indirectly from
that one. Use in this global POM a dependencyMgmt section and define there
all your deps with fix versions. That's it. This global POM will define
that for your complete project all the used versions everytime. There's no
possibility anymore to get suddenly something else and this is completely
independent from the stuff in your local repo.
> I hope there is any solution for that problem...
The location of the local repo is defined in the settings.xml. You can use a
separate settings.xml, its name and location can be defined from the
command line.
> Thanks if you are a this point! :-)
No, I won't get there, because we take a different approach. You should
really reconsider yours.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org