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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
