El mateix repositori funciona amb git clone en un terminal i falla en una aplicació que utilitza JGit. Es tracta d'una comparació entre dues implementacions, no necessàriament entre una còpia que funciona i una de trencada del mateix client.

La referència de configuració del JGit diu que la configuració del proxy utilitza els mecanismes estàndard de Java mitjançant java.net.ProxySelector. No assumiu que totes les opcions HTTP del Git natiu estan implementades només perquè tots dos clients entenen un fitxer de configuració Git.

Identifiqueu l'aplicació que incrusta el JGit, la seva versió i el transport HTTP triat. L'aplicació amfitriona pot oferir opcions o comportament més enllà dels valors per defecte autònoms del JGit.

A continuació, reviseu la configuració de proxy de Java visible per a aquest procés. Per a un transport HTTP basat en URLConnection, comproveu les propietats d'amfitrió i port de la JVM que consumeix. Una propietat introduïda en un terminal no relacionat després d'iniciar l'aplicació no pot reconfigurar la JVM en execució. L'operació Git nativa d'un IDE i la seva operació JGit també poden utilitzar camins diferents.

Manteniu l'autenticació del proxy separada de la selecció de ruta. Les propietats de proxy de Java que identifiquen un amfitrió i un port no implementen automàticament un esquema de contrasenya de proxy. Utilitzeu el mecanisme d'autenticació compatible de l'aplicació amfitriona.

La pregunta útil és “quin proxy ha triat aquesta sol·licitud JGit?”, i no “la meva configuració Git conté una línia de proxy?”. Un èxit del Git natiu és una comparació valuosa, però no respon a aquesta pregunta específica de la implementació.

Articles relacionats