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

systemPropertyVariables ignored #174

Open
jeacott1 opened this issue Apr 20, 2021 · 12 comments
Open

systemPropertyVariables ignored #174

jeacott1 opened this issue Apr 20, 2021 · 12 comments

Comments

@jeacott1
Copy link

it looks like this is an ancient issue and despite it claiming here it was transferred, I couldn't find any ref to it here.
ref https://bugs.eclipse.org/bugs/show_bug.cgi?id=388683

the maven failsafe/surefire <systemPropertyVariables> properties are ignored.

@HannesWell
Copy link
Contributor

HannesWell commented Jun 30, 2021

The last comment on that issue unfortunately tends to be misleading. It was intend as general statement that m2e issues are moved to github.

However, as stated in comment 1 of the linked bug, executing a Test via Run As -> JUnit Test is not connected to the Maven configuration at all and therefore does not consider Maven configurations at the moment (and I don't know about plans to implement that).

As a workaround you can add the desired system-properties to the JUnit launch-configuration in the Arguments tab. To store and share that launch configuration, I suggest to save it as a shared file (Common tab) in a project and check it into your version-control-system.

@garretwilson
Copy link

I would like to revisit this issue.

On SLF4J-592 we're discussing the best approach for specifying a logging provider to be used only in Maven tests without interfering with the main application logging provider (if any). The idea is to configure a logging provider for tests in a parent POM with test scope, but have it take precedence in descendant POM tests even if the main project has the production logging provider on the classpath.

The simplest and elegant solution we're converging on so far is to simply have a system property e.g. slf4j.provider to indicate the logging provider to use in the case that several appear on the classpath.

Whether this works depends on whether it is possible to specify a system property for Maven tests. Both the Maven Surefire Plugin and the Maven Failsafe Plugin provide a <systemPropertyVariables>, with a description, "List of System properties to pass to a provider". The Surefire Using System Properties documentation have some examples.

I've tested this in Maven 3.9.1 with Surefire.

  • I specified a system property e.g. foo in <systemPropertyVariables> in a parent POM.
  • I retrieved the system property in the unit test of an inheriting descendant POM, and the value was what I had set. I assume it will work in Failsafe as well for integration tests.

Unfortunately when I manually run a JUnit test in the Eclipse IDE, the unit test does not see the system property foo that has been configured for Surefire in the parent POM. And running the test in Eclipse was one of the main issues we were trying to solve for SLF4J. Manually adding a system property in Eclipse for each new testing configuration is not a viable solution.

@HannesWell you indicated that running unit tests in the Eclipse IDE is "not connected to the Maven configuration at all". But m2e examines the POM(s) when updating the projects (automatically and with Alt+F5). Would it not be possible to discover Surefire/Failsafe <systemPropertyVariables> and use them to configure values to be provided to the Eclipse IDE testing subsystem somehow?

If there are no plans to recognize <systemPropertyVariables> in Eclipse, it looks like we'll have to go back to the drawing board for SLF4J in relation to SLF4J-592.

@garretwilson
Copy link

It would appear this is supported in IntelliJ; see IDEA-101185. (See comments and pull requests on that ticket.)

@laeubi
Copy link
Member

laeubi commented Jun 22, 2023

@garretwilson I don't think this is possible as m2e does not can configure eclipse junit runs triggered by the UI, but you can run the test once and then edit the resulting runconfiguration and add any java option you like.

As an alternative, you need to ask JDT project for a way to have a project configurable "test properties" that are considered and can be set by m2e beforehands.

it looks like we'll have to go back to the drawing board for SLF4J in relation to SLF4J-592.

Without knowing the details, I would have choose a quite different approach:

  1. search the classpath for a /slf4j.properties file
  2. inside that file allow among maybe other (e.g. I can think about configuring the simple provider there) things a property slf4j.provider=my.favorite.one
  3. add a src/test/resources/slf4j.properties file to the project to configure the desired test-provider and add the additional one with <scope>test</scope>

@garretwilson
Copy link

Without knowing the details, I would have choose a quite different approach:

I'd like to not get off topic on this ticket. We welcome your input on the SLF4J-592 for alternate ideas to address that use case. As to your suggestion, the idea here was to configure this in a parent POM, and without going into its qualities in general, your slf4j.properties file suggestion would not work in this case as I cannot configure inherited resource files in a parent POM.

@laeubi
Copy link
Member

laeubi commented Jun 22, 2023

Well you can have a module slf4j-config and add this as a dependency in your parent pom in scope test then it will be inherited by all childs, that would work as of today and sounds quite tool and plugin independent approach.

If you insist of the system properties, as said m2e needs support from JDT here as we are not in charge of the test-run in any way.

@garretwilson
Copy link

As an alternative, you need to ask JDT project for a way to have a project configurable "test properties" that are considered and can be set by m2e beforehands.

Done; see eclipse-jdt/eclipse.jdt.debug#548 .

@garretwilson
Copy link

Well you can have a module slf4j-config and add this as a dependency in your parent pom.

OK, but what specifically would this slf4j-config do? What would it publish that would be available when running unit tests inside the Eclipse IDE?

@laeubi
Copy link
Member

laeubi commented Jun 22, 2023

OK, but what specifically would this slf4j-config do? What would it publish that would be available when running unit tests inside the Eclipse IDE?

It would contain the /slf4j.properties file, because it is a dependency it will be added to the classpath of the child project and therefore be visible to the executing tests.

@garretwilson
Copy link

@laeubi thank you for the additional suggestions for configuring SLF4J. In order to focus on this ticket related to Eclipse test use of Surefire/Failsafe system properties, it's probably best if further discussion of those alternatives are done on SLF4J-592.

@garretwilson
Copy link

As an alternative, you need to ask JDT project for a way to have a project configurable "test properties" that are considered and can be set by m2e beforehands.

I'm curious—what facility does m2e currently use to inform the Eclipse in-IDE testing platform of the test classpath specified by Maven for a project? (I'm guessing a facility for specifying system properties, which I've requested in eclipse-jdt/eclipse.jdt.debug#548 , would be analogous.)

@laeubi
Copy link
Member

laeubi commented Jun 23, 2023

it's probably best if further discussion of those alternatives are done on SLF4J-592

Feel free to copy a link and/or mentioned alternatives there but I don't have a JIRA account yet to participate directly.

I'm curious—what facility does m2e currently use to inform the Eclipse in-IDE testing platform of the test classpath specified by Maven for a project?

JDT has an extension point where extenders can supply a classpath container, if you import a maven project you will see an additional "Maven Dependencies" in the project and can expand it to see the items contributed to Eclipse JDT, an item can additionally be flagged as being "test". This is the used by the compiler, by test runs, and probably others neither m2e nor jdt knows about so it is not dedicated to a single usage.

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

4 participants