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

Include jvm.test.junit.options in IntelliJ test config #439

Closed
wants to merge 9 commits into from
Closed

Include jvm.test.junit.options in IntelliJ test config #439

wants to merge 9 commits into from

Conversation

tpasternak
Copy link
Contributor

closes #435

vm_options_demo

Copy link
Collaborator

@wisechengyi wisechengyi left a comment

Choose a reason for hiding this comment

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

Thanks, Tomasz!

@@ -104,6 +105,11 @@ else if (testPackage != null) {
}

taskSettings.setScriptParameters(StringUtil.join(scriptParameters, " "));
Optional<String[]> vmOptions =
PantsOptions.getPantsOptions(module.getProject()).flatMap(options -> options.getList("jvm.test.junit.options"));

Copy link
Collaborator

Choose a reason for hiding this comment

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

@@ -43,6 +44,12 @@ public boolean has(String optionName) {
return Optional.ofNullable(options.get(optionName));
}

public Optional<String[]> getList(String optionName) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you kindly add some unit tests for this function?

Copy link
Collaborator

@wisechengyi wisechengyi left a comment

Choose a reason for hiding this comment

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

Oh sorry. The pants runner does not need this change actually because Pants is already picking up those options via the ini files.

This is should be used for IntelliJ junit/scalatest and such, which is happens at

BeforeRunTask pantsMakeTask = new ExternalSystemBeforeRunTask(ID, PantsConstants.SYSTEM_ID);
pantsMakeTask.setEnabled(true);
runManagerImpl.setBeforeRunTasks(runConfiguration, Collections.singletonList(pantsMakeTask), false);

Basically for any config that we have to replace Build with PantsCompile.

Edit: url changed.

@wisechengyi
Copy link
Collaborator

wisechengyi commented Nov 25, 2019 via email

@tpasternak
Copy link
Contributor Author

Yes, it's clear, I just noticed your note right after I submitted the commits. I have some problems w with classpath now, because the Pants plugin needs access to JUnit plugin's classes. Hopefully will be done tomorrow.

@tpasternak
Copy link
Contributor Author

Ok, now the VM params are applied to JUnit confiuration

vm_options_junit

Copy link
Collaborator

@wisechengyi wisechengyi left a comment

Choose a reason for hiding this comment

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

Thanks, Tomasz! Looks mostly good with some minor points.

Comment on lines 115 to 122

if(runConfiguration instanceof JUnitConfiguration) {
Optional<String[]> os = PantsOptions.getPantsOptions(project)
.flatMap(options -> options.getList(PantsConstants.PANTS_OPTION_TEST_JUNIT_OPTIONS));
String optionsString = String.join(" ", os.orElse(new String[]{}));
((JUnitConfiguration)runConfiguration).setVMParameters(optionsString);
}

Copy link
Collaborator

Choose a reason for hiding this comment

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

This logic is needed for if (PantsUtil.isScalaRelatedTestRunConfiguration(runConfiguration)) as well. So possibly we can extract this to a helper function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 109 to 110


Copy link
Collaborator

Choose a reason for hiding this comment

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

xx

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

private ConfigurationFromContext getPantsJunitConfigurationFromContext(ConfigurationContext context) {
return getConfigurationFromContext(context, PantsJUnitTestRunConfigurationProducer.class);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

no longer used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Both getJunitConfigurationFromContext and getPantsJunitConfigurationFromContext are used. I Introduced getJunitConfigurationFromContext in order to test new behavior.

Comment on lines 117 to 118
Optional<String[]> os = PantsOptions.getPantsOptions(project)
.flatMap(options -> options.getList(PantsConstants.PANTS_OPTION_TEST_JUNIT_OPTIONS));
Copy link
Collaborator

Choose a reason for hiding this comment

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

This introduces a minor lag in the UI if PantsOptions wasn't cached. We could either the following options:

  1. Show the UI Getting Pants options ...
  2. Preemptively populate pants options up on project start.

Copy link
Contributor Author

@tpasternak tpasternak Nov 27, 2019

Choose a reason for hiding this comment

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

Thanks, I haven't try it on big projects, so I didn't observe this issue. I chose option one. If the caching mechanism is already implemented, then let's let it do its job.

lag

Copy link
Collaborator

Choose a reason for hiding this comment

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

Looks great. Thanks!

@@ -20,6 +20,7 @@
<!--Add gradle as a dep because of Pants runner requires it.-->
<depends>com.intellij.gradle</depends>

<depends optional="true" config-file="pants-junit.xml">JUnit</depends>
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be required. so optional=false or not specifying it at all.

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 chose conditional dependency, because otherwise it was failing when you were using 2019.2 for development.

Now it's unconditional.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks! The plugin upgrade is normally backwards incompatible, so not-optional should be fine.

@tpasternak
Copy link
Contributor Author

tpasternak commented Nov 27, 2019

I broke the tests by accident while I was refactoring the code. Now it should be fine

@wisechengyi
Copy link
Collaborator

That means tests are working as intended :)

@tpasternak
Copy link
Contributor Author

Now it's only "Too many projects leaked:" test that fails

@wisechengyi
Copy link
Collaborator

Thanks! This looks good. Unfortunately I found a blocking issue that internally we use certain security manager settings in jvm.test.junit.options, which intellij doesn't know about and will throw an error, so we can't land this just yet.

I will give it a bit more thought how we can proceed there.

@tpasternak
Copy link
Contributor Author

@wisechengyi can we close it?

@olafurpg
Copy link
Contributor

ping @wisechengyi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

include jvm.test.junit.options into test configurations VM options
3 participants