Using IntelliJ for Development

Currently Eclipse is used as IDE.

Developing in IntelliJ does not work out of the box, because of something related to Paths an loading assets (namely, gate definiton files) from the JAR-file or a directory "next to" the JAR-file.

Task: Find a way to make switching IDEs painless, while retaining the way the assets are loaded.

The culprit is a line in GateLoaderHelper.getClasses() that contains an Eclipse-specific relative path:

//original line with Eclipse output path
// File directory = new File("bin/gates"); 

//Line with IntelliJ output path
File directory = new File("out/production/LogicSim3/gates");

This is not a bug fix, this has been a crude hack in the first place. There is no "good way" to fix this.

The code should be IDE-agnostic. The code should be unware where it is run from.

I need to think more about this...

So... we need the ability to load a limited set of logical gates from a certain directory.

We also need the ability to load the full set of logical gates from the JAR-File.

How about adding a configuration file (or option in an already present configuration file), that works like:

loadGatesFrom=/path/to/gates

If it is empty or not present, we load the full set from the JAR, it is present and not empty, we load from the specified path.

Also, the loaded Gates can be tricked into registering themselves on loading at a central "library".
This can be done using static initializer blocks that are executed when a class is loaded.

I will prepare a piece of demo code for technical review, so we can decide if we want to implement this.

So... we need the ability to load a limited set of logical gates from a certain directory.

We also need the ability to load the full set of logical gates from the JAR-File.

How about adding a configuration file (or option in an already present configuration file), that works like:

loadGatesFrom=/path/to/gates

If it is empty or not present, we load the full set from the JAR, it is present and not empty, we load from the specified path.

Also, the loaded Gates can be tricked into registering themselves on loading at a central "library".
This can be done using static initializer blocks that are executed when a class is loaded.

I will prepare a piece of demo code for technical review, so we can decide if we want to implement this.

This is unrelated to IDEs, so I split it away into a separate issue: #7 (comment)

Also, static initializer blocks are no longer (as of JDK modularization) the "easy way to go".
Since a modular JDK only loads what is referenced (and no longer "everything on the classpath"), these do not work for class registration (when used alone).

As illustrated in #7, this might be a "non-issue" though, because flexible loading can be made a "configuration thing" instead of an "architecture thing".