Cory Horner wrote: > Martin Desruisseaux wrote: > > The current repository (with the exception of _share and old-m2-repo) > has been rebuilt from scratch using the mvn deploy:deploy-file command > (via > http://svn.geotools.org/geotools/trunk/scripts/deploy_dependencies.sh). > Only a handful of jars have been manually copied in and i'm not > convinced this is really a problem. However, you are correct in that > this is not a "proper" way to manage a maven 2 repository. There is > rumour of a plugin in the works to regenerate the maven-metadata files > -- so *maybe* we'll allow copy-paste one day. > >> * The Refractions repository has strange versions number. For example >> it contains Geotools >> release versionned as "2.2-RC4-SNAPSHOT". Is it really correct? I >> would expect "2.2-RC4" >> and "2.2-SNAPSHOT" as two separated direction. >> > The refractions version numbers are correct: 2.2-RC4 is an actual > release and 2.2-RC4-SNAPSHOT is a snapshot. The 2.2.x snapshots do not > have timestamps because of the pom settings: > > <distributionManagement> > <repository> > <uniqueVersion>false</uniqueVersion> > <id>refractions</id> > <name>Refractions Research Repository</name> > <url>dav:http://lists.refractions.net/m2</url> > </repository> > </distributionManagement> > > Please note "uniqueVersion" is false. For uDig at least, we don't use > maven 2 and don't want weird timestamped file names; if we want a stable > version to work against we should do a release -- otherwise we simply > work off of the latest snapshot. I believe it is maven nudging us to > use 2.2-RC4-SNAPSHOT rather than 2.2-SNAPSHOT.
Correct. When I was making the 2.2-RC3 release, maven defaulted to wanting to make the next release version '2.2-RC4-SNAPSHOT' rather than our standard '2.2-SNAPSHOT', so I let it. I think it is a better and more explicit way of doing it too. > >> * The Refractions repository duplicates some files already present on >> Ibiblio. >> For example postgresql, commons-lang, etc. Do we really want to >> duplicate Ibiblio? I >> admit that Ibiblio is often unreliable, but we need to connect to >> that only for new >> dependencies. >> >> > This is up for debate :) > > Frankly it's a bit embarrassing explaining to users that it is normal > for the GeoTools build system to explode the first few times you run > it... thoughts? > >> I would like to suggest the following approach: >> >> * We rename the current "m2" directory into (yet an other) >> "old-m2-repo". >> >> * I send to someone (Richard?) a ZIP file containing the whole >> repository currently >> on maven.geotools.fr, which is (I think) a little bit cleaner and >> also has more >> history (2.2-RC1, 2.2-RC2, etc., which are not on the Refractions >> repository). >> Richard would just need to unzip it in a fresh "m2" directory. I >> can't do this >> step myself, since WebDav doesn't seems to work on my Windows XP >> machine. >> >> > I think the trick on windows was hitting ok the first time and cancel > the second time it asks for a password. > > I agree that we should add these releases. We can log-in and scp your > repo. I'm going to make the deploy_dependencies script a little bit > smarter (automatically generate a pom if one doesn't exist) -- the only > requirement it has is that you already have your jars installed in your > local repository. Starting with Martin's repo as a base, I can > re-deploy the contents of the repository very quickly. If we add the > files people need to the end of the script this can be rather painless > (i guess i'll just add everything currently in the repo?). > > If this sounds good to everyone i'll likely attack this later this > afternoon. This sounds good to me. Cheers, Richard Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
