Maven. Ignored Files
Use this page to specify the pom.xml files or their paths of Maven modules, which you want to exclude from the project when you ignore a Maven subproject.
Enter the comma-separated list of paths to be ignored during the build. Wildcards are honored. For example, entering * will ignore all the files in the project. You can use Maven tool window to edit the specified patterns.
Check the individual files to be ignored during the build. If you have a multi-module project, IntelliJ IDEA lists all POM files of your project. Selecting the checkbox against a POM file will equal ignoring the project or module in the Maven structure. You can also use the Maven tool window to ignore or unignore projects from the importing.
To unignore the files, clear the checkboxes against them.
Настройка проекта для исключения определенных нарушений сонара
Во время наших сборок мы можем использовать различные инструменты, чтобы сообщать о качестве нашего исходного кода. Одним из таких инструментов является SonarQube , выполняющий статический анализ кода.
Иногда мы можем не согласиться с возвращенными результатами. Поэтому мы можем захотеть исключить некоторый код, который был неправильно помечен SonarQube.
В этом коротком уроке мы рассмотрим, как отключить проверки Sonar. Хотя можно изменить набор правил на сервере SonarQube, мы сосредоточимся только на том, как управлять отдельными проверками в исходном коде и конфигурации нашего проекта.
2. Пример нарушения
Давайте посмотрим на пример:
public void printStringToConsoleWithDate(String str) System.out.println(LocalDateTime.now().toString() + " " + str); > По умолчанию SonarQube сообщает об этом коде как о запахе кода из-за нарушения правила java :S106 :
Однако давайте представим, что для этого конкретного класса мы решили, что ведение журнала с помощью System.out допустимо . Может быть, это легкая утилита, которая будет работать в контейнере и не нуждается в целой библиотеке журналирования только для входа в стандартный вывод .
Следует отметить, что также можно пометить нарушение как ложноположительное в пользовательском интерфейсе SonarQube. Однако если код будет анализироваться на нескольких серверах или если после рефакторинга строка переместится в другой класс, то нарушение появится снова.
Иногда мы хотим сделать наши исключения в репозитории исходного кода, чтобы они сохранялись.
Итак, давайте посмотрим, как мы можем исключить этот код из отчета SonarQube, настроив проект.
3. Использование // НОСОНАР
Мы можем отключить одну строку кода, поставив // NOSONAR в конце :
System.out.println( LocalDateTime.now() .toString() + " " + str); //NOSONAR lightweight logging Тег // NOSONAR в конце строки подавляет все проблемы, которые могут возникнуть в связи с этим. Этот подход работает для большинства языков, поддерживаемых SonarQube .
Нам также разрешено оставлять некоторые дополнительные комментарии после NOSONAR, объясняющие, почему мы отключили проверку.
Давайте двинемся дальше и рассмотрим специфичный для Java способ отключения проверок.
4. Использование @SuppressWarnings
4.1. Аннотирование кода
В Java мы можем исключить проверки Sonar с помощью встроенной аннотации @SuppressWarnings .
Мы можем аннотировать функцию:
@SuppressWarnings("java:S106") public void printStringToConsoleWithDate(String str) System.out.println(LocalDateTime.now().toString() + " " + str); > Это работает точно так же, как подавление предупреждений компилятора. Все, что нам нужно сделать, это указать идентификатор правила, в данном случае java:S106 .
4.2. Как получить идентификатор
Мы можем получить идентификатор правила, используя пользовательский интерфейс SonarQube. Когда мы смотрим на нарушение, мы можем щелкнуть Почему это проблема? :
Он показывает нам определение. Отсюда мы можем найти идентификатор правила в правом верхнем углу:
5. Использование sonar-project.properties
Мы также можем определить правила исключения в файле sonar-project.properties , используя свойства анализа .
Давайте определим и добавим файл sonar-project.properties в наш каталог ресурсов:
sonar.issue.ignore.multicriteria=e1 sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106 sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java Мы только что объявили наш самый первый мультикритерий с именем e1 . Мы исключили правило java:S106 для класса SonarExclude . Наше определение может смешивать исключения, используя идентификаторы правил и шаблоны сопоставления файлов , соответственно, в свойствах ruleKey и resourceKey , которым предшествует тег имени e1 .
Используя этот подход, мы можем создать сложную конфигурацию, которая исключает определенные правила для нескольких файлов:
sonar.issue.ignore.multicriteria=e1,e2 # Console usage - ignore a single class sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106 sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java # Too many parameters - ignore the whole package sonar.issue.ignore.multicriteria.e2.ruleKey=java:S107 sonar.issue.ignore.multicriteria.e2.resourceKey=com/foreach/sonar/*.java Мы только что определили подмножество multicriteria . Мы расширили нашу конфигурацию, добавив второе определение и назвав его e2 . Затем мы объединили оба правила в одно подмножество, разделив имена запятыми.
6. Отключить с помощью Maven
Все свойства анализа можно также применить с помощью свойств Maven . Подобный механизм также доступен в Gradle .
6.1. Мультикритерии в Maven
Возвращаясь к примеру, давайте изменим наш pom.xml :
properties> sonar.issue.ignore.multicriteria>e1sonar.issue.ignore.multicriteria> sonar.issue.ignore.multicriteria.e1.ruleKey>java:S106sonar.issue.ignore.multicriteria.e1.ruleKey> sonar.issue.ignore.multicriteria.e1.resourceKey> **/SonarExclude.java sonar.issue.ignore.multicriteria.e1.resourceKey> properties> Эта конфигурация работает точно так же, как если бы она использовалась в файле sonar-project.properties .
6.2. Сужение фокуса
Иногда анализируемый проект может содержать некоторый сгенерированный код, который мы хотим исключить и сузить фокус проверок SonarQube.
Давайте исключим наш класс, определив sonar.exclusions в нашем pom.xml :
properties> sonar.exclusions>**/SonarExclude.javasonar.exclusions> properties> В этом случае мы исключили один файл по его имени. Проверки будут выполняться для всех файлов, кроме этого.
Мы также можем использовать шаблоны сопоставления файлов. Давайте исключим весь пакет, определив:
properties> sonar.exclusions>com/foreach/sonar/*.javasonar.exclusions> properties> С другой стороны, используя свойство sonar.inclusions , мы можем попросить SonarQube проанализировать только определенное подмножество файлов проекта:
properties> sonar.inclusions>com/foreach/sonar/*.javasonar.inclusions> properties> Этот фрагмент определяет анализ только для java-файлов из пакета com.foreach.sonar .
Наконец, мы также можем определить значение sonar.skip :
properties> sonar.skip>truesonar.skip> properties> Это исключает весь модуль Maven из проверок SonarQube.
7. Заключение
В этой статье мы обсудили различные способы подавления определенного анализа SonarQube в нашем коде.
Мы начали с исключения проверок на отдельных линиях. Затем мы рассказали о встроенной аннотации @SuppressWarnings и исключении по определенному правилу. Это требует от нас найти идентификатор правила.
Мы также рассмотрели настройку свойств анализа. Мы попробовали мультикритерий и файл sonar-project.properties .
Наконец, мы переместили наши свойства в файл pom.xml и рассмотрели другие способы сузить фокус.
- 1. Обзор
- 2. Пример нарушения
- 3. Использование // НОСОНАР
- 4. Использование @SuppressWarnings
- 4.1. Аннотирование кода
- 4.2. Как получить идентификатор
- 6.1. Мультикритерии в Maven
- 6.2. Сужение фокуса
IntelliJ pom.xml crossed out → Can’t build project/module
This is just a quick “hack” which kept me quite busy for some time and it was super frustrating as I thought that my code might has issues or that my IntelliJ installation is just broken.
Ignored Files:
Please let me know why you would want to have ignored pom files in IntelliJ project structure, I can actually not think of any case where I would like to have them. But what happened.
As I’m working with around 20 modules in a single IntelliJ project which have dependencies with each other IntelliJ is just awesome to linka module to another module and debug it in the main application.
But to do this it needs a module within the same IntelliJ project so that it can link it together.
Everything worked fine up until some point where just some of my pom files looked like this
They got crossed out.
I can’t build the project anymore, I can’t to a “Maven rebuild”. Nothing.
I tried to overcome this by adding the module again. I deleted the full module and downloaded it again. I added the single sub modules and not only the parent module of the libraries I’m using. I removed the internal IntelliJ Settings file *.iml files.
Nothing worked.
So the only workaround was to create an entire new project. There everything was working. But migrating 15 different “Build plans” and 12 different “Run Configurations” is just a pain in the ass.
God bless, there is a fix for it!
If you go to “Settings” → “Build,Execution,Deployment” →”Build Tools” → “Maven” → “Ignored Files” there you can see a bunch of Ignored Files
Honestly I don’t have any clue how they got there but this is actually the solution to the problem. Just uncheck all the Files and “Tadaaa”
Now all modules are available again.
pom.xml игнорируется intellij как пофиксить
Делала rebase чтобы собрать все коммиты в один — пропал .iml файл. Восстановила его с помощью просмотра локальной истории в IntellijIDEA. Модуль снова стал подсвечиваться, но вот помник — нет: Слева видно, что пом серый и зачеркнутый, а справа восстановленный iml файл. Как починить?
Отслеживать
задан 24 мар 2021 в 9:58
408 3 3 серебряных знака 17 17 бронзовых знаков
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
правой кнопкой мыши на pom -> maven -> unignore Projects
Отслеживать
ответ дан 24 авг 2022 в 8:16
828 7 7 серебряных знаков 18 18 бронзовых знаков