On Fri, 2002-03-29 at 14:31, Jon Scott Stevens wrote: > Hey jason, > > What do you think of the idea of server controlled versioning. In other > words, instead of putting the version numbers of the .jar files in > deps.list, the system would instead connect to the server > (jakarta.apache.org) and get the version numbers.
But the version numbers have to come from somewhere originally. I don't like the deps.list either. Dependency ids and version are stored in the POM, right now the project.xml file. That version information has to be stored at the project level in order for versioning to be coherent. > This way, all you have to do is list the dependencies and you never have to > worry about updating a bazillion deps.list files every time a new version of > the software comes out (you simply update it on the server). You have to update the id for a dependency and the version, there's no way around it. Right now it is crappy hack having the actual name of the JAR in the <dependency> entries, all you should need is the id and the version. > When you run > update-jar's, it will download the correct versions of the files based on > the version number that update-jar's sends to the server. Or, what is outlined above the update-jars pulls down the correct JARs based on the version numbers in the <dependency> entries in the project.xml file. > One could also do cool things like have it be that if someone is building a > project from cvs head (and update-jar's sends a -dev version number), then > update-jar's would download the jar files which were built from gump the > night before (or something like that)... That's definitely part of the plan. Being able to build arbitrarily against sources or binaries (of whatever flavour) can definitely be implemented. > The idea is to still keep the dependencies locally defined, but keep the > versioning centrally defined. Makes for less maintenance. For a particular project if you have a dependency on A version 1, I don't see what the advantage of server stored versioning would be to storing both the id and version in the project.xml file. I think there is actually a distinct disadvantage. If I make changes locally and decide that it's time to move to A version 2 then when I'm finished making my changes I will update the project.xml file accordingly and commit and push whatever new required JARs up to the central repository. When someone updates the next time that information can be used to pull down the newly required JARs and build. Again, remember that the <name> of the JAR in the project.xml file and the full name in the deps.list is a kludge. I think keeping the dependency id and version in separate locations can lead to problems in the server versioning scenerio where I have: a) Changed from using A version 1 to A version 2 b) Commit changes to CVS that require A version 2 c) Update the server with new versioning information Then a user updates CVS successfully but the something goes wrong with the service providing the versioning information. The user now has code that depends on A version 2 but can't build it because the build system is stuck with A version 1. If all the information is stored in the project.xml file then if they can't update from CVS then they will still be able to build, and when they can update all the information they need to build with new version will be present. I believe this makes things more coherent and also eliminates step c) above. > -jon > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
