Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ExternalRules enforcer rule #27294

Merged
merged 1 commit into from
Aug 30, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
142 changes: 23 additions & 119 deletions build-parent/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -60,7 +60,7 @@
<m2e.apt.activation>jdt_apt</m2e.apt.activation>

<!--
Supported Maven versions, interpreted as a version range
Supported Maven versions, interpreted as a version range (Also defined in quarkus-enforcer-rules)
-->
<supported-maven-versions>[3.6.2,)</supported-maven-versions>

Expand Down Expand Up @@ -485,130 +485,34 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-enforcer-rules</artifactId>
<version>${project.version}</version>
</dependency>
<!-- This dependency can be removed when MENFORCER-422 is available -->
<dependency>
<groupId>com.github.gastaldi</groupId>
<artifactId>enforcer-rules</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>enforce</id>
<configuration>
<rules>
<dependencyConvergence/>
<requireJavaVersion>
<version>[${maven.compiler.release},)</version>
</requireJavaVersion>
<requireMavenVersion>
<version>${supported-maven-versions}</version>
</requireMavenVersion>
<!-- Disabled due to https://issues.apache.org/jira/browse/MENFORCER-359 (3.0.0-M3)
3.0.0 suffers from https://issues.apache.org/jira/browse/MENFORCER-394, so we need to wait for a fixed release.
<requirePluginVersions>
<phases>compile</phases>
<unCheckedPluginList>io.quarkus:quarkus-extension-maven-plugin,io.quarkus:quarkus-bootstrap-maven-plugin,io.quarkus:quarkus-maven-plugin</unCheckedPluginList>
</requirePluginVersions>-->
<bannedDependencies>
<excludes>
<!-- Use Jakarta artifacts instead of JBoss specific ones -->
<exclude>org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec</exclude>
<exclude>org.jboss.spec.javax.annotation:jboss-annotations-api_1.3_spec</exclude>
<exclude>org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec</exclude>
<exclude>org.jboss.spec.javax.transaction:jboss-transaction-api_1.3_spec</exclude>
<exclude>org.jboss.spec.javax.servlet:jboss-servlet-api_4.0_spec</exclude>
<exclude>org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec</exclude>
<exclude>org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec</exclude>
<exclude>org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec</exclude>
<exclude>org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec</exclude>
<exclude>org.jboss.spec.javax.el:jboss-el-api_3.0_spec</exclude>
<!-- except for these 2 for now as most of the RESTEasy optional artifacts depend on them
<exclude>org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.1_spec</exclude>
<exclude>org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.3_spec</exclude>
-->
<exclude>jakarta.xml.bind:jakarta.xml.bind-api</exclude>
<exclude>jakarta.ws.rs:jakarta.ws.rs-api</exclude>
<!-- Exclude javax dependencies in favor of Jakarta -->
<exclude>javax.activation:activation</exclude>
<exclude>javax.activation:javax.activation-api</exclude>
<exclude>javax.annotation:javax.annotation-api</exclude>
<exclude>javax.enterprise:cdi-api</exclude>
<exclude>javax.inject:javax.inject</exclude>
<exclude>javax.json:javax.json-api</exclude>
<exclude>javax.json.bind:javax.json.bind-api</exclude>
<exclude>org.glassfish:javax.json</exclude>
<exclude>org.glassfish:javax.el</exclude>
<exclude>javax.persistence:javax.persistence-api</exclude>
<exclude>javax.persistence:persistence-api</exclude>
<exclude>javax.security.enterprise:javax.security.enterprise-api</exclude>
<exclude>javax.servlet:servlet-api</exclude>
<exclude>javax.servlet:javax.servlet-api</exclude>
<exclude>javax.transaction:jta</exclude>
<exclude>javax.transaction:javax.transaction-api</exclude>
<exclude>javax.validation:validation-api</exclude>
<exclude>javax.xml.bind:jaxb-api</exclude>
<exclude>javax.websocket:javax.websocket-api</exclude>
<exclude>javax.ws.rs:javax.ws.rs-api</exclude>
<!-- Exclude jakarta.activation-api as the implementation contains it -->
<exclude>jakarta.activation:jakarta.activation-api</exclude>
<!-- use our jboss-logmanager -->
<exclude>org.jboss.logging:jboss-logmanager</exclude>
<exclude>org.jboss.logging:jboss-logging-jdk</exclude>
<!-- We don't want all the API's in one jar-->
<exclude>javax:javaee-api</exclude>
<!-- Prevent incompatible config from coming in -->
<exclude>org.wildfly.client:wildfly-client-config</exclude>
<exclude>org.jboss.marshalling:jboss-marshalling-osgi</exclude>
<exclude>org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec</exclude>
<!-- The API is packaged by the implementation-->
<exclude>jakarta.json:jakarta.json-api</exclude>
<!-- Ensure none of the deps use netty-all. This forces deps to use more fine grained netty artifacts -->
<exclude>io.netty:netty-all</exclude>
<!-- Ban jboss-logmanager, we use jboss-logmanager-embedded -->
<exclude>org.jboss.logmanager:jboss-logmanager</exclude>
<!-- Ban Log4J (use org.jboss.logmanager:log4j-jboss-logmanager instead) -->
<exclude>log4j:log4j</exclude>
<exclude>org.apache.logging.log4j:log4j-core</exclude>
<exclude>org.apache.logging.log4j:log4j-slf4j-impl</exclude>
<!-- Ban commons-logging (use org.jboss.logging:commons-logging-jboss-logging instead) -->
<exclude>commons-logging:commons-logging</exclude>
<exclude>commons-logging:commons-logging-api</exclude>
<exclude>org.springframework:spring-jcl</exclude>
<exclude>org.slf4j:jcl-over-slf4j</exclude>
<!-- Ban SLF4j implementations (use org.jboss.slf4j:slf4j-jboss-logmanager instead) -->
<exclude>org.jboss.slf4j:slf4j-jboss-logging</exclude>
<exclude>org.slf4j:slf4j-simple</exclude>
<exclude>org.slf4j:slf4j-nop</exclude>
<exclude>org.slf4j:slf4j-jdk14</exclude>
<exclude>org.slf4j:slf4j-log4j12</exclude>
<exclude>org.slf4j:slf4j-log4j13</exclude>
<!-- Ban Logback implementations -->
<exclude>ch.qos.logback:logback-classic</exclude>
<exclude>ch.qos.logback:logback-core</exclude>
<exclude>ch.qos.logback:logback-access</exclude>
<exclude>ch.qos.logback:logback</exclude>
<exclude>org.osgi:org.osgi.annotation.versioning</exclude>
<!-- Ban Spring Dependencies (since we have our own jars)-->
<exclude>org.springframework:spring-core</exclude>
<exclude>org.springframework:spring-beans</exclude>
<exclude>org.springframework:spring-context</exclude>
<exclude>org.springframework:spring-web</exclude>
<exclude>org.springframework:spring-webmvc</exclude>
<exclude>org.springframework.data:spring-data-jpa</exclude>
<exclude>org.springframework.data:spring-data-commons</exclude>
<exclude>org.springframework.security:spring-security-core</exclude>
<exclude>org.springframework.boot:spring-boot</exclude>
<!-- Ban checker-qual, we don't use Checker Framework -->
<exclude>org.checkerframework:checker-qual</exclude>
<!-- We use our own impl here, including this one causes problems-->
<exclude>org.jboss.resteasy:resteasy-context-propagation</exclude>
<exclude>com.google.android:annotations</exclude>
<exclude>org.codehaus.mojo:animal-sniffer-annotations</exclude>
<!-- Includes its own copy of an old version of the servlet API-->
<exclude>org.apache.tomcat.embed:tomcat-embed-core</exclude>
<exclude>org.jboss.modules:jboss-modules</exclude>
<!-- We prefer ByteBuddy where possible -->
<exclude>org.javassist:javassist</exclude>
</excludes>
<includes>
<!-- this is for REST Assured -->
<include>jakarta.xml.bind:jakarta.xml.bind-api:*:*:test</include>
</includes>
</bannedDependencies>
<externalRules>
<location>classpath:enforcer-rules/quarkus-require-java-version.xml</location>
</externalRules>
<externalRules>
<location>classpath:enforcer-rules/quarkus-require-maven-version.xml</location>
</externalRules>
<externalRules>
<location>classpath:enforcer-rules/quarkus-banned-dependencies.xml</location>
</externalRules>
</rules>
</configuration>
<goals>
Expand Down
10 changes: 10 additions & 0 deletions independent-projects/enforcer-rules/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,10 @@
<maven-core.version>3.8.6</maven-core.version>

<nexus-staging-maven-plugin.version>1.6.8</nexus-staging-maven-plugin.version>
<!--
Supported Maven versions, interpreted as a version range (Also defined in build-parent)
-->
<supported-maven-versions>[3.6.2,)</supported-maven-versions>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it makes sense to define this one here. Rationale: the supported Maven version really depends on the project you are currently building and Quarkus has nothing to do with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, isn't that important for our Maven plugins?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be interested to get <supported-maven-versions> in Camel Quarkus. I think there will inevitably be entries in this rules file that we won't be wanting to enforce. A XSLT pre-filtering will solve all such issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we split the rules into several files (one for each rule type)?
e.g.

  • quarkus-require-java-version.xml;
  • quarkus-require-maven-version.xml;
  • quarkus-banned-dependencies.xml

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we split the rules into several files

Hm... how do I get notified that there is a new rule file?

Copy link
Contributor Author

@gastaldi gastaldi Aug 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could still have a quarkus-default.xml with <enforcerRules> to each of these individual files which if you use it you don't need to bother about new rule files.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move this to the global parent pom, wouldn't it be available everywhere?

Copy link
Contributor Author

@gastaldi gastaldi Aug 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What global parent pom are you talking about? quarkus-enforcer-rules has jboss-parent as the parent because it's an independent project

</properties>

<dependencies>
Expand Down Expand Up @@ -72,6 +76,12 @@
</dependencies>

<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-invoker-plugin</artifactId>
Expand Down
Loading