Comment 1 Oliver Goetz 2016-02-12 05:02:17 EST

I am not able to reproduce it using:

Eclipse for Testers
Version: Mars.2 Release (4.5.2RC3)
Build id: 20160210-2154
Windows 8.1

Comment 2 Andreas Sewe 2016-02-12 05:06:35 EST

(In reply to Oliver Goetz from comment #1)
> I am not able to reproduce it using:
> 
> Eclipse for Testers
> Version: Mars.2 Release (4.5.2RC3)
> Build id: 20160210-2154
> Windows 8.1

Thanks, Oliver.

I suspect this is an OS X issue.

What does "find . -name introData.xml" (or the Windows equivalent) return for you?

On OS X it's

  ./Eclipse.app/Contents/Eclipse/plugins/org.eclipse.platform_4.5.2.v20160203-1000/introData.xml

which is not where the code is looking:

  ./Eclipse.app/Contents/MacOS/introData.xml

Comment 3 Markus Knauer 2016-02-12 05:18:43 EST

I can reproduce it on Linux... and after digging a bit into it, I would say that this is a old error that affects nearly all packages.

The root cause is that there is a reference in the product's plugin_customization.ini file to a introData.xml file that isn't available in most packages. I'm going to copy a standard file to the packages where it is missing - should be fixable for RC4 next week.

Comment 4 Markus Knauer 2016-02-17 11:35:35 EST

After looking into this issue it seems a bit more work than just adding the same file to the packages... and as far as I can see the problem itself is not harmful, and moreover, it has been like that all the time...

The location of the file is defined as

  org.eclipse.ui.intro.universal/INTRO_DATA = product:introData.xml

and with that it is supposed to be located in the branding plug-in directory of the product. Unfortunately not all of the packages include this file, in fact, most of them never did, so I don't think we can call this a regression.

The problem that I see in Mars.2 RC4 week is that every package needs to define and to assemble its own introData.xml file based on its content, and that it is really late for doing, coordinating, and testing such a change. And if it is not a file specific to the package, it doesn't really help. I would like to move this to the list of issues that needs to be fixed for Neon.

Comment 5 Andreas Sewe 2016-02-17 11:38:26 EST

(In reply to Markus Knauer from comment #4)
> I
> would like to move this to the list of issues that needs to be fixed for
> Neon.

Fair enough. As I said, it didn't notice any buggy behavior (aside from the error messages), so this is not a big issue from the users' perspective.

Comment 6 Laurent Goubet 2016-03-18 06:16:29 EDT

*** Bug 479791 has been marked as a duplicate of this bug. ***

Comment 7 Andreas Sewe 2016-05-06 08:27:46 EDT

(In reply to Markus Knauer from comment #4)
> I
> would like to move this to the list of issues that needs to be fixed for
> Neon.

Markus, since Ed Merks just posted about this (and other issues) on cross-project-issues, I think we should revisit this.

As you did the initial analysis, can you maybe prepare a fix for one of the EPP packages and then the other packages' maintainers could use that as inspiration to do the fix for their package (as comment 4 suggests that the fix is package-specific)? I certainly would be willing to do the (follow-up) work for the Java package.

Comment 8 Ed Merks 2016-05-06 10:47:41 EDT

We should also keep in mind that if this file should exist, then the p2 director (and hence Oomph) should create it, otherwise the installer will create installations with this error.

Comment 9 Patrik Suzzi 2016-05-06 10:49:16 EDT

*** Bug 493117 has been marked as a duplicate of this bug. ***

Comment 10 Patrik Suzzi 2016-05-06 11:06:40 EDT

Created attachment 261516 [details]
stack  trace of the reproduced bug.

Reproducible in Neon Milestone 7 (4.6.0M7)
Build id: 20160505-1310

Steps to reproduce: 
1. download eclipse for DSL from the link at [#1]
2. launch eclipse, show the "Error Log" View

Possible cause: new File(introData.xml) without a relative path defined would start the search from the base location of the Java executable. 

[#1] - https://www.eclipse.org/downloads/index-developer.php

Comment 11 Ed Merks 2016-05-07 05:06:25 EDT

It seems pretty clear to me that this is a regression introduced by the changes for https://bugs.eclipse.org/bugs/show_bug.cgi?id=491556.

In particular, this method:

	private void loadData() {
		// load the active product's intro data first
		IProduct product = Platform.getProduct();
		if (product != null) {
			String dataFile = getVariable(VAR_INTRO_DATA);
			if (dataFile != null) {
				primaryIntroData = new IntroData(product.getId(), dataFile, true);
			}
		}

is guarded to check if dataFile != null) but the variable lookup/resolution mechanism ends up in 

	private String resolveFile(Bundle bundle, String path) {
		String prefixedPath = getThemePrefixedPath(path);
		try {
			URL url = null;
			if (prefixedPath != null) {
				url = bundle.getEntry(prefixedPath);
			}
			if (url == null) {
				url = bundle.getEntry(path);
			}
			if (url != null) {
				URL localURL = FileLocator.toFileURL(url);
				return localURL.toString();
			}
		} catch (IOException e) {
		}
		// just use the value as-is
		return path;
	}

which never returns null.  I believe this method should return null if the file/entry does not exist in the product bundle.

It's hard for me to test such a change, but stepping through a remote debug session I can see that this is exactly where this bogus relative path comes from.  

The previous revision has this method to resolve a variable. 

	private String resolveVariable(Bundle bundle, String value) {
		if (value != null) {
			String path = null;
			if (value.startsWith("intro:")) { //$NON-NLS-1$
				bundle = UniversalIntroPlugin.getDefault().getBundle();
				path = value.substring(6);
			} else if (value.startsWith("product:")) { //$NON-NLS-1$
				path = value.substring(8);
			} else
				return value;
			try {
				URL url = bundle.getEntry(path);
				if (url != null) {
					URL localURL = FileLocator.toFileURL(url);
					return localURL.toString();
				}
			} catch (IOException e) {
				// just use the value as-is
				return value;
			}
		}
		return null;
	}

Here we can see that if the bundle doesn't have an entry for the value, the final return null is reached.

I'm not sure how the problem was reproducible in Mars, except perhaps if the file locator threw an exception; I don't think that case should return null as well.

Comment 12 Brian de Alwis 2016-05-07 22:50:09 EDT

(In reply to Ed Merks from comment #11)
> It seems pretty clear to me that this is a regression introduced by the
> changes for https://bugs.eclipse.org/bugs/show_bug.cgi?id=491556.
[…]
> which never returns null.  I believe this method should return null if the
> file/entry does not exist in the product bundle.

You're right.  I'll put the fix against bug 491556 as the bug is not actually the cause of the problem described in the particular bug.

Comment 13 Alexander Kurtakov 2020-06-03 07:27:02 EDT

Still here on 2020-06