Hi Martin,
Thanks, comments below:
>
> I have a local Mercurial repository (like SVN, but not centralized), but we
> don't necessarily need it since there is only 3 pom.xml files which can be
> fetched directly from the web (links below). I deployed the artifacts using
> "mvn
> deploy:deploy-file"; I didn't modified the NetCDF sources.
Gotcha, OK thanks.
>
> All the following dependencies are available on Maven central; you can just
> copy-and-paste the dependencies section from
> http://maven.geotoolkit.org/edu/ucar/netcdf/4.2/netcdf-4.2.pom:
>
> * jdom
> * commons-httpclient
> * commons-codec
> * commons-logging
Okey dok, I'll grab the info out of the pom on your local repo.
>
> The following dependencies are not available on Maven central, but I already
> deployed them on our repository. We need to deploy those dependencies to Maven
> central, but again a copy-and-paste of the following pom.xml files (probably
> with edition) should make the process easier:
>
> * 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?
One of the challenges of what I was trying to do was to deploy Maven Central
artifacts to Sonatype OSS [1] (one of the approved Maven Central forges, the
others are listed here [2]); I was following this guide [3], which describes
how to take an existing Ant build script, and augment it with the necessary
Maven coordinates for upload to an approved Forge.
It seems like you are suggesting to publish the above artifacts as well, but
they don't seem to have separate Ant bulid.xml files (or do they?). Maybe
you are suggesting I grab the existing Maven pom.xml files from your local
repo, in which case, I could probably do that without any additional work,
so long as the poms live in the /edu/ucar namespace, which I have already
already reserved at Sonatype OSS (see here [4]). The new OPeNDAP namespace
would require another Sonatype OSS JIRA issue, per this guide [5].
>
> I suggest to start with opendap, since it was easier for me to identify its
> version number, groupId and some of its dependencies. For other dependencies,
> I'm less confident about what the proper version number / groupId should be.
Yep, me too, which is why I opted for an uber jar :)
>
> Other dependencies like visad are optional. Whatever we should deploy them or
> not is an open question.
OK, any optional dependencies, I'll ignore for now.
>
>
>> 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.
>
> Oups! I missed that email, sorry.
>
> I had a different approach for deploying NetCDF. Instead than making it part
> of
> the build process, I created a small shell script which use "mvn
> deploy:deploy-file". Deploying is very easy and fast. The hard part is to
> guess
> what are the version number of various dependencies. I had to inspect the
> content of META-INF/MANIFEST.MF files and sometime to perform "diff" against
> different versions of the NetCDF library in order to see if a dependency
> actually changed.
Yep, I hear ya. The process I followed was basically Sonatype's guide to
getting artifacts into Maven Central [5], which there are guides for
existing Ant builds, and for Maven builds. We have to follow this type of
process to get the artifacts into an approved forge, which is then sync'ed
to Central. This includes only uploading pom.xml files to a forge that list
dependencies that are *already* available in Maven Central.
>
>
>> 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.
>
> Let start with Opendap; all its dependencies are on Maven central as far as I
> know. Before to deploy, maybe we just need to make sure that the pom.xml is
> correct (organisation, URL, etc.).
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?
>
> Maybe we also need to choose how to process. Do we make the deployment part of
> the build process as you did (I don't know if it is easy to deploy individual
> JAR files that way), or do we use a shell script as I did? (I'm not attached
> to
> the script, since it was trivial to do).
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.
Cheers,
Chris
[1] http://oss.sonatype.org
[2] http://s.apache.org/iU
[3] https://docs.sonatype.org/display/Repository/Stage+Artifacts+with+Ant
[4] https://issues.sonatype.org/browse/OSSRH-792
[5] http://s.apache.org/pl
[6] https://issues.apache.org/jira/browse/NUTCH-825
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
