Re: [netcdf-java] [netcdfgroup] NetCDF jars=>Maven Central Repos?

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.




  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: