2009/9/4 javadevd...@googlemail.com <javadevd...@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 <stephen.alan.conno...@gmail.com> > > 1. you refer to a non-existant picture >> >> 2. Jorg's solution is the way to go. >> >> -Stephen >> >> 2009/9/4 javadevd...@googlemail.com <javadevd...@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 <joerg.schai...@gmx.de> >> > >> > > Hi, >> > > >> > > javadevd...@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-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: users-h...@maven.apache.org >> > > >> > > >> > >> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
