Как удалить maven windows

Обновлено: 05.07.2024

Мой инструктор заставил нас всех установить дополнение Maven для программирования в Java. Теперь каждый раз, когда я делаю новую программу Java, она не распознается Eclipse. Под этим я подразумеваю, что он перенаправляется на другую программу. Кроме того, при просмотре в разделе "конфигурации запуска" в разделе "Приложения Java" любые новые программы, которые я создаю, там не отображаются. Однако все программы должны отображаться здесь.

Пример:

Допустим, у меня есть программа с именем "Test", которую я сделал перед установкой Maven. Теперь предположим, что я сделал программу "Test2" после установки Maven. При запуске теста он работает нормально. Но когда выполняется Условие_2, она проходит тест. Кроме того, что он отображается в каталоге слева, Eclipse не указывает на то, что Test2 действительно существует. Это моя проблема.

Мой Вопрос:

Как полностью удалить Maven из моей системы? Я не хочу использовать Восстановление системы.

То, что я пробовал:

Я удалил переменную окружения "M3 HOME" и удалил ее из переменной "Path". Однако проблема все еще существует.

У меня есть игровой ноутбук Lenovo Y50-70 Windows 10 (64 bit) с разрешением 4K. Я использую Eclipse Luna.

1 ответ

Я пытаюсь полностью удалить редактор Webstorm из моего Ubuntu 14.04, я уже пытался удалить его установочную папку, но его настройки все еще существуют, есть ли какая-либо команда, чтобы удалить его полностью или каким-либо другим способом? пожалуйста, помогите мне?

Немного повозившись, я нашел ответ.

Щелкните правой кнопкой мыши любую папку "src" и выберите что-то в строке "Exclude Maven Artifact" под параметром "Maven". Это удалило его из Eclipse, и теперь я могу создавать новые программы и запускать их снова.

Надеюсь, это поможет тому, у кого есть моя проблема!

Как удалить собственный скелет Maven (архетип) в IDEA

Как удалить кастомный скелет (архетип), добавленный в IDEA

Как показано на рисунке, это мой собственный скелет Maven.

1. Найдите следующий каталог (Windows)

2. Откройте UserArchetypes.xml

Как видите, в файле UserArchetypes.xml есть только один настраиваемый скелет Maven. Если вам нужно удалить его, удалите тег <archtypes /> там, где скелет, который вы хотите удалить, в этом файле UserArchetypes.xml.

Интеллектуальная рекомендация

Краткое описание общих функций MPI

содержание 1, основная функция MPI 2, точка-точка функция связи 3, коллективная функция связи 1, основная функция MPI MPI_Init(&argc, &argv) Информировать системы MPI для выполнения всех необх.

Примечание 9: EL выражение

JVM память

концепция Виртуальная машина JVM управляет собственной памятью, которая разделяет память во многие блоки, наиболее распространенной для памяти стека и памяти кучи. 1 структура виртуальной машины JVM H.

Проблема сетевого запроса на Android 9.0

вЗапустите Android 9 (API Уровень 28) или вышеНа устройстве операционной системы Android, чтобы обеспечить безопасность пользовательских данных и устройств, использование по умолчанию для зашифрованно.

Учебная запись по Webpack (3) В статье рассказывается о создании webpack4.0.

предисловие Для изучения веб-пакета автор также предпринял много обходных путей. Есть много вещей, которые я хочу знать, но я не могу их найти. Автор поможет вам быстро начать работу. Цель этой статьи.

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

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

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

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

Итак дано:

— Система, «ядро» которой состоит из набора dll и отдается прикладным разработчикам без исходников.
— Прикладной язык программирования, который подобен Паскалю, но кроме стандартных возможностей Паскаля(из которых доступно далеко не все) позволяет использовать объекты, реализованные в dll «ядра». Данный прикладной язык компилируется в подобие байт кода и исполняется отдельной dll «ядра».

Таким образом, основная разработка ведется на описанном выше ~~волшебном~~ прикладном языке, все прелести которого, пожалуй, могли бы ужаснуть уважаемое сообщество, а «ядро» периодически(новая версия раз в пару месяцев) поставляется из головного офиса и не подлежит модификации.

Очень вероятно, что разработка и поддержание собственного языка программирования похожего на Паскаль и сделанного на базе Delphi возможно была плохой идеей, но 15-17 лет назад, когда все это начиналось, об этом никто не думал. Преследовались другие цели, которые в общем-то с успехом были достигнуты.

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

Проведя анализ, стало понятно, что такое отсутствие взаимодействия отделов объясняется прежде всего нехваткой механизмов использования общего кода. Иными словами, если все-таки, происходил обмен опытом и исходниками между группами, то библиотека(исходник) просто копировалась в другой проект(продукт для друго клиента) и начинала жить самостоятельной жизнью, сохранив в себе все глюки и недоработки, которые присутствовали на момент копирования.

Для исправления ситуации было принято решение организовать репозиторий (хранилише) и систему сбора проекта с использованием набора библиотек общего кода(Пакетов).

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

Но обо всем по порядку

Главной проблемой, о которой я и не подозревал в начале своих изысканий, оказалось то, что Пакеты должны содержать в себе не скомпилированные в байт код файлы, а именно исходники, т.к. компиляция должна происходить именно под той версией «ядра», для которой они будут использоваться. Для простоты назовем наши прикладные исходники bpas. Это немного противоречит стандартному ЖЦ в Maven.

После таких откровений было принято решение формировать пакет из исходников, но при формировании обязательно проверять их атомарную компилируемость. Иными словами, задействовать почти стандартный ЖЦ Maven, когда сначала компилируются .class, а потом вместе с ресурсами запаковываются в jar. Только в моем случае Пакет вместо скомпилированных файлов формировался из запакованных в zip исходных bpas.

Немного о том как работает Maven

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

Причем пытаясь запустить какую-то фазу ЖЦ, например «mvn compile», я на самом деле запускаю всю цепочку фаз от validate (валидация проекта) до compile, не пропуская ни одной. Для каких-то фаз существуют так называемые плагины по умолчанию, которые будут вызваны несмотря на то, что в pom.xml(основной файл Maven проекта) существует только заголовок и ни одного указания на запуск плагинов.

Здесь стоит отдельно отметить тот факт, что Maven — это полностью плагинная система. Иными словами, он не умеет практически ничего, кроме запуска плагинов, а вот они уже умеют делать потрясающе много. Получается, что когда мы хотим научить Maven каким- то особенностям сборки проекта, мы должны добавить в pom.xml указание на запуск нужного плагина в нужную фазу и с нужными параметрами.

Вот такой абсолютно валидный пустой pom.xml, несмотря на свою пустоту, при получении команды mvn deploy запустит Плагин инициализации, компиляции, упаковки и деплоя Java исходников из папки src/main.

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

Построение нового ЖЦ в pom.xml

Для реализации пакетов был подобран следующий жизненный цикл.

initialize (инциализация) – Читаем настройки из конфиг(property или key = value) файла и добавляем их в тег properties. О теге properties поговорим чуть позже.
generate-sources (генерация исходного кода) – Загружаем и распаковываем из zip все Пакеты, которые являются зависимостями данного пакета/проекта, в отдельную директорию для последующей компиляции вместе с исходниками текущего пакета/проекта.
compile (компиляция) – Запускаем свой плагин компиляции для наших bpas, который определяет правильный порядок компиляции и запускает компилятор командной строки для нашего языка. Кратко я расскажу о собственном плагине ниже, но гайд по его написанию предлагаю вынести за пределы данной статьи.
assembly (сборка) – запаковываем пакет, состоящий из исходников bpas в zip с сохранением структуры подкаталогов исходных файлов.
deploy (в нашем случае выгрузка в репозиторий) – Собранный на фазе assembly zip отправляется в локальный репозиторий Maven с добавлением к нему pom.xml и другой информации по пакету. Данная процедура почти идентична нормальному deploy jar файла, но с особыми параметрами.

clean (очистка) – Данная фаза не входит в общий ЖЦ фаз сборки, а стоит несколько особняком, но поскольку она также была модернизирована, ее тоже стоит упомянуть. Кроме стандартного удаления директории, в которой лежат скомпилированные файлы. (targetDirectory), потребовалось удалять тот мусор, который образуется в процессе скачивания и распаковки пакетов-зависимостей.

Общая структура pom.xml

Я условно делю pom.xml на две части: заголовок и сборка.

Сборка (тег build) — это вторая часть pom.xml, в которой настраиваются особенности обработки той или иной фазы жизненного цикла различными плагинами с недефолтными настройками. Кроме этого там настраиваются директории и параметры, которые будут участвовать в сборке проекта:
sourceDirectory – директория, в которой находятся исходники для компиляции.
finalName – конечное имя файла после запаковки в архив.
directory – рабочая директория, в которую будут положены скомпилированные файлы.
Кроме этого еще раз хочу напомнить, что для всех этих параметров, существуют значения по умолчанию, и их отдельное указание в нашем случае требуется только потому, что они должны отличаться от этих самых умолчаний.

Реализация ЖЦ в теге build

Теперь вернемся к определенному нами ЖЦ и посмотрим, как каждая из фаз жизненного цикла реализована при помощи вызова нужного плагина с той конфигурацией, которая нам нужна.

initialize

Тут опять давайте немного отвлечемся и отдельно упомянем тег properties. Объясним, зачем он нужен и как используется.

Если говорить очень грубо, то этот тег похож на объявление констант, которые в дальнейшем будут использоваться в нашей программе (pom.xml). Но попадать туда значения могут тремя разными способами. И у каждого способа есть приоритет, определяющий, какое в итоге значение будет в тот момент, когда оно реально потребуется.

Низший приоритет у прямой записи свойств в тег properties, например так:

Более высокий приоритет у прямого задания параметров при запуске Maven, примерно так «mvn –DhelloText=Hi initialize»
При запуске Maven с таким параметром исходное значение тега helloText будет заменено на переданное в строке запуска для текущего сеанса, т.е. в xml оно не сохранится. Если такой константы вообще не существовало, то на этот сеанс она будет существовать и может быть использована. Значения всех несуществующих констант — пустая строка.

Наивысшим приоритетом обладает добавление значений в тег proprties плагинами в текущей сессии. Они так же не сохраняться в pom.xml. Именно этот механизм и будет использован нами для вынесения отдельных настроек сборки в properties файл, содержащий “имя=значение”
Для этого используется плагин properties-maven-plugin

Кроме интересного решения по вынесению зависимых от контекста настроек в отдельный файл здесь присутствует хорошая демонстрация того как один и тот же плагин запускается в совершенно разные фазы жизненного цикла. Это обеспечивается за счет тега <executions/>, где для каждой нужной фазы создается отдельный тег <execution/>. Тег <execution/>должен включать в себя уникальный id(если execution больше одного), а так же может содержать отдельный тег configuration приоритет которого выше всех остальных.

generate-sources

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

Конструкция $ означает, что нужно взять значение из тега “/project/properties/packagesPath”.

Отдельно хочу отметить, что использования плагина maven-assembly-plugin для распаковки считается deprecated и не рекомендуется к использованию в Maven 3. Вместо него используется maven-dependency-plugin с настройками аналогичными указанным выше. Я же использую более старую версию плагина, чтобы еще раз наглядно показать, как один и тот же плагин настраивается на выполнение нескольких задач из его ассортимента.

compile

Со стадией компиляции пришлось изрядно повозиться, но основные трудности возникли с написанием собственного плагина компиляции. Пошаговая инструкция по написанию собственного плагина для Maven — это тема для отдельной статьи, поэтому сейчас мы не будем заострять на этом внимание. В конце-концов изложенный здесь материал может быть использован и для скриптовых языков, компиляция которым вообще не требуется.
Одно можно сказать наверняка, как бы вы не старались, не удастся отключить запуск родного плагина maven-compile-plugin, призвание которого компилировать исходники на Java( Не рассматривая возможности редактирования superPom.xml). Итак настройки моего плагина компиляции выглядят следующим образом:

используемые параметры:
protectionServer — сервер защиты, без которого невозможен запуск компилятора командной строки.
protectionAlias — секция используемой лицензии сервера защиты.
bpasccPath — полный или относительный путь к компилятору командной строки.
binaryVersion — Версия, которая будет «вмонтирована» в скомпилированную библиотеку.

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

assembly

При прохождении фазы assembly у Maven по умолчанию настроен запуск maven-assembly-plugin, явно указав его запуск в фазе assembly в теге build, мы можем переопределить его настройки и заставить работать на нас. Этот же плагин мы использовали для распаковки пакетов перед компиляцией, поэтому теперь я приведу полную версию настроек этого плагина, включающую и запаковку и распаковку.

Здесь мы видим вторую секцию execution с и необходимую для этой фазы настройку ..\src.xml. В src.xml содержатся настройки того, как необходимо запаковать исходники. На самом деле все эти настройки можно поместить прямо в теге descriptor, но это может сильно загромоздить pom.xml.
Приведем пример src.xml для полноты картины.

packagesDirName — это константа из /project/properties файла pom.xml
Отдельно хочу отметить, что такое вынесение настроек запаковки в отдельный файл, позволило мне создать один конфиг запаковки на все Пакеты, что крайне удобно.

deploy

Фаза deploy так же запускается Maven'ом независимо от того, указали ли мы настройки этого плагина или нет. Переопределив их, мы и этот плагин заставили работать на себя.

С такими ручными настройками maven-deploy-plugin позволяет любой файл(или даже группу файлов) выложить в репозиторий Maven как валидную библиотеку(Пакет). Теперь разберем настройки по порядку.
file — файл, который будет отправлен в репозиторий Maven как Пакет.
url — путь к репозиторию Maven
repositoryId — идентификатор репозитория, в который будет производиться депллой.
groupId, artifactId, version — стандартная идентификация пакета в репозитории Maven. Именно по этим трем параметрам можно однозначно идентифицировать библиотеку. packaging – функционал деплой так же включает в себя запаковку файлов, которые будут отправлены в репозиторий, поэтому необходимо снова указать ему zip, чтобы он ничего не делал с пакетом, иначе распакует и запакует как jar :-).
pomFile – если данный параметр указан, то в комплект к Пакету будет добавлен тот файл, который мы укажем как pom.xml, при этом его изначальное имя может быть другим. Сохранять оригинальный pom.xml выгодно по многим причинам, поэтому мы не будем брезговать данной возможностью.

clean

Фаза clean, как я уже говорил, не входит в стандартный ЖЦ. Изначальная ее задача состоит в том, чтобы после выполнения команды mvn clean в проекте не осталось никаких следов жизнедеятельности. В нашем случае кроме стандартной папки targetSource(указана в теге build) требуется так же удалить все Пакеты, которые были «слиты» как зависимости для успешной компиляции пакета/проекта.

directory — собственно указание директории, которую необходимо удалить. Надо отметить, что тут создатели плагина отошли от общепринятой концепции, и явное указание настроек плагина не отменяет его действий по умолчанию. Но в данном случае, это очень хорошо, т. к. избавляет нас от лишний настроек.

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

Итоги

phase и goal их взаимосвязь между собой и плагинами.
создание архитипов — шаблон проекта для быстрого развертывания своей конфигурации pom.xml и набора файлов по умолчанию.
репозитории Maven и управление ими.
как написать и отладить свой плагин для Maven.
как НЕ писать свой плагин под каждый «чих».

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

Мой компьютер работает под управлением Windows 10 и я работаю с Java и Eclipse. Недавно Windows предупредила меня, что у меня мало места на диске, и после некоторых исследований я заметил, что у меня есть папка с именем .m2 в папке моего пользователя ( C:UsersMySelf ), который занимает 202Gb.

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

безопасно ли просто удалить содержимое папки или я должен запустить какой-то конкретный процесс, чтобы сэкономить место и сохранить Maven хорошо работать?

- Это совершенно безопасно удалить папку .m2/.repository как maven будет повторно загружать все необходимые зависимости, когда это необходимо за исключением локальных проектов. Это там любая другая папка под .m2 занимая место?

для ваших местных проектов maven будет жаловаться на то, что не находит их. В этом случае вам просто нужно повторно скомпилировать их и установить. Они будут загружены в репозиторий mvn clean install

вы даже можете создать новую папку на диске D или любом другом диске. И используй его.

не обязательно, что вы используете .папка m2 создана по умолчанию.

также измените это на новый путь:

изменить настройки, как показано на рисунке ниже:

удалить .папка m2, а затем убедитесь, что все проекты имеют только новые версии / требуется версия входа опарника в pom.XML. Перестройте проект. Этот.папка m2 останется только с последней версией

совет: держите IDE и необходимые проекты открытыми, чтобы предотвратить их удаление.

Maven загружает все зависимости в папку .m2/repository в домашнем каталоге пользователя (т. е. C:\users\[your user name]\.m2\repository на Windows. При удалении этой папки Maven создает папку и загружает зависимости для создаваемых проектов.

активируйте его, установите его на путь, который вам нравится, например, сделайте Maven скачать зависимости в D:\myMavenRepository установить

просто откройте eclipse-->window-->preferences-->maven-->user settings-->там см. "Local repository location". затем найдите место для своего .папка m2 / repository затем удалите эту папку, если ваш maven работает неправильно.

Читайте также: