The motivation to get into maven central probably isn't so much a "how does
this make geotools/geoserver we have right now immediately better" - I
agree, there are some awkward hoops to jump through.
I think the payout is longer term in making the artifacts easier to use and
more accessible for the *non* geospatial community out there. Someone who
is working on another project and has a need for geospatial capabilities is
(in my opinion) much more likely to show a preference for projects that are
in maven central.
Some of the projects we are looking to work with (spark, hadoop, hbase,
etc.) are all pretty centralized around maven central.
I totally agree that, in reality, it's not a huge issue to add another repo
to the POM. But at the same time, that initial cusp of getting peoples
attention, getting them to spend time and come to understand a project, is
lots of times made on quick decisions (what's already available, that I
don't have to add repositories for etc.)
<That's based on my experience and the experience of people I know when we
are looking for other libraries or projects; absent anything better that's
turns out to be a pretty significant criteria - but it's admittedly both
anecdotal and an opinion>.
Would it be fair to say there's three separate high level concerns going
around here?
(1) The impact on people who do the traditional clone/build - with the
caveat that the POM should just work without jumping through any hoops.
(2) The extra overhead/maintenance required to deploy a "different" profile
to maven central.
(3) The overall viability (how I interpret Ben's point) - will we actually
be able to move enough of the artifacts over to make people using maven
central viable (because otherwise the whole effort is futile)
1 - I think this is a hard requirement (shouldn't break anything that
already works), and here I believe Rich's intent (though correct me if I'm
wrong) is to ensure that this is not impacted at all. People should be
able to clone and build from git exactly as they do now.
2 - I think it would turn into one extra deploy step (with a separate POM I
believe). The other overhead I can think of
- Managing GPG keys for signing (might already be done)
- Managing accounts with Sonatype, Bintray, or someone else (typical way
I'm familiar with; leverging OSgeo there may be a way to mirror directly)
3 - I have to admit I'm not as familiar with this. Are these things people
need if they want to use geotools, write a geoserver plugin, or are these
things needed for GeoServer integration/verification tests? That said, as
long as the group has redistribution rights I don't see any reason why
those couldn't be uploaded. (Other than the work you mentioned that would
have to be done to pomify/version control the refdataset jar, which could
be added to this proposal)
--
Chris
On Tue, Mar 17, 2015 at 11:43 PM, Ben Caradoc-Davies <[email protected]>
wrote:
> I am also bothered by this proposal as Maven Central is in my view
> overly restrictive.
>
> - What about the data-only schema jars used for app-schema testing that
> are generated by downloading schemas with ant? These exist only to allow
> caching of test data so tests can (once the artifacts are in the local
> repository) run offline without relying on network resources.
>
> - What about the refdataset jar for GeoServer app-schema database
> testing (not even under version control let alone a proper pom)? I would
> love to see an scm link that points back to a maven repo. :->
>
> I do not think these are a good fit with Maven Central's world view. Not
> to mention having somewhere to deploy an unofficial handcrafted
> milestone when we have a killer problem with a dependency and are
> getting no joy with upstream? Or the time we had no GWC release and made
> a handcrafted milestone to release against. The osgeo repo allows us to
> adopt these pragmatic workarounds.
>
> The osgeo maven repository is in my view an workable solution for these
> cases. Can osgeo put a varnishd in front of apache and be done with it?
>
> Kind regards,
> Ben.
>
> On 18/03/15 08:37, Andrea Aime wrote:
> > One thing that bothers me to the point I'd -1 this proposal is requesting
> > people to manually install some jars in order
> > to get a GeoTools build working... it's hard enough now without having to
> > also add some ex
>
> --
> Ben Caradoc-Davies <[email protected]>
> Director
> Transient Software Limited <http://transient.nz>
> New Zealand
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
