Re: Review Request 4363: [IntelliJ] Detect project changes in order to determine noop compile. i.e. immediate launch of test runner.

3 views
Skip to first unread message

Yi Cheng

unread,
Nov 11, 2016, 3:18:21 AM11/11/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng
This is an automatically generated e-mail. To reply, visit: https://rbcommons.com/s/twitter/r/4363/

Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.
By Yi Cheng.

Updated Nov. 11, 2016, 8:18 a.m.

Summary (updated)

[IntelliJ] Detect project changes in order to determine noop compile. i.e. immediate launch of test runner.
Repository: intellij-pants-plugin

Description (updated)

Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.


This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 



Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    •

Testing (updated)

https://travis-ci.org/pantsbuild/intellij-pants-plugin/builds/175003947

Diffs (updated)

  • common/com/twitter/intellij/pants/util/PantsConstants.java (effc506894780d3f386e8f06997dad197f83a9d3)
  • src/com/twitter/intellij/pants/components/impl/PantsProjectComponentImpl.java (d272eb2ef5fbc9ddab1a87e9f2f9ad652dbbdb9a)
  • src/com/twitter/intellij/pants/execution/PantsMakeBeforeRun.java (0122a68beb986d53f849abbb74a30fd881fba818)
  • src/com/twitter/intellij/pants/file/FileChangeTracker.java (PRE-CREATION)
  • src/com/twitter/intellij/pants/settings/PantsExecutionSettings.java (be36768619b0886253c9cfd0b0a9a0bf98519df4)
  • src/com/twitter/intellij/pants/settings/PantsProjectSettings.java (14799ba27ea5ff5f271133c80ef518d9f20717f1)
  • src/com/twitter/intellij/pants/settings/PantsSettings.java (c23e3fdbaa6d3d62ddccf2580dd32f64b2f2e803)
  • testFramework/com/twitter/intellij/pants/testFramework/PantsIntegrationTestCase.java (2b3aeacc1ff5d6e18401cffdc2482d12699192a2)
  • testFramework/com/twitter/intellij/pants/testFramework/runner/CustomProjectIntegrationTests.java (507dce3194e13de4e4ece33e3e5bada99b224158)
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedJavaReferenceQuickFixProviderTest.java (a1bcd1f6d821a15e2869ad5e8e933cbe5bc33c0b)
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedScalaReferenceQuickFixProviderTest.java (cc00bc4b9d81f283f24d652227a4dbd0f2cd09e1)
  • tests/com/twitter/intellij/pants/integration/NoopCompileTest.java (PRE-CREATION)
  • tests/com/twitter/intellij/pants/integration/OSSPantsExamplesMultiTargetsIntegrationTest.java (e56228dd8315911e2bea2ed03a50f6d04fb60684)
  • tests/com/twitter/intellij/pants/integration/OSSPantsFromScriptIntegrationTest.java (70cb0219f7f9334c26a766fb999f819ba4eddbba)
  • tests/com/twitter/intellij/pants/integration/OSSPantsJavaExamplesIntegrationTest.java (8e1b93a9e255f980811cb68e79406a8f0ab646bf)
  • tests/com/twitter/intellij/pants/integration/OSSPantsMakeIntegrationTest.java (8beb435eec489e309905e96cc4ca862e1ce27965)
  • tests/com/twitter/intellij/pants/integration/OSSPantsScalaExamplesIntegrationTest.java (bec2b23ac700c7edd95bf44d52854be16c402cc0)
  • tests/com/twitter/intellij/pants/integration/OSSPantsTestExamplesIntegrationTest.java (836b74c02ba37bd12c8e7cf7fb35f27d35074b24)

View Diff

Show Changes

Yi Cheng

unread,
Nov 11, 2016, 3:35:36 AM11/11/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng
This is an automatically generated e-mail. To reply, visit: https://rbcommons.com/s/twitter/r/4363/

Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.
By Yi Cheng.

Updated Nov. 11, 2016, 8:35 a.m.

Changes

correct some test method names.
Repository: intellij-pants-plugin

Description 

Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.


This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 



Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    •

Testing

Stu Hood

unread,
Nov 16, 2016, 3:27:14 PM11/16/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng
This is an automatically generated e-mail. To reply, visit: https://rbcommons.com/s/twitter/r/4363/

src/com/twitter/intellij/pants/file/FileChangeTracker.java (Diff revision 3) 

    56
    
  /**

  


  

    
    

    57
    
   * Determine whether a project should be recompiled given targets to compile and PantsSettings

  


  

    
    

    58
    
   * by comparing with the last one.

  


  

    
    

    59
    
   *

  


  

    
    

    60
    
   * @param project:         project under question.

  


  

    
    

    61
    
   * @param targetAddresses: target addresses for this compile.

  


  

    
    

    62
    
   * @return true if anything in the project has changed or the current `CompileSnapshot` does not match with

  


  

    
    

    63
    
   * the previous one.

  


  

    
    

    64
    
   */

  


  

    
    

    65
    
  public static boolean shouldRecompileThenReset(@NotNull Project project, @NotNull Set<String> targetAddresses) {

  


 




 


  
This will break if someone has compiled outside of intellij, such as on the CLI, right?

 













 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    77
    
      projectStates.put(project, Pair.create(false, Optional.of(snapshot)));

  


 




 


  
Updating the project state here means that this method isn't idempotent. IMO, should update the project state independently after a compile has actually succeeded. I can easily imagine a state where a cancelled/failed compile is considered to be clean.


But also, it's not at all obvious from the javadoc that this will mutate the state.

 













 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    103
    
    if (projectStates.containsKey(project)) {

  


  

    
    

    104
    
      projectStates.remove(project);

  


  

    
    

    105
    
    }

  


 




 


  
IIRC, remove works regardless of whether something is present... so no need to check first.

 













 
  

   
    src/com/twitter/intellij/pants/settings/PantsExecutionSettings.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    42
    
   * @param enableIncrementalImport: whether incrementally import the project.

  


 




 


  
whether to

 













 
  

   
    src/com/twitter/intellij/pants/settings/PantsSettings.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    23
    

    24
    

  


 




 


  
IMO, the project change detection should probably be optional for at least one release.

 









- Stu Hood






On November 11th, 2016, 8:35 a.m. UTC, Yi Cheng wrote:













Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.


By Yi Cheng.




Updated Nov. 11, 2016, 8:35 a.m.












 Repository: 
intellij-pants-plugin





Description 

 

 

  
   
Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.


This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 



Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    • 


  		
 






Testing 



 

  
   
https://travis-ci.org/pantsbuild/intellij-pants-plugin/builds/175003947

  		
 








Diffs 


Yi Cheng
unread,
Nov 16, 2016, 8:11:48 PM11/16/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng

   

    

     
      This is an automatically generated e-mail. To reply, visit:
      https://rbcommons.com/s/twitter/r/4363/
     
    

   

   













 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    56
    
  /**

  


  

    
    

    57
    
   * Determine whether a project should be recompiled given targets to compile and PantsSettings

  


  

    
    

    58
    
   * by comparing with the last one.

  


  

    
    

    59
    
   *

  


  

    
    

    60
    
   * @param project:         project under question.

  


  

    
    

    61
    
   * @param targetAddresses: target addresses for this compile.

  


  

    
    

    62
    
   * @return true if anything in the project has changed or the current `CompileSnapshot` does not match with

  


  

    
    

    63
    
   * the previous one.

  


  

    
    

    64
    
   */

  


  

    
    

    65
    
  public static boolean shouldRecompileThenReset(@NotNull Project project, @NotNull Set<String> targetAddresses) {

  


 




  
This will break if someone has compiled outside of intellij, such as on the CLI, right?

 









That is not the case. Out of band file IO will be caught as long as they are under any of the project content roots.


If a source file changes and a compile is issued on CLI, next time when user switches back to IntelliJ GUI, the system will detect changes on disk since user switched out of IntelliJ, hence the project will be marked as dirty.


If a compile was issued on CLI without any source change, then manifest.jar which IJ consumes won't change either.


However another caveat I just realize is ./pants clean-all isn't detected, but I think it can be resolved by having clean-all to remove dist/export-classpath/manifest.jar which would be likely be invalid anyway, and then have IntelliJ check for its existence.






 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    77
    
      projectStates.put(project, Pair.create(false, Optional.of(snapshot)));

  


 




  
Updating the project state here means that this method isn't idempotent. IMO, should update the project state independently after a compile has actually succeeded. I can easily imagine a state where a cancelled/failed compile is considered to be clean.


But also, it's not at all obvious from the javadoc that this will mutate the state.

 









A failed/cancelled build will caught at the end of PantsMakeBeforeRun https://rbcommons.com/s/twitter/r/4363/diff/3#2 so the project will be marked dirty.


Will update the javadoc.








- Yi
Yi Cheng
unread,
Nov 18, 2016, 9:42:24 PM11/18/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng

   

    

     
      This is an automatically generated e-mail. To reply, visit:
      https://rbcommons.com/s/twitter/r/4363/
     
    

   

   









Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.


By Yi Cheng.




Updated Nov. 19, 2016, 2:42 a.m.










 Bugs: 


 217









 Repository: 
intellij-pants-plugin





Description  (updated)

 

 

  
   
Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.


This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 

  • After a clean-all it will always trigger a pants call.
    • 

  • After dist/export-classpath/manifest.jar getting overwritten because of other out of band pants CLI, pants will be triggered.
    • 

Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    • 



Other changes:
* Test against major pants releases, current dev releases, and master.

  		
 






Testing (updated)



 

  
   
https://travis-ci.org/pantsbuild/intellij-pants-plugin/builds/177196230
https://travis-ci.org/pantsbuild/intellij-pants-plugin/builds/177197025

  		
 








Diffs (updated)


    

 
  • .travis.yml (7e95149655e046cb2b28535134f791a2b21cccaa)
    

 
  • common/com/twitter/intellij/pants/util/PantsConstants.java (effc506894780d3f386e8f06997dad197f83a9d3)
    • 

 
  • src/com/twitter/intellij/pants/components/impl/PantsProjectComponentImpl.java (d272eb2ef5fbc9ddab1a87e9f2f9ad652dbbdb9a)
    • 

 
  • src/com/twitter/intellij/pants/execution/PantsMakeBeforeRun.java (0122a68beb986d53f849abbb74a30fd881fba818)
    • 

 
  • src/com/twitter/intellij/pants/file/FileChangeTracker.java (PRE-CREATION)
    • 

 
  • src/com/twitter/intellij/pants/service/project/modifier/PantsTargetNamesShortenerModifier.java (434cf5fe828a652c50b2304ac32687ba7cb8cbfd)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsExecutionSettings.java (be36768619b0886253c9cfd0b0a9a0bf98519df4)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsProjectSettings.java (14799ba27ea5ff5f271133c80ef518d9f20717f1)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsProjectSettingsControl.java (83571d71c8de210d46e868ce02112c5390a1c19b)
    

 
  • src/com/twitter/intellij/pants/settings/PantsSettings.java (c23e3fdbaa6d3d62ddccf2580dd32f64b2f2e803)
    • 

 
  • testFramework/com/twitter/intellij/pants/testFramework/PantsIntegrationTestCase.java (2b3aeacc1ff5d6e18401cffdc2482d12699192a2)
    • 

 
  • testFramework/com/twitter/intellij/pants/testFramework/runner/CustomProjectIntegrationTests.java (507dce3194e13de4e4ece33e3e5bada99b224158)
    • 

 
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedJavaReferenceQuickFixProviderTest.java (a1bcd1f6d821a15e2869ad5e8e933cbe5bc33c0b)
    • 

 
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedScalaReferenceQuickFixProviderTest.java (cc00bc4b9d81f283f24d652227a4dbd0f2cd09e1)
    • 

 
  • tests/com/twitter/intellij/pants/integration/NoopCompileTest.java (PRE-CREATION)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsExamplesMultiTargetsIntegrationTest.java (e56228dd8315911e2bea2ed03a50f6d04fb60684)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsFromScriptIntegrationTest.java (70cb0219f7f9334c26a766fb999f819ba4eddbba)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsJavaExamplesIntegrationTest.java (8e1b93a9e255f980811cb68e79406a8f0ab646bf)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsMakeIntegrationTest.java (8beb435eec489e309905e96cc4ca862e1ce27965)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsScalaExamplesIntegrationTest.java (bec2b23ac700c7edd95bf44d52854be16c402cc0)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsTestExamplesIntegrationTest.java (836b74c02ba37bd12c8e7cf7fb35f27d35074b24)
    • 






Yi Cheng
unread,
Nov 18, 2016, 9:42:29 PM11/18/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng

   

    

     
      This is an automatically generated e-mail. To reply, visit:
      https://rbcommons.com/s/twitter/r/4363/
     
    

   

   













 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    56
    
  /**

  


  

    
    

    57
    
   * Determine whether a project should be recompiled given targets to compile and PantsSettings

  


  

    
    

    58
    
   * by comparing with the last one.

  


  

    
    

    59
    
   *

  


  

    
    

    60
    
   * @param project:         project under question.

  


  

    
    

    61
    
   * @param targetAddresses: target addresses for this compile.

  


  

    
    

    62
    
   * @return true if anything in the project has changed or the current `CompileSnapshot` does not match with

  


  

    
    

    63
    
   * the previous one.

  


  

    
    

    64
    
   */

  


  

    
    

    65
    
  public static boolean shouldRecompileThenReset(@NotNull Project project, @NotNull Set<String> targetAddresses) {

  


 




  
This will break if someone has compiled outside of intellij, such as on the CLI, right?

 




 
On November 17th, 2016, 1:11 a.m. UTC, Yi Cheng wrote:

 

  
That is not the case. Out of band file IO will be caught as long as they are under any of the project content roots.


If a source file changes and a compile is issued on CLI, next time when user switches back to IntelliJ GUI, the system will detect changes on disk since user switched out of IntelliJ, hence the project will be marked as dirty.


If a compile was issued on CLI without any source change, then manifest.jar which IJ consumes won't change either.


However another caveat I just realize is ./pants clean-all isn't detected, but I think it can be resolved by having clean-all to remove dist/export-classpath/manifest.jar which would be likely be invalid anyway, and then have IntelliJ check for its existence.

 











I added two additional checks.


    

  1. Have CompileSnapshot include the SHA of manifest.jar, so any change on manifest.jar will trigger a rebuild
    2. 

  2. Inspect the validity of manifest.jar, so after a clean-all, METAINF/MANIFEST.MF entries will become invalid, thus triggering a new build.
    3. 







 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    77
    
      projectStates.put(project, Pair.create(false, Optional.of(snapshot)));

  


 




  
Updating the project state here means that this method isn't idempotent. IMO, should update the project state independently after a compile has actually succeeded. I can easily imagine a state where a cancelled/failed compile is considered to be clean.


But also, it's not at all obvious from the javadoc that this will mutate the state.

 




 
On November 17th, 2016, 1:11 a.m. UTC, Yi Cheng wrote:

 

  
A failed/cancelled build will caught at the end of PantsMakeBeforeRun https://rbcommons.com/s/twitter/r/4363/diff/3#2 so the project will be marked dirty.


Will update the javadoc.

 











Doc updated to reflect the behavior.






 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/file/FileChangeTracker.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    103
    
    if (projectStates.containsKey(project)) {

  


  

    
    

    104
    
      projectStates.remove(project);

  


  

    
    

    105
    
    }

  


 




  
IIRC, remove works regardless of whether something is present... so no need to check first.

 









Redundant check removed.






 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/settings/PantsExecutionSettings.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    
    

    42
    
   * @param enableIncrementalImport: whether incrementally import the project.

  


 




  
whether to

 









Corrected.






 
On November 16th, 2016, 8:27 p.m. UTC, Stu Hood wrote:

 

  




 
  

   
    src/com/twitter/intellij/pants/settings/PantsSettings.java
    

     (Diff revision 3)

    
   
  

 



 
 

 

  

    23
    

    24
    

  


 




  
IMO, the project change detection should probably be optional for at least one release.

 









With the two additional checks added, I think it should be safe to land. Plus there is testing channel to use.








- Yi






On November 19th, 2016, 2:42 a.m. UTC, Yi Cheng wrote:













Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.


By Yi Cheng.




Updated Nov. 19, 2016, 2:42 a.m.










 Bugs: 


 217









 Repository: 
intellij-pants-plugin





Description 

 

 

  
   
Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.


This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 

  • After a clean-all it will always trigger a pants call.
    • 

  • After dist/export-classpath/manifest.jar getting overwritten because of other out of band pants CLI, pants will be triggered.
    • 

Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    • 



Other changes:
* Test against major pants releases, current dev releases, and master.
    

 
  • common/com/twitter/intellij/pants/util/PantsConstants.java (effc506894780d3f386e8f06997dad197f83a9d3)
    • 

 
  • src/com/twitter/intellij/pants/components/impl/PantsProjectComponentImpl.java (d272eb2ef5fbc9ddab1a87e9f2f9ad652dbbdb9a)
    • 

 
  • src/com/twitter/intellij/pants/execution/PantsMakeBeforeRun.java (0122a68beb986d53f849abbb74a30fd881fba818)
    • 

 
  • src/com/twitter/intellij/pants/file/FileChangeTracker.java (PRE-CREATION)
    • 

 
  • src/com/twitter/intellij/pants/service/project/modifier/PantsTargetNamesShortenerModifier.java (434cf5fe828a652c50b2304ac32687ba7cb8cbfd)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsExecutionSettings.java (be36768619b0886253c9cfd0b0a9a0bf98519df4)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsProjectSettings.java (14799ba27ea5ff5f271133c80ef518d9f20717f1)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsProjectSettingsControl.java (83571d71c8de210d46e868ce02112c5390a1c19b)
    • 

 
  • src/com/twitter/intellij/pants/settings/PantsSettings.java (c23e3fdbaa6d3d62ddccf2580dd32f64b2f2e803)
    • 

 
  • testFramework/com/twitter/intellij/pants/testFramework/PantsIntegrationTestCase.java (2b3aeacc1ff5d6e18401cffdc2482d12699192a2)
    • 

 
  • testFramework/com/twitter/intellij/pants/testFramework/runner/CustomProjectIntegrationTests.java (507dce3194e13de4e4ece33e3e5bada99b224158)
    • 

 
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedJavaReferenceQuickFixProviderTest.java (a1bcd1f6d821a15e2869ad5e8e933cbe5bc33c0b)
    • 

 
  • tests/com/twitter/intellij/pants/highlighting/PantsUnresolvedScalaReferenceQuickFixProviderTest.java (cc00bc4b9d81f283f24d652227a4dbd0f2cd09e1)
    • 

 
  • tests/com/twitter/intellij/pants/integration/NoopCompileTest.java (PRE-CREATION)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsExamplesMultiTargetsIntegrationTest.java (e56228dd8315911e2bea2ed03a50f6d04fb60684)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsFromScriptIntegrationTest.java (70cb0219f7f9334c26a766fb999f819ba4eddbba)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsJavaExamplesIntegrationTest.java (8e1b93a9e255f980811cb68e79406a8f0ab646bf)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsMakeIntegrationTest.java (8beb435eec489e309905e96cc4ca862e1ce27965)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsScalaExamplesIntegrationTest.java (bec2b23ac700c7edd95bf44d52854be16c402cc0)
    • 

 
  • tests/com/twitter/intellij/pants/integration/OSSPantsTestExamplesIntegrationTest.java (836b74c02ba37bd12c8e7cf7fb35f27d35074b24)
    • 






Yi Cheng
unread,
Nov 19, 2016, 7:22:10 PM11/19/16
to Peiyu Wang, Nick Howard (Twitter), Benjy Weinberger, Eric Ayers, Stu Hood, pants-reviews, Yi Cheng

   

    

     
      This is an automatically generated e-mail. To reply, visit:
      https://rbcommons.com/s/twitter/r/4363/
     
    

   

   









Review request for pants-reviews, Benjy Weinberger, Nick Howard (Twitter), Peiyu Wang, Stu Hood, and Eric Ayers.


By Yi Cheng.




Updated Nov. 20, 2016, 12:22 a.m.





Changes



 

  
   
merge with master

  		
 










 Bugs: 


 217









 Repository: 
intellij-pants-plugin





Description 

 

 

  
   
Earlier IntelliJ run configuration calls Pants every time before launching the test runner. This change leverages the intellij framework to detect whether a change on disk belongs to the project, so calling pants can be skipped when there is no changes between two test initiations.
This only applies to IntelliJ Junit/Scala Runner tests and not to Pants run configuration that directly calls ./pants test ...


Behavior:


    

  • Adding a file into/deleting a file from/editing a file in the project will trigger pants call.
    • 

  • Change of project settings will trigger pants call.
    • 

  • Using incremental imports will always trigger pants call because we can no longer determine whether a change belongs to the project or not.
    • 

  • After a clean-all it will always trigger a pants call.
    • 

  • After dist/export-classpath/manifest.jar getting overwritten because of other out of band pants CLI, pants will be triggered.
    • 



Minor issue:


    

  • Change in pants.ini is not tracked, but should be a very rare case. (Added in FIXME)
    • 



Other changes:
* Test against major pants releases, current dev releases, and master.
Reply all
Reply to author
Forward
0 new messages