Nested target file location error with "file:" protocol

[Phillipus]

Eclipse 4.24
OpenJDK 64-Bit Server VM Temurin-11.0.15+10 (build 11.0.15+10, mixed mode)

I have two target files in a project com.archimatetool.editor.product. One is the main target and one is nested:

archi.target:

<target name="Archi">
<locations>
    <location type="Target" uri="file:${project_loc:/com.archimatetool.editor.product}/archi2.target"/>

    <location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
        <repository location="https://download.eclipse.org/eclipse/updates/4.23"/>
        <unit id="org.eclipse.sdk.ide" version="4.23.0.I20220308-0310"/>
    </location>
</locations>
</target>

The nested target is:

<target name="Archi Nested">
<locations>
    <location includeAllPlatforms="true" includeConfigurePhase="true" includeMode="slicer" includeSource="true" type="InstallableUnit">
        <repository location="https://download.eclipse.org/eclipse/updates/4.23"/>
        <unit id="org.eclipse.sdk.ide" version="4.23.0.I20220308-0310"/>
    </location>
</locations>
</target>

However, when I attempt to launch the RCP app from Eclipse via its product file it fails to launch and error is written to log:

java.lang.IllegalStateException: Install location is invalid: file:file:D:\projekts\archi\archi\com.archimatetool.editor.product/archi2.target
	at org.eclipse.equinox.launcher.Main.getInstallLocation(Main.java:1977)
	at org.eclipse.equinox.launcher.Main.processConfiguration(Main.java:1886)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1440)

If I remove the file: protocol from the line file:${project_loc:/com.archimatetool.editor.product}/archi2.target so it is ${project_loc:/com.archimatetool.editor.product}/archi2.target it launches but now there is an "unknown protocol" error when editing the location of the nested target file.

[Phillipus]

It has something to do with the order of the locations in the first target file. This one works:

<target name="Archi">
<locations>
    <location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
        <repository location="https://download.eclipse.org/eclipse/updates/4.23"/>
        <unit id="org.eclipse.sdk.ide" version="4.23.0.I20220308-0310"/>
    </location>

    <location type="Target" uri="file:${project_loc:/com.archimatetool.editor.product}/archi2.target"/>
</locations>
</target>

[merks]

This looks exactly like this issue:

#178

[Phillipus]

This looks exactly like this issue:

#178

@merks As per my comment above, maybe the order of the location in that issue could affect it?

[merks]

Yes, I believe the analysis was that the first target location's location is used by this:

eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/core/plugin/TargetPlatform.java

Lines 66 to 84 in 642462b

	public static String getLocation() {
	try {
	ITargetDefinition target = TargetPlatformService.getDefault().getWorkspaceTargetDefinition();
	ITargetLocation[] containers = target.getTargetLocations();
	// the first container is assumed to be the primary/home location
	String path = null;
	if (containers != null && containers.length > 0) {
	path = containers[0].getLocation(true);
	if (path != null) {
	IStringVariableManager manager = VariablesPlugin.getDefault().getStringVariableManager();
	path = manager.performStringSubstitution(path);
	return path;
	}
	}
	} catch (CoreException e) {
	PDECore.log(e);
	}
	return getDefaultLocation();
	}

So yes, the order maters and it's only a problem if the target reference target location is first.

[Phillipus]

So yes, the order maters and it's only a problem if the target reference target location is first.

OK, so maybe I should close this issue?

Is this the cause of #178, or is that something else?

[merks]

Here I asked if he was using a reference target location and he answered that he was:

#178 (comment)

Though I'm doubtful that file:file: was ever tolerated. I know all the other bad forms have been tolerated...

So yes, I'm sure this is a duplicate problem. FYI @vik-chand

[Phillipus]

OK, I've read through #178 properly now and I understand that a change in File.toURL in JDK 11.0.15 throws an exception. If that were not the case (or using an earlier JDK 11 version) presumably the order of target locations would not matter?

[merks]

As I keep mentioning, I don't think file:file: does, will, or ever has worked. Also, this referenced target location is quite new and only with that do we end up with file:file:. But I'm not sure what conclusion you wish to draw here? That this problem is different than other problem?

[Phillipus]

I think I'm mixing things up. :-)

For this issue, the JDK version is not relevant, as I just tested it. What is relevant is that the order of target locations is correct as you mention in #230 (comment)

Now that I have the local file target location second, the product launches, even with the file: prefix.