Thanks everyone for getting and keeping the ball rolling on this. I will
try to follow the conversation as a non-maven user, and add comments
that i hope will be helpful.
On 11/1/2010 1:22 PM, Martin Desruisseaux wrote:
Hello all
Le 30/10/10 03:07, Mattmann, Chris A (388J) a écrit :
Hi Guys,
Attached is a patch file that integrates deployment to Maven Central
into your
build. It currently relies on my own Sonatype free OSS hosting
account, which is
one of the forges that is synced to Maven Central.
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).
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/
This requires that opendap and bufrTables dependencies are deployed
separatly, but this seems a necessary step 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?
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).
Regards,
Martin Desruisseaux
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
I recently did a survey of how developers use the jar files. A large
majority prefer the "all-in-one" jar, and a significant minority want to
pick and choose.
So it might make sense to let us deliver the all-in-one jar and variants
on our site, and let maven handle the dependencies in the optimal way
for maven users.
Having said that, there are various worms in the individual cans, er,
jars. For example, standard Visad delivers an old and (I think)
conflicting version of opendap. So we have to unpack it and remove that
into our "VisadNoDods.jar". Perhaps a better thing for us to do is to
rename the packages to eliminate the conflict.
