Community
Participate
Working Groups
To accomodate the diversity of JUnit/JUnitPlugin Interactive/Tycho testing my tests suffix their names with <standalone> / <plugin> / <maven> / <tycho>. This is ok wrt running / viewing tests but no longer allows a particular failing test to be rerun. With the attached project, Run the NameBugPlugin.launch. - test passes and is named "MyTest <plugin>" Select "MyTest <plugin>" and Run - dialog pops up < is an invalid character in resource name 'Rerun NameBug.MyTest <plugin>.launch'. Since this used to work, I presume the encoding of awkward characters has been removed.
Created attachment 281833 [details] Repro project Maybe the attachment will attach this time.
Since which Eclipse version do you see it broken?
I think it is new in 2019-12, but can't be sure since mostly I relaunch Junit rather than JUnitPlugin tests. Going back to 2019-03, it works (once I disable MalformedURLExceptions that occur for the "." on the bad start path).
I don't have a 4.13 (2018-09) to hand but using 4.13RC1, the re-Run of "testOkAssignPrecedences <plugin>" from the "org.eclipse.ocl.examples.xtext.tests (plugin)" launch JUnit View works. So 4.11 ok, 4.13RC1 ok, 4.14 bad encoding.
@Andrey, Looks impact of some platform change ? Are you aware of any change?
(In reply to Sarika Sinha from comment #5) > @Andrey, > Looks impact of some platform change ? Are you aware of any change? Not immediately (of course we've updated JUnit may be). But my problem is that I can't reproduce this bug on RHEL 7.4 / Java 8 + Java 11. I run the "selected" test both as "JUNit test", and "JUnit Plug-in test" without issues. Ed, do you see some errors reported in the error log? Can you attach it?
There is tons in the error log but nothing that seems related. To me the problem is very simple. Once "testOkAssignPrecedences <plugin>" is naively turned into a Windows file name for an internal launch file, it is illegal and that causes the failure. The regression is whether the internal launch file is new, or whether the internal file was never exposed to Windows, or whether it was actually 'encoded'. Since IIRC my choice of <> as delimiters was driven by [] being mis-understood as parameters and () as bad Windows characters, it may just be that JUnit5 introduces a change in the <> treatment.
It works on Mac as well. Will try on Windows 10 to see if I can reproduce.
It works on Windows with 4.12 and 4.13 but I was able to reproduce on the latest build. So looks like a regression from 4.14.
From org.eclipse.core.internal.resources.OS : if (INSTALLED_PLATFORM.equals(Platform.OS_WIN32)) { //valid names and characters taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp INVALID_RESOURCE_CHARACTERS = new char[] {'\\', '/', ':', '*', '?', '"', '<', '>', '|'}; I did not investigate as to how it was working before, may be some bug but I think "<" is not a valid resource character and hence org.eclipse.core.internal.resources.LocationValidator.validateName(String, int) throws this error. I don't think this can be fixed, if anyone else has any suggestion please reopen the bug with details.
It did work before so it is a regression. There is no Microsoft specification on the spelling of JUnit test names. The problem lies in one of - The naive assumption that the test name can be used unchecked as a Microsoft file name. - The naive assumption that a test name can be saved in a file such as a *.launch without checking. This is a very well known problem. Whenever any arbitrary text is stored in XML it must be encoded using e.g. < to satisfy the XML specification. Here too when the test name is used in a restrictive context, it must be adequately encoded. Presumably it worked before because - a longstanding encoding failure is only now detected - a new encoding opportunity has been introduced and overlooked
It is actually no encoding change which has caused this. It is caused by a change in Bug 231099. org.eclipse.pde.internal.launching.launcher.BundleLauncherHelper.migrateLaunchConfiguration(ILaunchConfiguration) is now saving the Launching working copy if it was dirty instead of the previous check : if (save && (value != null || value2 != null || upgrade)) Moving to PDE UI .
Julian, can you please have a look?
The issue is that PDE saves a launch configuration that was meant to be temporary. Apart from the invalid character issue, this also pollutes the workspace with temporary launch configs. That could have happened before, when a migration was necessary, but is now triggered every time making this issue more apparent. I don't see a safe quickfix here for RC2. We need to remove the saving completely during launch and always migrate on-the-fly. Only in the launch config dialog can the migrated config be saved.
(In reply to Julian Honnen from comment #14) > The issue is that PDE saves a launch configuration that was meant to be > temporary. Apart from the invalid character issue, this also pollutes the > workspace with temporary launch configs. > > That could have happened before, when a migration was necessary, but is now > triggered every time making this issue more apparent. > > > I don't see a safe quickfix here for RC2. We need to remove the saving > completely during launch and always migrate on-the-fly. Only in the launch > config dialog can the migrated config be saved. Thanks Julian, for your investigation and quick assessment for this bug.
New Gerrit change created: https://git.eclipse.org/r/159776
New Gerrit change created: https://git.eclipse.org/r/159775
Gerrit change https://git.eclipse.org/r/159776 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=b813b9cd94363e31641f576905a5bc7b3283b839
Gerrit change https://git.eclipse.org/r/159775 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=f15e72f99c0bc1fbc3375da189030c66f54c708a
(In reply to Julian Honnen from comment #14) > The issue is that PDE saves a launch configuration that was meant to be > temporary. Apart from the invalid character issue, this also pollutes the > workspace with temporary launch configs. > > That could have happened before, when a migration was necessary, but is now > triggered every time making this issue more apparent. The "now" is caused by which change? I see a crazy error in 4.15 where previously saved launch configs with tracing enabled are automatically re-written on first time opening the launch config dialog, and all the tracing data is gone.
(In reply to Andrey Loskutov from comment #20) > The "now" is caused by which change? bug 231099, specifically https://git.eclipse.org/r/c/151702/6/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/BundleLauncherHelper.java#590 > I see a crazy error in 4.15 where previously saved launch configs with > tracing enabled are automatically re-written on first time opening the > launch config dialog, and all the tracing data is gone. I think that's a different issue. Opening the launch config dialog does (and did before) also trigger a save when dirty. The bigger question is, why the tracing data is lost, not why the config is saved, I think.
(In reply to Julian Honnen from comment #21) > (In reply to Andrey Loskutov from comment #20) > > The "now" is caused by which change? > bug 231099, specifically > https://git.eclipse.org/r/c/151702/6/ui/org.eclipse.pde.launching/src/org/ > eclipse/pde/internal/launching/launcher/BundleLauncherHelper.java#590 > > > I see a crazy error in 4.15 where previously saved launch configs with > > tracing enabled are automatically re-written on first time opening the > > launch config dialog, and all the tracing data is gone. > I think that's a different issue. Opening the launch config dialog does (and > did before) also trigger a save when dirty. The bigger question is, why the > tracing data is lost, not why the config is saved, I think. I've created bug 561424.
Julian, can you please verify this fix?
verified with project from comment 1 on Version: 2020-06 (4.16) Build id: I20200407-1800
