Thank you Eugene.
Eugene Kuleshov schrieb:
Jan,
I don't remember if anyone answered this. So I would reiterate.
I think as long as your proxy is not on the same host, there is a
chance that network connection between Maven client and proxy could
get stuck. Those chances would increase if specific repository manager
or proxy don't handle timeouts well enough on its side. But the root
cause of this is in the default transfer provider (lightweight http
wagon) used by Maven core, which also don't handle timeouts very well.
regards,
Eugene
Jan Schoppenhorst wrote:
Thanks for your answer, Eugene. My current setup is that I have
Archiva on another machine and mirror all requests to this
repository. Archiva is connected to central. Is that not good enough?
Are you suggesting to put an Archiva instance on my machine
(localhost)? I thought mirroring all requests would result in all
Maven requests being sent over the Archiva proxy and thereby reducing
the cost of network connection already. I know that drifts further
away from m2e but since the discussion started here I will keep it here.
Eugene Kuleshov schrieb:
Jan,
I think Igor was just suggesting to install local repository
manager what would proxy all requests to the central repository, so
it would be much faster even when Maven would search external
repositories. More over, if you'll have such proxying repository
manager on the localhost it would eliminate cost of network
connection in such cases.
Please also note that this issue is not in m2eclipse, but in Maven
core that m2eclipse is delegating to. We are working together with
Maven core team, but due to some restructuring in the Maven embedder
it is hard to say when it will be fixed.
regards,
Eugene
Jan Schoppenhorst wrote:
Thanks for the answer. The bug[1] seems to have caused the pain.
I do not know what you mean by saying "This behaviour probably
highlights problems in your network infrastructure or instability
of the repository manager." If the pom not being in the repo causes
m2e to search in the external repo why does that highlight a
problem in our network infrastructure? In the mentioned case, the
central repo was slow and querying it because of the missing pom
caused the hang.
Igor Fedorenko schrieb:
There is a bug in the version of maven embedder used by m2e, it
always checks missing pom.xml files from all remote repositories
(i.e. multiple times per embedder invocation). This behaviour
probably highlights problems in your network infrastructure or
instability of the repository manager. See [1] for more details.
Originally I switched to nexus because [2] contained all artifacts
that I needed, so I could trim my settings.xml to just two entries
(repository/pluginRepository). Since then I started to use nexus
on my local machine too, mostly to debug deployment scenarios. It
barely use any memory so I just keep it running. (disclaimer, I am
affiliated with Sonatype).
[1] http://jira.codehaus.org/browse/MNGECLIPSE-523
[2] http://repository.sonatype.org/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
****************************************************************
Jan Schoppenhorst
GDV
Gesellschaft für geografische Datenverarbeitung mbH
Binger Straße 49-51
55218 Ingelheim
Tel.: 06132/7148-19
Fax.: 06132/7148-28
www.gdv.com
www.gdv-mapbuilder.de
Sitz der Gesellschaft: Ingelheim
Amtsgericht Mainz HRB 23123
Gerichtsstand Mainz
Geschäftsführer: Thomas Riehl, Dirk Hübener
****************************************************************
begin:vcard
fn:Jan Schoppenhorst
n:Schoppenhorst;Jan
org:GDVmbH
adr;dom:;;Binger Str. 49-51;Ingelheim;;55218
email;internet:[EMAIL PROTECTED]
url:http://www.gdv.com
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
