I agree, Maven-based project dependencies are the safest way to go. This way, I can create the final JAR with Maven and not the 'Runnable JAR' export tool of Eclipse, which I cannot automate anyway.
[...]
Eclipse's project dependencies by default are not transitively inherited by other depending projects, but this can be enabled via the "Order and Export" settings by simply checking/marking the project dependency. So you could've checked project 3 in project 2's "Order and Export" tab and that would have allowed project 1 to actually see project 3's dependencies.
For the sake of completeness, I tried this, but I could not get it to work.
I got rid of the Maven dependencies (between the 3 projects), and defined two Eclipse project dependencies, Project1 -> Project2, and Project2 -> Project3.
In Project3, I go to Java Build Path > Order and Export and click the checkbox 'Maven Dependencies'
In Project2, I go to Java Build Path > Order and Export and click the checkbox 'Maven Dependencies' and Project3
In Project1, I go to Java Build Path > Order and Export and click the checkbox 'Maven Dependencies' and Project2
Project3's Maven dependencies (LWJGL) do not get to the classpath.
EDIT: to further clarify, 'Order and Export' between projects seems to make Project3's built-in or JAR-based classes accessible to Project1, at compile time. For instance, a 'Project3Class' in 'Project3' will be visible to Project1 code if I chain 'Order and Export' dependencies. Maven dependency classes, for instance LWJGL classes, will also be available at
compile time to Project1 code. However, at runtime, LWJGL will
not be in the classpath.