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-unsubscr...@flink.apache.org

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


Reply via email to