Code Monkey home page Code Monkey logo

Comments (2)

plaird avatar plaird commented on May 29, 2024

What works with 1:1:1 as of today

With all the work that went into more flexible package layouts #8 our 1:1:1 support is actually pretty good. In fact, if the project is laid out such that:

  • there is a root BUILD file that has a rule that rolls up all the subpackages
  • the tests are defined in that root BUILD file

Everything works if you import just the root package as an Eclipse project. Even the test launchers. Like this (assume the toplevel BUILD is in projects/libs/oneoneone):

  • BUILD (java_binary with deps on foo and bar libs, plus java_test rules) <== import this
  • src/main/java/com/salesforce/foo/BUILD (java_library with Foo.java) <== do not import this
  • src/main/java/com/salesforce/foo/Foo.java
  • src/main/java/com/salesforce/bar/BUILD (java_library with Bar.java) <== do not import this
  • src/main/java/com/salesforce/bar/Bar.java
  • src/test/java/com/salesforce/baz/BazTest.java

For this case the main thing we need to change is the import offers. We should detect 1:1:1 and mask the subBUILDs because the user should not import src/main/java/com/salesforce/foo/BUILD or src/main/java/com/salesforce/bar/BUILD as distinct Eclipse projects. Just importing the root BUILD as an Eclipse project is enough.

What doesn't work

There are problems though if the tests are defined in a subBuild. The root BUILD will not have the test deps, nor the java_test rules. For example:

  • src/test/java/com/salesforce/baz/BUILD (java_test for BazTest)
  • src/test/java/com/salesforce/baz/BazTest.java

If this is the case, the test launchers when launching the file from the root BUILD project no longer work. Also the tests show compile errors if you open them from the root project.

I think for these cases we should:

  • import the test subBUILD as an Eclipse project
  • mask the test source dir from the root package project
  • fix the name of the test package to make it clear what it is there for

from bazel-eclipse.

plaird avatar plaird commented on May 29, 2024

While there are ways to improve what we have, I think the 1:1:1 support is tolerable. As I wrote in #8, I have a new mindset that we shouldn't expect for BEF to perfectly model every Bazel build. Eclipse and JDT was not designed with the flexibility of Bazel in mind, and therefore it shouldn't be a surprise that more complex Bazel builds cannot be modeled in every case.

from bazel-eclipse.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.