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