As described in this article:
It would be helpful for platform developers (especially when using IntelliJ or Eclipse IDE) to run a platform application in which modules are directory structures (corresponding to an extracted JAR file), rather than a JAR file itself. This would help to reduce turnaround times between making a change in a platform application and seeing that change when the program finally runs (since a developer could compile class files and launch the application without using Ant, for typical modifications).
I did some experimentation which indicated that the only obstacle seemed to be org.netbeans.ModuleInstaller's loadManifest method, which assumes a module's manifest exist within a JAR file. I was able to make a simple modification to handle the case where the "JAR" is actually a directory, and then loads the manifest from the META-INF/manifest.mf below that.
If you agree with this approach, let me know and I will create a patch which includes this modification, plus a test case and documentation. If not, I'd appreciate if you could describe a better alternative approach.
I know there is JarClassLoader.DirSource, so the system is capable to load classes from a directory. Also there is a way to specify patches for each module:
StandardModule.java: System.getProperty("netbeans.patches." + getCodeNameBase())
possibly this property could point not only to a JAR but also to a directory...
Anyway, if you want to make classloading work, go on. Just make sure subsequent starts with caches don't touch any new files on disk.
Created attachment 108851 [details]
I am attaching a tentative patch. It's untested and contains no documentation, so it's not ready to be applied, just making sure I can pick up where I left off from another machine when I work on it again.