That is how I have worked with a few teams - including LocationTech.
When we migrated to maven 2 a webdav folder was the 'best' way to set up a
public maven repository. We could as OSGeo to stand up a Nexus repository
(which may better handle scalability issues).
One part missing in this discussion is *how* to upload to maven central. We
were going to use CodeHaus but they have shut down. I updated the proposal
"tasks" to list this as a research step.
Reading the maven central docs it is clear a project *can* publish modified
artifacts into maven central (example gt-opengis is an older copy of
geoapi) but should do so under a distinct group id.
Compare:
<dependency>
<groupId>org.geotools</groupId>
<artifactId>gt-opengis</artifactId>
<packaging>jar</packaging>
</dependency>
<dependency>
<groupId>org.opengis</groupId>
<artifactId>geoapi</artifactId>
<version>3.0.0</version>
</dependency>
That said we have feedback on the user list that package overlap presents a
problem for integrators. Not strictly a maven central issue, more
respecting java package conventions.
I believe our jars that bundle OGC Schemas and EMF model would be fine.
<dependency>
<groupId>org.geotools.ogc</groupId>
<artifactId>net.opengis.fes</artifactId>
<packaging>jar</packaging>
</dependency>
Even though the artifactId uses net.opengis.fes, the groupId clearly
indicates this is part of the geotools project.
--
Jody Garnett
On 18 March 2015 at 06:15, Chris Snider <[email protected]> wrote:
> 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.*
>
> [image: 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]>
> 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/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-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
