Ensure the XMLLanguageServer process inherits user.name and user.home

[merks]

No description provided.

[merks]

For testing, I frequently provision installations to specify a explicit user.home:

-Duser.home=D:\Users\test35

This is also very useful environments where developers wish to provision multiple installations with completely independent content, including separate global preferences and even separate global maven caches.

In an IDE with the above system property, the m2e preferences default to values based on that user.home value:

But I noticed in the editor, that the hover links for nagivating to a parent pom were "leaking" information that could only come from my real user.home which is D:\Users\merks where it was reading the .m2\settings.xml which is a different from the one in the preferences. Perhaps that's an m2e bug that should be fixed too, but in general, it makes sense that the launched Java process inherits the user.home of the running Java process. Also the user.name makes sense, and perhaps even the java.io.tmpdir. It already inherits the user.dir.

[mickaelistria]

Can you please also bump the version of the feature as suggested by CI build?
(note that Wild Web Developer currently doesn't use the same versioning pattern for features than Platform, so they do need version bumps. If you're interested in fixing it by the way so it behaves like Platform, that would be welcome)

[merks]

Yes, I noticed the first failure was the bundle needed incrementing and the next one was the feature needed incrementing. Fortunately I have some experience reading the tea leaves to recognized the errors.

[laeubi]

Wouldn't it be better if the process would simply inherit all system properties?

[merks]

I doubt that’s a good idea. It has the potential to have unintended consequences. I don’t think we just want to just transfer all the properties documented here

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#getProperties()

let alone all properties with unknown meaning.

[laeubi]

Changing user.home is already "undefined behavior" according to the docs

Changing a standard system property may have unpredictable results unless otherwise specified.

but maybe its fine to just export those if required (like here) as a first step.

[merks]

Thanks @mickaelistria

note the I interpret the documentation’s API note to mean changing the value via the setProperty API and because of course any of the values might be used before one can change it via System.setProperty but via the command line a property will start with the value of the command line

anyway it does work well and is really important when testing anything that relies on and pollutes the user home folder