On Tue, Mar 17, 2015 at 9:05 PM, Rich Fecher <[email protected]> wrote:
> I agree its a painful workaround. I look at it as steps in the right
> direction to maybe get someday to the point where we just can resolve
> dependencies entirely from maven central.
>
> But there perhaps may be some clarifications on the suggestion that may
> alleviate concerns. I am suggesting the root pom.xml that you would get
> from cloning geotools source still have any repositories and plugin
> repositories explicitly listed that will allow maven to automatically
> resolve all dependencies (basically no difference when building geotools
> from source). But the geotools pom.xml that is published to maven central
> cannot reference external repositories to follow maven central's guidelines
> so it will require downstream applications to add a repositories tag. The
> downstream application would reference a repository that contains the
> identified dependencies that are missing from maven central. I can't quite
> see how its worse than the current situation for a downstream application.
> In other words, referencing additional maven repositories to pick up on
> geotools dependencies is not foreign to applications that use geotools
> right now, and what this proposal will hopefully do is get more/most
> geotools dependencies available on maven central so that only a relatively
> small subset need to be hosted externally. Unless I'm missing something, it
> shouldn't affect downstream applications if the repositories that currently
> host artifacts don't go away. Maybe (hopefully) we can get all dependencies
> on maven central to simplify the use of geotools but there currently seem
> to be dependencies such as JAI that we cannot distribute on maven central.
>
Indeed it is not foreign, but I was thinking of the situation that we had
recently, with the OSGeo repository not keeping up with the load
(too many concurrent connections) mostly because it is one of the first
repos to be searched.
To reduce the load, we have to tell people to list central as the first
repo to search, and only use OSGeo as a fallback... however, if JAI
remains in the current groupId, my understanding is that central will just
tell us the jar must be manually installed and the build
will fail there... or not? That's why I was suggesting that we move jai to
a different groupId.
Also.. what support do we have, build time, to alter the pom.xml for the
purpose of publishing it to central?
Like.. we would not be able to use mvn deploy (or a single mvn deploy
command) anymore, am I right?
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
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
