Hi Folks,

Thanks for the input so far... some more comments below.
In the past I've uploaded the 'problem' artifacts (namely those classified
as 'scientific' e.g. netcdf and dependencies) to OSSRH. There is no working
around the fact that is a PITA... and that's not me being obstinate... it
really is a PITA.

The response this time around from the Unidata netCDF Java Support is as
follows "...We would like to publish to Maven Central one day, but THREDDS
has a few dependencies that aren't available there either. So even if we
migrated our stuff, you'd still have to add our Nexus server to your Maven
config for the transitive dependencies."

In short, the 2nd blog post you provided below Chris does state as a
'moral' summary of sorts the following, "...If you are exposing your source
and want to make it easy for others to build, then consider adding a
repository entry to your POM, but don't pick a URL lightly, think
long-term, and use a URL that will always be under your control." My
interactions with the Unidata netCDF Java Team would suggest that this is
the case. Also, based on the fact that thier documentation on this topic
has been static for a number of years, I would also say that things are
stable enough for us to have confidence that they will remain that way for
some time to come.
The argument does however fall to pieces when we consider the other
guidance e.g. "...If your URL has to change down the road, make sure that
you will always be able to track 404s and write the appropriate mod_rewrite
rules to ensure that future builds will be able to find the appropriate
artifacts."

This is essentially why the re-architecture as originally proposed under
Tika 2.0 was so appropriate IMHO. It would have enabled near full recovery
from external repository URL changes resulting in unresolved URLs, as the
'scientific' dependencies were all packaged into a neat parser module and
separate from everything else. This is going off topic of course.

Basically, us Tika dev's maintaining and pushing netCDF (or any other third
party artifacts) through OSSRH is really not a sustainable solution. We
need something else.

@Nick, I noticed that you didn't provide any policy document... from what I
understand it is more a Tika PMC reservation/objection than ASF policy is
this fair to say?

Any other ideas for how we address this issue moving forward as I don't
want the thread to die off folks.
Thanks all,
Lewis

On Mon, Feb 5, 2018 at 9:52 AM, <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB