Publish detekt-bom module

[arturbosch]

No description provided.

[codecov]

Codecov Report

Merging #2814 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #2814      +/-   ##
============================================
+ Coverage     80.52%   80.54%   +0.02%     
- Complexity     2323     2335      +12     
============================================
  Files           386      387       +1     
  Lines          6957     6987      +30     
  Branches       1262     1265       +3     
============================================
+ Hits           5602     5628      +26     
  Misses          726      726              
- Partials        629      633       +4     

Impacted Files	Coverage Δ	Complexity Δ
...arturbosch/detekt/rules/naming/IsPropertyNaming.kt	85.18% <0.00%> (ø)	12.00% <0.00%> (?%)
...tlab/arturbosch/detekt/rules/naming/NamingRules.kt	93.33% <0.00%> (+0.35%)	18.00% <0.00%> (ø%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0649ece...bc4ee6f. Read the comment docs.

[BraisGabin]

🤔 If we publish the bom... should we keep ktlint in or bom? I use detekt and ktlint as different tools.

[arturbosch]

If we publish the bom... should we keep ktlint in or bom? I use detekt and ktlint as different tools.

The question is when to use the detekt pom? Who will use it?

Users embedding detekt or write custom rules? -> KtLint should be included

Normal users of the cli or gradle plugin won't need it, right?

[BraisGabin]

Users embedding detekt or write custom rules? -> KtLint should be included

Should it? Should I align my custom rules with the format plugin?

Should we create a different bom for the format plugin? This bom should contain the detekt bom plus the format plugin dependencies (ktlint).

[arturbosch]

Users embedding detekt or write custom rules? -> KtLint should be included

Should it? Should I align my custom rules with the format plugin?

Should we create a different bom for the format plugin? This bom should contain the detekt bom plus the format plugin dependencies (ktlint).

Your right. detekt-formatting is an extension and its dependencies shouldn't be included in the bom.
But as a rule authors do I really need to include the bom? Or is api enough?

From the point of view of the sonarqube and intellij plugin collaborator I want to have one bom with all dependencies :).
But there shouldn't be any problems with including KtLint as a transitive dependency in this cases.

[calvarez-ov]

We have a nexus repository which mirrors other repositories.

In our mirror, we somehow managed to retrieve this file:
https://<our nexus repo>/repository/maven-public/io/gitlab/arturbosch/detekt/detekt-bom/1.10.0/detekt-bom-1.10.0.module

With the following content:

You are using a deprecated resolve URL for Pentaho projects. The correct resolve URL is:

https://nexus.pentaho.org/content/groups/omni

Please refer to the official Pentaho Documentation on how to build Pentaho projects with Maven:

https://github.com/pentaho/maven-parent-poms/wiki

This is a sample settings.xml file that could be used in your local build environment:

https://github.com/pentaho/maven-parent-poms/blob/master/maven-support-files/settings.xml

This caused the following build failure:

> Could not resolve all files for configuration ':detekt'.
   > Could not resolve io.gitlab.arturbosch.detekt:detekt-cli:1.10.0.
     Required by:
         project : 
      > Could not resolve io.gitlab.arturbosch.detekt:detekt-cli:1.10.0.
         > Could not parse POM http://nexus:8081/repository/maven-public/io/gitlab/arturbosch/detekt/detekt-cli/1.10.0/detekt-cli-1.10.0.pom
            > Could not resolve io.gitlab.arturbosch.detekt:detekt-bom:1.10.0.
               > Could not resolve io.gitlab.arturbosch.detekt:detekt-bom:1.10.0.
                  > Could not parse module metadata http://nexus:8081/repository/maven-public/io/gitlab/arturbosch/detekt/detekt-bom/1.10.0/detekt-bom-1.10.0.module
                     > Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1 path $

Could this possibly be a problem of the packaging of detekt? Or a problem with our nexus repository configuration?

We resolved this by deleting the detekt-bom-1.10.0.module file from our mirror.

[cortinico]

Could this possibly be a problem of the packaging of detekt? Or a problem with our nexus repository configuration?

A mixture of the two. You nexus is considering an error page a valid artifact and storing it (maybe this should be disabled in the configuration).
On the other hand, we're failing and publish all the needed files (specifically detekt-bom-1.10.0.module is missing). I've opened an issue to fix this #2878. Let's follow over there.