Hi,
Not sure if my company business practice is relevant to other development
groups, and is surely irrelevant to the single/home/hobbyist developer, but we
use our own hosted maven nexus. Company policy is to generate a settings.xml
for new employees that point all maven requests at the company maven nexus.
When we need to pull jars from maven source other than maven central, we put a
help desk ticket with local IT department and the appropriate links. Usually
within a couple hours we have access to those repositories.
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
[Description: Description: Description: cid:[email protected]]
From: Chris Bennight [mailto:[email protected]]
Sent: Tuesday, March 17, 2015 10:16 PM
To: Ben Caradoc-Davies
Cc: Geoserver-devel; Andrea Aime; Geotools-Devel list
Subject: Re: [Geoserver-devel] [Geotools-devel] osgeo maven repo
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]<mailto:[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]<mailto:[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]<mailto:[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/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
