Imported BEF projects can have a circular dependency

[simontoens]

Given these bazel packages/targets:

/libs/l1:prod
/libs/l1:test

/libs/l2:prod
/libs/l2:test

And these references:

//libs/l2:prod depends on //libs/l1:prod
//libs/l1:test depends on //libs/l2:prod
//libs/l2:test depends on //libs/l1:prod

Bazel is ok with this because it can build in order:

//libs/l1:prod
//libs/l2:prod
//libs/l1:test
//libs/l2:test

However, for BEF this is a problem because we create one Eclipse project for
//libs/l1:* and one for //libs/l2:*, and the target dependencies create a
circular reference between these two projects, which is not allowed by
Eclipse.

Best case, the import actually succeeds but the project references are wrong:
Eclipse project l1 references Eclipse project l2, but l2 references libl1.jar (not the imported project, but the compiled jar)

Worst case, we get into an infinite loop (stack overflow) when trying to compute
the project order:

java.lang.RuntimeException: java.lang.StackOverflowError
at com.salesforce.bazel.eclipse.projectimport.flow.FlowProjectImporter.runFlows(FlowProjectImporter.java:90)
at com.salesforce.bazel.eclipse.projectimport.flow.FlowProjectImporter.run(FlowProjectImporter.java:71)
at com.salesforce.bazel.eclipse.wizard.BazelProjectImporter$1.run(BazelProjectImporter.java:33)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Caused by: java.lang.StackOverflowError
at java.base/java.nio.Buffer.(Buffer.java:222)
at java.base/java.nio.CharBuffer.(CharBuffer.java:281)
at java.base/java.nio.HeapCharBuffer.(HeapCharBuffer.java:75)
at java.base/java.nio.CharBuffer.wrap(CharBuffer.java:393)
at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:280)
at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:211)
at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120)
at java.base/java.io.PrintStream.write(PrintStream.java:605)
at java.base/java.io.PrintStream.print(PrintStream.java:745)
at java.base/java.io.PrintStream.println(PrintStream.java:882)
at org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.println(ThreadPrintStream.java:179)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:236)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)
at com.salesforce.bazel.sdk.model.BazelDependencyGraph.isDependencyRecur(BazelDependencyGraph.java:256)

[plaird]

The most rigorous solution is to support target scoped classpaths described in #407 in my comment on March 13, 2022. But not only would that be a lot of work, I am not sure many users would like that from a UX point of view.

As an MVP solution, we will ask users to exclude the target that is causing the circular dependency during import. See #73 for details for that. Once we implement that solution, we might detect the circular reference and ask the user to choose what target to excluse as the solution to this work item.