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

means for m2e to set system properties for some tests #548

Open
garretwilson opened this issue Jun 22, 2023 · 4 comments
Open

means for m2e to set system properties for some tests #548

garretwilson opened this issue Jun 22, 2023 · 4 comments

Comments

@garretwilson
Copy link

There needs to be a means for m2e to advise the Eclipse IDE testing subsystem of system properties to make available to unit tests when run within the IDE.

Both the Maven Surefire Plugin and the Maven Failsafe Plugin provide a <systemPropertyVariables> as way to configure system properties that will be accessible for unit test and integration tests, respectively. See Using System Properties for an example.

IntelliJ apparently (see IDEA-101185) supports <systemPropertyVariables> in in-IDE tests.

Unfortunately Eclipse IDE ignore any <systemPropertyVariables> properties set in the Maven POM in these plugin configurations. In the discussion in eclipse-m2e/m2e-core#174, I was told that m2e, when in processes a Maven POM, has no way to advise Eclipse of the system properties to be used for in-IDE testing. I was asked to file a ticket here to request this capability. Otherwise, our <systemPropertyVariables> properties are ignored in unit/integration tests and according to m2e, they have no way around this.

@iloveeclipse
Copy link
Member

m2e can provide own launch configuration type (like "Run as Maven Test" or something in that direction) and configure there everything based on pom files. Platform itself doesn't know anything about maven.

@garretwilson
Copy link
Author

Platform itself doesn't know anything about maven.

Maybe I didn't explain well what is being requested.

I know the Eclipse platform knows nothing about Maven. I am not requesting that the Eclipse platform know anything about Maven. I am requesting that the Eclipse platform provide some means for some other subsystem to pass it system property values to make available when running tests.

Looking at the Eclipse IDE as a whole, when I open Eclipse and run a test normally (without going to some special "Run as Maven Test" menu), I expect the classpath to be correctly configured based upon my Maven POM. Does this mean the Eclipse platform knows something about Maven so that it directly retrieves the classpath from the POM? I imagine not; instead, the platform undoubtedly provides some way to configure the classpath, and m2e determines the classpath from Maven and informs the platform of this. (I'm guessing about how it works, but it's not an unreasonable assumption.)

Similarly when I looking at the Eclipse IDE as a whole, when I open Eclipse and run a test normally (without going to some special "Run as Maven Test" menu), I expect the system properties that I configured in my Maven POM to be available to the unit/integration tests. (Apparently this works in IntelliJ.) Does this mean I am asking the platform to have knowledge of Maven? No, it means I am requesting that the platform provide a means for specifying per-project system properties for tests (just as it provides a means for specifying the project classpath) so that another module (in this case m2e) can configure those properties accordingly.

m2e tells me they cannot do this because the plaform does not provide them this means. They requested that I file this ticket requesting the platform add that facility.

@HannesWell
Copy link
Contributor

m2e can provide own launch configuration type (like "Run as Maven Test" or something in that direction) and configure there everything based on pom files. Platform itself doesn't know anything about maven.

That would be possible, but I tend to have sympathy for the suggestion.
In the CI test code in Maven projects will only run with the environment set up by the Maven-pom and is therefore supposed pass with that. And in contrast to for examples PDE's JUnit Plug-in Tests the modifications done by a Maven configuration likely won't have that big impact on the test execution time.
Not needing to think about which kind of Junit Testing/Launch-Config type to choose respectively not needing to tell it your colleagues would make Eclipse in general more convenient to use. Ideally it should be as simple as 'Just execute the tests'.
Adding another JUnit Launch type would just another piece to the Eclipse puzzle.

That being said, it could be implemented without any need to tell platform/JDT anything about Maven by providing some kind of hook that can modify the LaunchConfigurationWorkingCopy being created when launching the JUnit tests from the Context menu. The hook could be contributed via an Extension-Point or as an OSGi (Declarative) Service.

It is already possible to be notified about launches being created by registering a ILaunchConfigurationListener in the ILaunchManager of the Platform, but when notified about a new config the listener only get the immutable LaunchConfig and not a working-copy. But for this there is no need to intercept Launch creation in general, we just need that for JUnit launches.
Maybe the possible ways to influence the created launch config could be limited, for example to only providing extra Program or VM-arguements.
If I read @garretwilson's case in m2e correctly that would at least be sufficient for that case. And since m2e can already influence the jars in the test-runtime atm. Additionally m2e could for example pick a suitable JRE to run the tests, based on the surefire config.

@HannesWell
Copy link
Contributor

Another use case for this would be in PDE.
In order to be able to run tests in a Plugin-Project as plain JUnit Test (without OSGi) PDE adds the Junit-5 launcher jars to the classpath if only the junit-jupiter-api bundle is in the Plugins dependency closure. And although there are non-accassible rules applied to those jars, in some scenarios the jar content seems to be available nevertheless.
A cleaner/less hacky approach would be if PDE could just supply the launcher jars from the Target-Platform when a JUnit Test is launched. Using PDE's own JUnit Plugin Test launch type is in that case not desired because that would launch an OSGi runtime as well.

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

No branches or pull requests

3 participants