Custom Java-Editor clone for Plugin

[M-Marvin]

I am currently working on an plugin for my own custom build system, which utilizes java files as the build script.
The problem is that if I open them in the IDE, all the classes referenced by the file are invalid since they are not on the classpath.
My first idea was to make a custom editor for those files, which basically is a copy/extension of the JDT JavaSource Editor but with its own classpath which would be set to the build systems files.

But I cant find any clear documentation about how the JDT plugin is structured and how it might be possible to make these modifications to the editor.
So far I came up with this:

import org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor;

@SuppressWarnings("restriction")
public class BuildscriptEditor extends CompilationUnitEditor {
	
}

Which creates an editor that is able to highlight the keywords in the code, but autocomplete or suggestions don't work.

Maybe there is even a better way to do this.
Especially since the CompilationUnitEditor seems to be an internal class, not intended to be extended by plugins.

[mickaelistria]

I suggest that instead of creating an Eclipse-specific editor, you consider creating a language server for your language. There is eclipse.jdt.ls project that provides a language server for Java that you may be able to leverage and configure to provide some smartness for your files; and also eclipseide-jdtls plugin that demoes how to embed JDT-LS inside the Eclipse IDE so the .java files are editable with the Generic Code Editor. This can also be mimicked by your language server.

[M-Marvin]

As far as I know language servers are language specific, so there will be a language server for java, rust or other languages.
Is it really the right way to make a second language server for java, just for an other classpath ?

There is nothing special about my buildscipt files, in fact, if I include the build-script project into any project containing such an buildscript file, I can edit the buildscript in the default java editor with no problems, since all classes are now in the classpath.
Maybe I am wrong, but it seems like introducing my files as a new language is overkill for this.

Also, if I would create a custom language server, how would I apply it to an custom editor to get all the standard features of an java editor ?

[mickaelistria]

OK, I think I misunderstood: you're not creating a new (build tool specific) language, but more some APIs for multiple languages to allow building?
If it is so, I don't think you'd need a new editor. The trick would indeed be to teach Eclipse to use a different classpath when opening that file. However, the file -> project -> classpath relationship is way deeper in JDT, not just in the editor; and currently it's very hard to allow different classpaths in 1 project (there have been tons of reports about it).
But this also bring new questions: are the files to be compiled as .class? are they seeing other files from this project?...
Overall, my first impression is that your build file is basically another "project" (in the meaning of JDT: another source, another classpath...). Eclipse allows nested projects, so you could try create a dedicated "build" project under your project and have this one containing and/or referencing the build files and storing all custom classpath info about it. If you manage to be happy with it, then the next steps mostly become playing with the Project Explorer to improve the layout of the project.

[M-Marvin]

The build script is a single file (only one per project) which is nothing more than a regular java source file (just with a custom file extension do differentiate it from other source files).
It does not need to be compiled by the IDE, this is handled by my custom build system (it stores the compiled version in an cache so that it does not need to do that every time it is invoked).

The only files that should be visible to that files source are the .jar files inside the build systems installation directory, it does not need to see any project related files.

Creating an separate project for that file would be a viable work around, but definitely not the preferred solution, since I planned on support multiple projects which refer each other (purely trough the build script file, nothing IDE related) and this would make it more complicated (since I would have to reference both projects, the build project and the source code project).

I will try to look into the classpath code of JDT a bit, maybe I can find some workaround, if not, I will probably try the separate project idea.

[mickaelistria]

Feel free to have a look at JDT code and suggest enhancement; however I think you can trust the dozen of people from various project (JDT, m2e, buildship...) who have all looked at this issue and all concluded that there is no such viable workaround to be found and that such case would require non-trivial, yet possible, changes in JDT Core.
However, for this case, especially if you create a particular extension/content-type, your initial idea might be more "workaround-friendly". Basically, there is the method getInputJavaElement() on JavaEditor and family you can override. What you will want is to build a different CompilationUnit for your case; particularly a custom CompilationUnit that would set the parent project and compilation options differently (ie not delegate to the current Java project, but instead build a classpath from your build tool) so those would be used by the editor rather than the unrelated project configuration.

[M-Marvin]

This seems to be exactly what I was looking for.
I managed to write this code snipped, which indeed configures the custom editor to act as an java editor with the supplied jar file as classpath:

@SuppressWarnings("restriction")
public class BuildscriptEditor extends CompilationUnitEditor {
	
	public static class Test extends WorkingCopyOwner {
		
	}
	
	@Override
	protected ITypeRoot getInputJavaElement() {
		
		File buildsystemJar = new File("Path/To/My/JarFile.jar");
		
		Test test = new Test();
		try {
			List<IClasspathEntry> classpath = new ArrayList<IClasspathEntry>();
			
			classpath.add(JavaRuntime.getDefaultJREContainerEntry());
			classpath.add(JavaCore.newLibraryEntry(IPath.fromFile(buildsystemJar), null, null));
			
			ICompilationUnit compillationUnit = test.newWorkingCopy(IMeta.BUILD_SCRIPT_CLASS_NAME + ".java", classpath.toArray(IClasspathEntry[]::new), null);
			return compillationUnit;
		} catch (JavaModelException e) {
			e.printStackTrace();
			return null;
		}
		
	}
	
}

I now only need to handle the source and javadoc attachments, I think I already figured out how to do that tough.
But I am not entirely sure what this WorkingCopyOwner is, I just figured out that I need it to create my compilation unit by looking at some JDT code.
Tips on this topic might be helpful.

Would it be ok to use above code (the "Test" class) to construct one statically and use it ?
Or should I use DefaultWorkingCopyOwner.PRIMARY which seems to be some kind of default instance ?
Maybe I don't even need it, and there is a better way to construct the CompilationUnit