Bah hit send too soon - comments inline. > Just a suggestion for the net.refractions.udig.libs bundle right here. > In some projects we set the version of the OSGi-fied bundle to the > main characteristic version of the bundled jars. Means for this > example and the current version of geotools the libs-bundle would get > the version 8.RC1. Good thing is, everybody knows what's in the libs > bundle ;) > >
I would rather rename it org.geotools with a version of 8.0.0.timestamp as appropriate. > And an other suggestion for the libs bundle. With the > maven-dependency-plugin Plugin and the naming/versioning convention > mentioned above its possible to set the configuration value > <stripVersion>true</stripVersion> > > We did that previously (with maven ant tasks) and it resulted in a nightmare as developers tried to hunt down what was what. Not so bad for the top level geotools dependencies (now that the project keeps the version numbers in sync) - but for the transitive dependencies like apache-commons and miglayout the version number is useful. > As a result the internal jars (in lib folder) wouldn't have versions > numbers anymore, the developers would not have any trouble with > classpath and manifest anymore, except some dependencies were added or > libs have additional transitive dependencies. > > Interesting; could we only stripVersion on the geotools jars? > And last but not least we should start working with version ranges in > the bundles Manifest (Require-Bundle), for example in Manifest: > > That sounds fine; although we tend to not have that many direct dependencies on net.refractions.udig.libs - as we often "re-export" dependencies. Jody
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
