Hi Martin,
> Having NetCDF on the central Maven repository is nice, but...
>
> The deployed file (http://repo1.maven.org/maven2/edu/ucar/netcdf/4.2/) is the
> full NetCDF file (11 Mb) with most of its dependencies, including:
>
> * jdom
> * commons-httpclient
> * commons-codec
> * commons-logging
>
> (not mentioning Visad, Opendap and others). All the dependencies listed above
> are already deployed on the Maven central repository, and often imported by
> projects using both NetCDF and JDOM (for example) together. Having those
> dependencies bundled in the NetCDF.jar file is both a duplication and a
> possible
> hard-to-debug cause of conflict (especially if a project declares different
> version of those dependencies).
Agreed, I didn't see all of the included deps in Maven Central (e.g., Grib,
and OPeNDAP), though.
>
> A better way to process would have been to deploy only the core NetCDF file
> (3.9
> Mb) rather the full 11 Mb JAR file, and to declare the dependencies in its
> pom.xml. I have already done this work just a few days before, please look at
> the files there (especially the "dependency" section of the netcdf-4.2.pom
> file):
>
> http://maven.geotoolkit.org/edu/ucar/netcdf/4.2/
Interesting. So, is there an SVN somewhere else besides the SVN [1] that is
linked on this page [2]? Are all of the jars listed in that netcdf-4.2.pom
available on Maven Central?
>
> This requires that opendap and bufrTables dependencies are deployed separatly,
> but this seems a necessary step to me.
That's fine, but the restriction for putting jars into Maven Central is that
any referenced dependencies must be available in Central as well. That's why
a singleton uber jar with all dependencies included seemed like a viable
option to me.
>
> Can we fix the deployment on the central repository, at the very least for
> removing the above-listed dependencies and declare them as normal Maven
> dependencies instead?
I can, as long as those dependencies are available via Central. Are they? If
not, we can file issues and make them available using the same process, but
it's going to take longer. We're trying to cut an Apache Tika 0.8 release
and having NetCDF available from Maven Central is a blocker to that release .
If we don't have it, we either have to disable NetCDF from Tika (which would
erase or put on hold a bunch of work I've done), or get all the deps that
we're missing in Central up there and delay the release even further.
I sent an email many months ago on this topic and I've been working the
process little by little, as I've had time available.
>
> We should also merge the pom.xml file that you created (which contains a nice
> list of developers) with the one that I created (which contains information
> about mailing list, and a more appropriate list of dependencies).
Sure, good idea.
I'm happy to deploy an update to Maven Central, I just need to make sure the
deps we reference in the POM are available there.
One other thing I noticed: can we remove the Java6 dependencies on some of
the class files (e.g., ucar.unidata.uitl.Format)? If not, that's OK, but
just wondering.
Cheers,
Chris
[1] http://svn.unidata.ucar.edu/repos/thredds/trunk/
[2] http://www.unidata.ucar.edu/software/netcdf-java/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@xxxxxxxxxxxx
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
