Hi Martin, Chris:
On 12/9/2010 3:29 PM, Martin Desruisseaux wrote:
Hello Jon
I would like some guidance from UCAR representative. In order to get a
NetCDF deployment on Maven Central that I can use for the
Geotoolkit.org project, I need the NetCDF pom.xml files to declare
their dependencies as accurately as possible (as opposed to grouping
many dependencies in the same JAR file).
In my effort to get "correct" pom.xml declarations, I found easier to
mavenize for real the NetCDF project. Note that it doesn't affect your
current Ant scripts, since both build systems can live in parallel.
However, if you agree, I need your advise on some details (mostly
naming question):
1) All artifacts would be in the "edu.ucar" groupId.
Is that all right?
ok
2) Since there is many modules (netcdf, grib, opendap, etc.), I need
a parent pom.xml where information like version numbers can be
declared only once. We need an artifactId for that. I took the
"unidata" name. Is that all right?
ok
This "unidata" artifact would be the basis of all NetCDF-related
modules (including opendap, grib...), and eventually all Unidata
Java softwares if you choose to extends its use that way.
3) The unidata parent currently declares the following modules:
- unidataCommon
- common
- grib
- opendap
- netcdf (work in progress - this is the "cdm" directory)
3a) The source code for unidataCommon is currently not versioned on
http://svn.unidata.ucar.edu/repos/thredds/trunk/. Would it be
possible to put it there? It would make the task easier for
mavenizing the project.
ok
3b) Can "common" be merged with "unidataCommon"? If not, do you
have a more explicit name to suggest? (maybe netcdfCommon?)
I have seen that the build.xml script performs some trick for
adding the "common" directory to the netcdf build, but we can
not do that in Maven if the common classes are used by both
"netcdf" (a.k.a. "cdm") and "grib" modules, since Maven does
not allow cyclic dependency.
this problem of cyclic dependencies is vexing. we divide things into
modules in order to allow features to be optional, not because they are
used in standalone mode. We use reflection in some key places for
optional class loading.
Now, if any of these modules needs something from another, maven
requires you to push that code (and its dependencies) down into a common
module.
I need to think about this some more. Also Im wondering if/how OGSi
and/or Project Jigsaw changes anything.
The current pom.xml proposal are there:
http://hg.geotoolkit.org/netcdf-deploy/file/tip
the list of developers should probably be trimmed.
im unclear how this ties into our svn repository. we would add these
poms to that?
Regards,
Martin
thanks much for your efforts,
John
