> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: mercredi 23 mars 2005 09:41 > To: Maven 2 Developers List > Subject: Re: SNAPSHOT design > > Vincent Massol wrote: > > >Cool. At first reading the systematic use of snapshot timestamp and the > >juggling of format between local and remote repos seemed too much of > magic > >to me. I now understand this may be the only solution for clock issues. > > > > > This is all pretty well hidden - the user should just specify SNAPSHOT > in their dependencies and it will just work.
Yes, that's good. That also means that the repository is no longer open and that you have to use tools to use it. This is good as it allows adding more advanced feature to it. At the same time it makes it a little bit less ubiquitous. There's probably a good tradeoff to find but I don't think this proposal is crossing it yet, so that's good! ;-) > >I think a version.txt file may be required not only for snapshots but > also > >for proper release versions so that the user can specify a dependency > that > >is greater than a certain number (ex: 1.7+ or >1.7). Is it the plan to > have > >another file for it? Wouldn't it be better to merge the 2 files into one? > > > > > I'd imagine that they would be treated like SNAPSHOTs if implemented as > they are also unresolved versions - but I don't want to go too far down > that track yet. > > To be honest, I'm not entirely certain we should implement this in the > short term. It's dangerous when versioning is not done right. What we're > better to do is make it easier to globally change a dependency version > which is what dependencyManagement is about so you can have careful > control of the dependency version in play. The use case that I've encountered several times is the following: - One of my projects needs to use a given plugin with a version higher than X because it depends on features introduced or bugs corrected in version X. Initially I had created a fixed dependency on version X but then as new plugins are released it's a pain to keep up with the dependency and have to update them to X+1, etc. If they stay at X I get emails from users of my projects asking why such feature does not work as it is present in version X+1 of the dependent plugin, etc. In the end, I had to remove the dependency and instead hard code a check in maven.xml: http://rafb.net/paste/results/5hvNM072.html It's not that bad but it's a bit of a pain. Also, I'd love to be able to depend on the last released version of a given dependency. That'll allow my continuous build to automatically find out if there's a compatibility issue with the latest released dependencies, a la Gump. Maybe this is a feature of Continuum but still it impacts the layout of the remote repository. I guess this is not really a must-have for the first alpha or beta of m2 but I think it makes sense to have it in before a final m2. Thanks -Vincent
