Настройка частного удаленного репозитория maven

2 ответа

Лучший ответ

Я думаю, у вас есть три варианта.

1. Переход на 11.0

Вы можете перейти на Netbeans 11.0 LTS (или 11.2), он использует встроенную версию Maven 3.3.9. Он уже использует https.

2. Установите автономный Apache Maven

Вы можете остаться с Netbeans 8.2, но загрузить автономный apache maven, установить его в свою систему и указать путь к новому домашнему каталогу maven в Параметры -> Java -> Maven -> Maven Home.

Вам нужно всего лишь:

Загрузите apache-maven-3.6.3-bin.zip (или apache-maven-3.6.3-bin.tar.gz) из Apache
Распакуйте его в любой каталог. Это будет дом Maven.
В домашнем каталоге Maven в NetBeans укажите каталог, в который вы распаковали zip-файл.
Убедитесь, что вы установили JAVA_HOME в свои переменные окружения

Инструкции по установке автономной версии здесь.

Если вы правильно установите Maven Home в NetBeans, он покажет вам обновленную версию:

Maven Central перенесен в https

Проблема связана с этим:

Здесь находится соответствующее улучшение, которое было устранено и соответствует меняет.

Dmitry.M
3 Фев 2020 в 18:56

В рамках установки Netbeans это работало для меня:

Перейти к , и здесь я обновил файл с правами администратора.

Поскольку ссылка на репо http теперь не будет работать, я создал зеркало для репозитория , предварительно созданное с помощью IDE, которое нельзя изменить.

Добавьте это внутри тега mirrors of

После этого перезапустите IDE NetBeans, и центральное хранилище будет переопределено указанным нами зеркалом.

Karthik Kumar
7 Апр 2020 в 02:37

Зачем вообще нужен SSL-сертификат

SSL-сертификат — это цифровая подпись сайта. Она обеспечивает безопасное шифрованное соединение пользователя с вашей платформой. Без такого сертификата все данные, которые вводят на сайте посетители, могут быть похищены: электронные адреса, пароли и данные банковских карт.

Мы уже писали о том, что такое SSL-сертификат, как он связан с безопасностью и почему вам лучше перевести сайт на защищенный протокол HTTPS. Там же вы найдёте инструкцию по переходу на HTTPS.

Сегодня поговорим о том, как выбрать SSL-сертификат для сайта.

Существует три способа получить сертификат:

Сделать самостоятельно. Такой вариант можно использовать для экспериментов на внутренних ресурсах компании, но лучше отказаться от него совсем, ниже мы подробно рассмотрим, почему.
Установка такого сертификата позволит сэкономить, но, как правило, у него будет низкий уровень безопасности, что подвергает риску работу вашего сайта.
Купить. Вариант с гарантиями и всесторонней поддержкой. Подойдёт для любого сайта и бизнеса.

Рассмотрим плюсы и минусы каждого из видов сертификатов и сделаем выводы.

Включенный экспериментальный протокол QUIC

QUIC — это новый экспериментальный протокол, который нужен для быстрого подключения к интернету. Основная задача протокола QUIC состоит в поддержке нескольких соединений. Вы можете отключить этот протокол в конфигурации вашего браузера.

Показываем как отключить QUIC на примере браузера Google Chrome:

Откройте браузер и введите команду chrome://flags/#enable-quic;
В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Добавление учетных данных

Если бы наш прокси не был защищен, это все, что нам нужно; однако наш, так что давайте добавим наши учетные данные в определение прокси :

Мы не добавляем записи имени пользователя и пароля, если они нам не нужны — даже пустые, — поскольку их присутствие, когда прокси не требуется, может привести к отклонению наших запросов.

Наша минимальная аутентифицированная конфигурация теперь должна выглядеть так:

Теперь, когда мы запустим команду mvn, мы пройдем через прокси-сервер, чтобы подключиться к нужным нам сайтам.

3.1. Необязательные записи

Давайте дадим ему необязательный идентификатор ‘BaeldungProxy_Authenticated’, чтобы упростить обращение, на случай, если нам когда-нибудь понадобится переключить прокси:

Теперь, если у нас есть другой прокси, мы можем добавить другое определение прокси, но только один может быть активным. По умолчанию Maven будет использовать первое найденное определение активного прокси .

Определения прокси активны по умолчанию и получают неявное определение:

Если бы мы хотели сделать активным другой прокси-сервер, мы бы деактивировали нашу исходную запись, установив на ложь:

Значение Maven по умолчанию для протокола прокси — HTTP , что подходит для большинства случаев. Если наш прокси-сервер использует другой протокол, мы бы объявили его здесь и заменили http на протокол, который нужен нашему прокси:

Обратите внимание, что это протокол, который использует прокси — протокол наших запросов (ftp: //, //, //) не зависит от этого. А вот как выглядит наше расширенное определение прокси , включая необязательные элементы:

А вот как выглядит наше расширенное определение прокси , включая необязательные элементы:

Итак, это все, что касается нашей базовой записи прокси, но достаточно ли она безопасна для нас?

Про релизы и SNAPSHOT-ы

Maven позволяет управлять циклом разработки и сборки проекта. С помощью maven эти процессы стандартизируются для всех проектов.

SPANSHOT — это специальная версия проекта или модуля. Означает, что на данный момент в модуле находится самый новый код и ведутся постоянные изменения, например делается багфиксинг или доработка нового функционала. Если в проекте используется артефакт с обычной версией (например 2.0), то maven выполнит его сборку (либо загрузку с nexus) один раз и сохранит в локальном репозитории, потом будет загружать собранный (загруженный) в первый раз артефакт. Если модуль является SPAPSHOT-ом (версия 2.0-SNAPSHOT), то maven будет пересобирать его каждый раз заново вместо того, чтобы подтягивать из репозитория, либо каждый раз вытягивать из nexus вместо вытягивания из локального репозитория. Указывать версию как SNAPSHOT нужно, если на проекте ведутся работы и нам всегда нужна самая последняя версия.

Релиз — это какой-то объём функциональности, срез проекта в определённый момент времени и фиксирование этих изменений. Зачастую релизы поставляются заказчику и отдаются на тестирование.
С помощью maven можно создавать релизы и управлять версиями автоматически.

Maven и управление релизами

Создание релиза состоит из двух стадий:

Подготовка релиза

1. У нас есть многомодульный проект, версия на данный момент 1.0-SNAPSHOT

2. Мы комитаем весь исходный код и вызываем

 mvn release:prepare

3. Maven переименовывает все версии на 1.0, делает сборку проекта, запускаетunit-тесты

4. Далее maven создаёт тег в системе контроля версий (svn, git, …), и сохраняет под этим тегом слепок нашего проекта (версия 1.0)

5. Далее maven инкрементирует версии (в проекте и подпроектах) на 1.1-SNAPSHOT и комитает изменённые pom.xml файлы

Создание релиза

После подготовки релиза, в проекте появляются файлы бэкапов pom.xml и файл release.properties. Release plugin использует эти файлы для выполнения релиза.

6. Вызываем

 mvn release:perform

7. maven достаёт по тегу последний релиз (в нашем случае был 1.0), выполняет сборку и паблишит артефакты на nexus

После этого чистятся все бэкапы pom-файлов и файл release.properties

4 ответа

Лучший ответ

Есть несколько способов сделать это.

Лучше всего, ИМО, чтобы ваш локальный сервер репозитория действовал как прокси для Maven Central. И Nexus, и Artifactory делают это из коробки. Если вы используете Apache или другой веб-сервер, вам следует переключиться.

Вы также можете обновить свои настройки, исключив целевой сервер из зеркала:

Это работает, если у вас есть несколько локальных серверов репозитория, но я не думаю, что вы можете исключить центральный таким образом: по умолчанию Maven ищет артефакты в центральном, а ваш сервер действует как заместитель для Это.

Это оставляет явные записи репозитория в ваших POMS, которые ссылаются на локальный репозиторий. Если ваш локальный репозиторий просто обслуживает ваши артефакты, это может быть вторым по простоте делом (особенно если вы используете родительский POM, содержащий спецификацию репозитория).

parsifal
11 Окт 2012 в 17:00

Я использую три репозитория (с использованием Nexus), первый — это репозиторий Proxy, в который я добавляю все внешние репозитории. Два других — мои внутренние репозитории для развертывания релизов и снимков. Вот мой .m2 / settings.xml:

Maven использует их все, поэтому вы можете использовать функцию маршрутизации Nexus, чтобы заблокировать «^ / my / private / packages /.*», чтобы он не пытался получить внутренние пакеты из внешних репозиториев. Я не добавлял внутренние репозитории в репо прокси.

Вам не нужно настраивать файлы pom.xml, чтобы это работало. Просто введите «mvn deploy».

user1050755
16 Мар 2014 в 13:21

Ваша директива Mirror в настоящее время зеркалирует все . Вы можете исключить именованные репозитории следующим образом:

Вышеупомянутое отражает все, кроме репозитория с именем .

Brian Agnew
11 Окт 2012 в 16:58

Я нашел рабочий ответ, который состоит в том, чтобы вместо этого изменить pom.xml и добавить удаленные репозитории на лету, как указано в эта ссылка

Спасибо за ответы, ребята, и я предполагаю, что ваши предложения могут быть полезны для более сложных сценариев с большим количеством репозиториев и сложных конфигураций.

Some Newbie
11 Окт 2012 в 19:01

Подходы к работе с reusable-компонентом

Повторно-используемые компоненты позволяют шарить общий код между проектами, тем самым ускоряя разработку. Для работы с такими компонентами мы используем maven + nexus (internal maven-репозиторий).

Как подключить готовый компонент к проекту

1. В файле maven/conf/settings.xml настроить использование внутреннего nexus-репозитория

 <servers>
   <server>
     <id>nexus</id> 
     <username>login</username> 
     <password>password</password> 
   </server>
 </servers>

2. Подключить компонент как maven-зависимость

 <dependency>
   <groupId>org.jazzteam</groupId> 
   <artifactId>utils</artifactId> 
   <version>1.0</version> 
 </dependency>

Как создать компонент для повторного использования в других проектах

1. Создать maven-проект, положить его в репозиторий (svn, git, …)

2. Добавить к проекту конфигурацию для работы с релизами (см. раздел «Конфигурирование pom-файла»)

3. Выполнить релиз, после этого проект будет задеплоен на nexus и доступен для использования в других проектах (см. раздел «Maven и управление релизами»)

Что делать, если нужно изменить компонент (добавить код, исправить баг…)

1. Чекаутаем компонент из репозитория

2. Делаем изменения, вносим код, рефакторим, …

3. Выполняем релиз компонента (см. раздел «Maven и управление релизами»), убеждаемся что зарелизанная версия отличается от предыдущей (к примеру, до модификации была версия 1.2-SNAPSHOT, значит старая версия проекта будет 1.1, версия, которая пойдёт в релиз будет 1.2)

4. Проекты, которые использовали компонент до изменений будут продолжать использовать версию 1.1. Чтобы начать использовать наши изменения нужно поменять версию этого в зависимостях на 1.2.

 <dependency>
   <groupId>org.jazzteam</groupId> 
   <artifactId>utils</artifactId> 
   <version>1.2</version> 
 </dependency>

Password encription

Чтобы не хранить пароли в конфигурации в их чистом видео используют md5 hash.

Зная пароль от maven удаленного репозитория мы можем сгенерировать hash.

для начала сгенерируем master-password. <password> — это базовый пароль, введите любой пароль.

mvn --encrypt-master-password <password>

Создайте файл

~/.m2/settings-security.xml

заполните его

<?xml version="1.0" encoding="UTF-8"?>	  
<settingsSecurity>
  <master>{rNKR4UvVllQHZdE/gp7wlKv85wxDoi9+WFZaTRpHw9U=}</master>
</settingsSecurity>

Далее сгенерируем хэш для нашего пароля.

mvn --encrypt-password <realPassword>

Вставим его в ~/.m2/settings.xml

<server>
 <id>nexus</id>
 <username>user</username>
 <password>{GAsdfsdfRWd9dgfdgfdfgdfgdfg0Lxj/HYhjBFlXLqYrM6YdU3j24=}</password>
</server>

Если вы администратор, и вам нужно передать готовый хэш пользователю.

Вам нужно проделать вышесказанные пункты используя пароль пользователя, и передать ему файл

~/.m2/settings-security.xml

и хэш пароля из файла

~/.m2/settings.xml

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.

Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.

Использование свойств системы

Хотя настройка Maven с помощью файла настроек является рекомендуемым подходом , мы могли бы объявить конфигурацию нашего прокси-сервера с помощью свойств системы Java.

Если в нашей операционной системе уже настроен прокси, мы можем установить:

В качестве альтернативы, чтобы он всегда был включен, если у нас есть права администратора, мы можем установить это в нашем файле /lib/net.properties .

Однако отметим, что, хотя сам Maven может уважать этот параметр, не все плагины соблюдают его, поэтому мы все равно можем получать неудачные соединения с использованием этого метода.

Даже когда он включен, мы можем переопределить его, установив данные нашего HTTP-прокси в системном свойстве http.proxyHost :

Наш прокси-сервер прослушивает порт 80 по умолчанию, но если он прослушивает порт 8080, мы бы настроили свойство http.proxyPort :

А для наших сайтов, которым прокси не нужен :

Итак, если наш прокси находится на 10.10.0.100, мы можем использовать:

Конечно, если наш прокси требует аутентификации , мы также добавим :

И если мы хотим, чтобы некоторые из этих настроек применялись ко всем нашим вызовам Maven, мы можем определить их в переменной среды MAVEN_OPTS:

Теперь, когда мы запускаем « mvn », эти настройки будут применяться автоматически — пока мы не выйдем.

7 ответов

Лучший ответ

Sonatype больше не поддерживает TLSv1.1 и ниже (вступает в силу 18 июня 2018 года). Я предполагаю, что вы используете протокол TLSv1.1 или ниже.

Документация, которую я перечислил, дает вам 4 варианта:

Обновите среду выполнения Java, например, с помощью сборок OpenJDK или платной поддержки Oracle
Настройте среду выполнения Java для включения TLS 1.2, добавив -Dhttps.protocols = TLSv1.2
Используйте менеджер репозитория, который использует версию Java, поддерживающую TLS 1.2
Вернитесь к http, пока не сможете выполнить один из указанных выше шагов по исправлению.

Я сам исправил это, просто используя -Dhttps.protocols = TLSv1.2 в качестве аргумента виртуальной машины.

John29
14 Июл 2018 в 00:23

Для постоянного решения (в основном требуется в Java 7) — в каталоге сборки (откуда вы выполняете команду ) добавьте каталог:

(в cmd )

И в нем создай файл

И вставьте следующую строку:

Yoav R.
3 Июл 2018 в 22:12

Пакет, который вы пытаетесь установить , не поддерживает TLS1.1 , и вы можете по умолчанию использовать TLS 1.1. Настройте среду выполнения Java для включения TLS 1.2, добавив -Dhttps.protocols = TLSv1 .2 для вашей команды Maven Build решит проблему

Например, mvn clean install -Dhttps.protocols = TLSv1.2 .

kartick shaw
8 Фев 2020 в 19:08

Я исправил эту ошибку в SpringToolSuit , добавив файл в папку , которая находится в папке «Пользователи» на диске , и обновив Project с помощью щелкните правой кнопкой мыши .

Убедитесь, что вы выбрали Принудительное обновление .

AjahnCharles
6 Апр 2020 в 01:13

Я обновил Java 1.7 до Java 1.8 и получил ту же ошибку. Чтобы устранить эту ошибку, я проверил версию mvn с помощью и обнаружил, что JAVA_HOME все еще использует Java 1.7. Я изменил JAVA_HOME в переменной среды, чтобы указать на Java 1.8 JRE в JDK

Надеюсь, это кому-нибудь поможет.

sa3036
26 Окт 2018 в 00:16

Самое простое решение — настроить аргументы времени выполнения JVM. На затмении вы можете сделать это следующим образом:

Зайдите в windows> настройки> java> установленные JREs нажмите на установленный JRE / JDK, который вы используете для своего проекта

Нажмите на кнопку «Изменить» справа от нее, и добавьте в поле ввода аргументов виртуальной машины по умолчанию.

Посмотрите на скриншот:

Jean-François Corbett
29 Авг 2018 в 13:32

Для этого нужны оба: настройка аргументов времени выполнения JVM, а также наличие файла settings.xml, после того как я это сделал, все заработало. Обновление только аргумента времени выполнения JVM не помогло.

user4770620
12 Апр 2019 в 06:28

Защита нашей конфигурации

Теперь предположим, что один из наших коллег хочет, чтобы мы отправили им нашу конфигурацию прокси.

Мы не слишком заинтересованы в отправке нашего пароля в виде обычного текста, поэтому давайте посмотрим, насколько легко Maven позволяет шифровать наши пароли .

4.1. Создание мастер-пароля

Сначала давайте выберем мастер-пароль, скажем «te! St! Ma $ ter».

Теперь давайте зашифруем наш мастер-пароль , введя его в приглашении при запуске:

После того, как мы нажали Enter, мы видим наш зашифрованный пароль, заключенный в фигурные скобки:

4.2. Устранение неполадок при генерации пароля

Если мы видим {} вместо приглашения Master Password: (это может произойти при использовании bash), то нам нужно указать пароль в командной строке.

Давайте заключим пароль в кавычки, чтобы исключить наличие специальных символов, таких как ‘!’ не иметь нежелательных эффектов.

Итак, давайте использовать одинарные кавычки, если мы используем bash:

Или используйте двойные кавычки, если используете командную строку Windows:

Теперь, иногда наш сгенерированный мастер-пароль содержит фигурные скобки , как в этом примере с закрывающей фигурной скобкой, ‘}’, после ‘UD’:

В этом случае мы можем:

снова запустите команду mvn –encrypt-master-password, чтобы сгенерировать еще одну (надеюсь, без фигурной скобки)
избегайте фигурных скобок в нашем пароле, добавляя обратную косую черту перед ‘{‘ или ‘ }’

4.3. Создание файла settings-security.xml

Теперь давайте наш зашифрованный пароль, с беглым «\}», в файл с именем настройки-security.xml файла в нашем .m2 каталоге :

Наконец, Maven позволяет нам добавлять комментарий внутри главного элемента.

Давайте добавим текст перед разделителем пароля ‘{‘, стараясь не использовать {или} в нашем комментарии, поскольку Maven использует их для поиска нашего пароля:

4.4. Использование съемного диска

Допустим, нам нужно быть в безопасности и мы хотим хранить наш мастер-пароль на отдельном устройстве .

Сначала мы поместим наш файл settings-security.xml в директорию config на съемном диске «R:»:

А теперь мы обновим файл settings-security.xml в нашем каталоге .m2, чтобы перенаправить Maven на наш настоящий settings-security.xml на нашем съемном диске:

Maven теперь прочитает наш зашифрованный мастер-пароль из файла, указанного в элементе перемещения , на нашем съемном диске.

Генерация CSR запроса на сертификат

CSR (Certificate Signing Request) – это зашифрованный запрос на получение сертификата, включает в себя информацию о домене и организации.

CSR может быть сгенерирован одним из способов:

Автоматически в процессе заказа SSL-сертификата.
Онлайн, через CSR генератор, например у или .
Самостоятельно на собственном веб-сервере.

В независимости от способа, в результате вы должны получить 2 файла (или их текстовое содержание) — файл запроса (domain.csr) и файл приватного ключа (private.key). Файл запроса потребуется для генерации сертификата. А приватный ключ понадобится в дальнейшем, его вместе с сертификатом нужно будет установить на хостинг или сервер.

Первые два способа не должны вызвать трудностей, генерация на собственном сервере описана ниже, но для начала несколько важных замечаний:

Все данные запроса должны заполняться на английском языке.

При заказе сертификатов типа WildCard доменное имя необходимо указывать со знаком звездочка (Пример: *.domain.com).

У домена, для которого заказывается SSL-сертификат (за исключением зон .ru и .рф), должно быть отключено сокрытие персональных данных.

В некоторых случаях, для того, чтобы сертификат защищал домены с префиксом www и без него, необходимо указать домен с префиксом, например: www.domain.ru. В противном случае сертификат не будет защищать домен с www даже если он поддерживает его.

Далее при генерации запроса CSR вам потребуется указать адрес электронной почты. Рекомендуется заранее создать почтовый ящик вида admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain и указать в контактных данных его. Этот же адрес пригодится позже для подтверждения владения доменом.

Генерация CSR запроса на собственном сервере

Потребуется криптографический пакет с открытым исходным кодом – . Он входит в состав большинства UNIX-подобных операционных систем.

Во многих инструкциях рекомендуется генерировать закрытый ключ и CSR запрос на том же сервере, для которого выпускается сертификат. Однако, на самом деле, это не обязательно должен быть один и тот же сервер.

Подключитесь к серверу по SSH и перейдите в домашнюю директорию.

Сгенерируйте закрытый ключ.

В команде выше:

private.key – выходной файл, который будет содержать ключ;
4096 – размер ключа, резже 2048.

На запрос «Enter pass phrase for private.key» укажите пароль для защиты закрытого ключа, а затем «Verifying – Enter pass phrase for private.key» – подтвердите его, повторив ввод пароля еще раз.

Закрытый ключ будет создан и сохранен в файл под именем private.key.

Сохраните копию закрытого ключа на своем компьютере. При компрометации ключа или утрате пароля сертификат придется перевыпустить.

Далее сгенерируйте CSR запрос.

В команде выше:

private.key – созданный на предыдущем этапе закрытый ключ;
domaine.csr – выходной файл с CSR запросом.

На запрос «Enter pass phrase for private.key» введите пароль от закрытого ключа.

Далее последовательно латинскими символами укажите следующие данные:

Country Name – двухсимвольный код страны согласно ISO-3166, например RU для России;
State or Province Name: область или регион без сокращений;
Locality Name: название города или населенного пункта;
Organization Name: название организации, для физ. лиц укажите «Private Person»;
Organizational Unit Name: подразделение (необязательно), для которого заказывается сертификат, например для IT-отдела можно указать IT;
Common Name: доменное имя (полностью) для которого заказывается сертификат;
Email Address: контактный e-mail адрес, вида admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain;
A challenge password: не заполняется;
An optional company name: альтернативное имя компании (необязательно).

CSR запрос на сертификат будет сохранен в файле domain.csr в виде закодированного текста.

Проверить корректность введенных данных можно, выполнив следующую команду.

Файлы закрытого ключа и CSR запроса или их содержимое потребуются далее. Вывести (чтобы затем скопировать) содержимое файла можно командой cat.

или

Для выхода нажмите клавишу Q.