Le 02/11/10 18:24, John Caron a écrit :
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.
Of course you comments are highly wanted :)
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.
Yes, I like this approach. This is exactly what we did for our project. We
splitted the domain in two parts, "maven" and "download":
* Fine-grained JAR files on http://maven.etc...
* "All-in-one" JAR (actually PACK200) files on http://download.etc...
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.
If there is no other change than the removal of OpenDap, I think this is okay.
If all this discussion was about deploying VisAD instead than NetCDF, we would
still have to separate VisAD from OpenDap for deployment on the Maven central
repository.
Where does this opendap come from, and how do I figure that out? We have a
forked version of opendap.*; the one from opendap.org is not being developed by
them.
The OpenDap deployed on http://maven.geotoolkit.org/org/opendap/opendap/2.2/ is
the one which was provided inside the netcdfAll-4.2.zip file. I put it in the
"org.opendap" groupId because I though it was the same than the one on
http://www.opendap.org/. If this is not the case, then we need to change the
groupId for "edu.ucar". No other changes are required as far as I know, while
maybe a change in package name would be safer.
Regards,
Martin
