On 11/2/2010 5:15 AM, Martin Desruisseaux wrote:
Le 02/11/10 07:07, Mattmann, Chris A (388J) a écrit :
I think that the NetCDF community though has to decide if it wants to
continue with the Ant build or to simply use Maven. I'm staying out
of that
holy war :) Either way we can integrate and publish to Maven Central.
I'm obviously among those we think that a Maven build would be nice,
but I'm actually neutral as long as the NetCDF files make their way to
a Maven repository in one way or an other.
I think there is an advantage however of having an uber jar at
Central, but
maybe I should name the artifact something different, like
netcdf-4.2-with-dependencies.jar or something of that nature.
What about "netcdf-all" to be consistent with the naming scheme
already in use on UCAR download area?
However I think that there is little advantage to put everything in
the same JAR file when using Maven (quite the opposite, it can makes
dependency management and convergence analysis more difficult). For
Maven users, having one or many JAR files is transparent. I rather see
"netcdf-all" as a pom.xml file just listing "netcdf" and all
dependencies in its "<dependencies>" section. So a Maven project that
depends on "netcdf-all" get everything.
If someone really wants a single JAR file with everything in it, I
would assume that he is not using Maven, so maybe he would be fine to
download the big JAR file from the UCAR download area?
Regards,
Martin
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
Ok, ive caught up (sort of) with this thread, so let me summarize some
of the issues from my POV:
1) forked/variant libraries.
opendap is the main problem here. probably could be solved by
versioning, or by a package name change
2) version dependencies are not clear
we dont use versions to manage our dependencies, so we havent kept
up with this. however, theres no reason we cant do this better for
stable releases.
3) code partitioning
we break up our code into several pieces to allow smaller
footprints, not because the code is independent or can be used
stand-alone. This is quite different from using third-party libraries.
In this category are:
- grib
- bufrTables
- opendap
4) artifact creation
we did follow maven directory layout mostly, but not one src tree
== one artifact. One reason we stayed with ant was to allow arbitrary
artifact creation. I would need to know how this is done in maven.
It would be helpful for Unidata to manage the pom.xml so others dont
have to guess at the dependencies. However, it will take some time to
fit this into our development, and im not sure how to best solve some of
these issues.
