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, <dev-digest-h...@tika.apache.org> wrote: > > From: Chris Mattmann <mattm...@apache.org> > To: "firstname.lastname@example.org" <email@example.com> > Cc: > Bcc: > Date: Mon, 05 Feb 2018 09:09:21 -0800 > Subject: Re: relying on a non-Maven central repo? > I think we can't merge this b/c it references an external repository: > > https://blog.sonatype.com/2010/03/why-external-repos- > are-being-phased-out-of-central/ > https://blog.sonatype.com/2009/02/why-putting- > repositories-in-your-poms-is-a-bad-idea/ > > Before it can be merged it needs to be uploaded to OSSRH and synced.... > > >