[GitHub] [flink] codecholeric commented on pull request #18333: [FLINK-25220][test] Write an architectural rule for all IT cases w.r.t. the MiniCluster

[GitBox <gi...@apache.org>]

codecholeric commented on pull request #18333:
URL: https://github.com/apache/flink/pull/18333#issuecomment-1012456359


   Hey, I quickly looked over it (it's quite late for me already :wink:), but here are my 2 cents why things probably differ (as you already guessed in the last comments):
   
   For the case of `KafkaShuffleITCase` or `FlinkKafkaInternalProducerITCase` the `test-jar` goal is defined like this:
   
   ```
   <plugin>
   	<groupId>org.apache.maven.plugins</groupId>
   	<artifactId>maven-jar-plugin</artifactId>
   	<executions>
   		<execution>
   			<goals>
   				<goal>test-jar</goal>
   			</goals>
   			<configuration>
   				<includes>
   					<include>**/KafkaTestEnvironment*</include>
   					<include>**/testutils/*</include>
   					<include>META-INF/LICENSE</include>
   					<include>META-INF/NOTICE</include>
   				</includes>
   			</configuration>
   		</execution>
   	</executions>
   </plugin>
   ```
   
   AFAIK IntelliJ doesn't support this fine-grained configuration. It emulates Maven and if there is `<goal>test-jar</goal>` in one project and `<type>test-jar</type>` as dependency in another, then it will simply dump all classes compiled from `src/test/java` (i.e. `target/test-classes`) onto the classpath. I think that's why `KafkaShuffleITCase` doesn't appear when you run it with Maven (I also checked the contents of the `test-jar` archive and `KafkaShuffleITCase` is indeed not contained).
   
   I see 2 solutions:
   
   1) do you really need this optimization to only include a little bit of those classes in the test jars? Most other modules seem to simply dump everything in the test jars, which makes it simpler and the difference here should vanish (after all test jars are not released, right? Thus, maybe it's not really relevant to optimize for a couple KB more or less?)
   2) exclude those classes from the test, even though they are not tested with Maven (but then it also doesn't hurt)
   
   Theoretically there would be 3), don't go via classpath, but compile everything and then just put in the Flink root folder to look for `.class` files on the file system, but I wouldn't go this way if you can get around it.
   
   If there is any way, I would simply follow 1), because that's also the only way to really test all relevant classes in a downstream module.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org