Hi Martin,
Thanks. Comments inline below:
>>> * opendap: http://maven.geotoolkit.org/org/opendap/opendap/2.2/
>>> * bufrTables: http://maven.geotoolkit.org/edu/ucar/bufrTables/2.0u1/
>>> * unidatacommon: http://maven.geotoolkit.org/edu/ucar/unidatacommon/4.2/
>>
>> Where is the source for these pom files? Or, is this included with the
>> NetCDF source? Can you point me in SVN to where the source lives?
>
> I just pushed the files on our public server for convenience. If you have
> Mercurial installed on your system, you can get the files as below:
>
> hg clone http://hg.geotoolkit.org/netcdf-deploy
OK, I will look for them there, thanks. Is Mercurial the same as Git? I have
Git installed on my Mac, but not sure that I have Mercurial. Can I just do
git clone?
>
> This will create a "netcdf-deploy" directory on your machine. Alternatively,
> you
> can also browse on-line:
>
> http://hg.geotoolkit.org/netcdf-deploy/file/tip
I will check that out.
>
> All ".xml" files are actually POM files. I used the ".xml" extension only for
> allowing IDE to recognize them as XML files. For the "mvn deploy" commands,
> the
> extension doesn't matter.
Thanks, OK.
>
> Following instructions are for deploying existing artifacts only (i.e. NetCDF
> versions already released). For future NetCDF versions, I think that
> performing
> the releases from source code as you did would be better.
+1, I think for future NetCDF releases, we can use what I did to integrate.
>
> The deployment is performed by the "mvn-deploy.sh" script. For example in
> order
> to deploy "opendap":
>
> 1) Edit opendap.xml if needed
> 2) Run the following command:
>
> mvn-deploy.sh opendap
>
> Thats all. We will need to edit the "mvn-deploy.sh" script however in order to
> change the repositoryId and URL from "geotoolkit" to "sonatype".
Yeah, basically we need to change it to the Sonatype parameters on the usage
guide (aka what they call "Maven coordinates" and what is part of the patch
I sent to the list). We need to talk more about OPeNDAP. See my comments
below.
>
> Furthermore, we need to add an extra step: signature. If I'm understanding
> well
> the following page:
>
> https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+Wi
> th+Maven#HowToGeneratePGPSignaturesWithMaven-MavenGPGPlugin
>
> We "only" need to add "maven-gpg-plugin" in the xml files, and replace
> "deploy:deploy-file" by "gpg:sign-and-deploy-file" in the mvn-deploy.sh
> script.
Yeah basically. And we need to generate a *-sources.jar and a *-javadoc.jar
to go along with the actual JAR artifact for NetCDF.
>
>
>> The new OPeNDAP namespace
>> would require another Sonatype OSS JIRA issue, per this guide [5].
>
> Yes, I fell that a clean approach would be to create new JIRA issue for
> "org.opendap". Do you want me to take this action?
Actually, looking at OPeNDAP's license [1], I'm a bit confused. The license
states that OPeNDAP is LGPL, however, NetCDF is more like a BSD/MIT style
license [2]. How is it possible to include OPeNDAP-Java in NetCDF-java and
not have NetCDF immediately be LGPL? I'm actually kind of worried now b/c I
was going under the assumption in Apache Tika that NetCDF was amenable to
use in an Apache environment. See my discussions on Apache legal about this
[3].
Actually now I am thinking we probably do need to include a minimal NetCDF
jar in Tika, without the OPeNDAP dependencies and anything else that could
include a viral OSS license, at least for my Apache needs :)
I have the ability to republish the 4.2 as a minimal 4.2 jar to Central.
I'll do that tonight.
>> Hrm, are we talking about the opendap code that ships with the netcdf
>> library from NCAR or the OPeNDAP library code from opendap.org? If it's the
>> NetCDF one, I think the namespace should be edu.ucar.opendap, right?
>
> I though that the opendap-2.2.jar file bundled in NetCDF.zip was identical to
> the JAR I would get from org.opendap. Does they differ? If so, is there anyway
> to get NetCDF to use the original OpenDAP file? (since the classes in
> opendap-2.2.jar use the "opendap" package names, we are at risk of conflict if
> the code is modified).
Yeah if they aren't different, then anyone wanting an ASF compat license
wouldn't be able to use NetCDF and we certainly wouldn't be able to use it
in Tika.
>
>
>> I would just integrate it into the build process, as a specific target (or
>> Maven goal) that the release manager runs. That way it's separate of
>> generating local artifacts, and just augments it with the ability to upload
>> to an approved forge. My +1 for that. We just recently did that in the Nutch
>> project [6] and it worked great.
>
> I think that the work we did are orthogonal: the "mvn-deploy" approach I took
> applies to legacy releases, while the work you did would apply to all future
> releases. Can we deploy the existing artifacts manually using mvn-deploy (at
> least for NetCDF 4.1 and 4.2, and eventually for additional historical
> versions
I'm happy to re-deploy 4.2 to Central and get the minimal NetCDF jar up
there. That should take care of the immediate need. If we need to deploy 4.1
to central, please feel free to backport the patch I did for your build.xml,
or integrate it into your Maven build, and then ship it off to me and I can
use my Sonatype OSS username and password to upload it and then sync to
Central for 4.1.
> if we can do that easily) just for being sure to deploy the exact same thing
> than the JAR files downloaded from UCAR, and integrate you work on the SVN for
> all future releases?
+1, that sounds good to me, but we need to address the opendap issue. I'm
wondering if a more modular build set up as maven projects (e.g.,
netcdf-core, netcdf-opendap, netcdf-idv, netcdf-util, etc.) that builds
separate artifacts for netcdf, like maybe:
netcdf-core-X.Y.jar
netcdf-opendap-X.Y.jar
netcdf-idv-X.Y.jar
netcdf-thredds-X.Y.jar
Would work better? Then folks could pick and choose which parts of NetCDF
(and which licenses better yet) to include in their sources.
Cheers,
Chris
[1] http://scm.opendap.org:8090/svn/trunk/Java-OPeNDAP/COPYRIGHT
[2] http://www.unidata.ucar.edu/software/netcdf/copyright.html
[3] https://issues.apache.org/jira/browse/TIKA-432
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
