Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mike Slinn
    @mslinn
    @eed3si9n Several things:
    1) I'm solely motivated at this time by issues regarding multi-project builds.
    2) I found "provided->test" in the SBT unit tests.
    3) Using an unqualified"provided" as is (or even just for compile scope) is essential when developing modules, if methods/classes need to be resolved in order to build
    4) Not considering publishing subprojects at this time, either locally or publicly, although a case might be made for doing that. Certainly not considering ever publishing unit tests
    BTW, assigning "provided" scope to a subproject from another subproject seems to work just fine for me.
    eugene yokota
    @eed3si9n
    everything mostly works for the person developing
    the tricky part is how the modules behave when they are downloaded from Maven
    and how POM looks like
    Mike Slinn
    @mslinn
    Hehe. Usually I experience the opposite: nothing ever works for me :(
    Again, I'm only talking about how subprojects work, not for dependencies coming from Maven or Ivy
    eugene yokota
    @eed3si9n
    i get that
    Mike Slinn
    @mslinn
    ... although I have also had good success using "provided" on Play when publishing Play enhancements
    eugene yokota
    @eed3si9n
    you have subproject A and B, and could depend on some exotic way, which works only in the context of Ivy
    then you publish A and B
    the third party (let's say Bob) tries to use B as a library
    Bob only sees the POM of B
    which may or may not describe the dependency to A correctly
    Mike Slinn
    @mslinn
    Here is the scenario: subprojects A and B are used to build C. No-one else ever sees A or B, just C.
    A and C need any unresolved methods/classes to be "provided" in order to compile. Especially for Play, where it is really hard to create a subproject that can be tested by itself. Sometimes Play artifacts need to be stubbed/mocked in order to compile/test.
    eugene yokota
    @eed3si9n
    I guess ymmv
    I recently got burnt by the scoping of inter-project dependencies, so I'm a bit paranoid about this
    Mike Slinn
    @mslinn
    In my case I have subprojects model, authentication, services and webapp (root).
    I agree this can be tricky to get right, which is why I'm reaching out to you. This needs to be figured out, and "the golden path" documented.
    eugene yokota
    @eed3si9n
    my general recommendation, at least for non-experts, is don't do funny business
    Mike Slinn
    @mslinn
    Some subset of all possible setups should work reliably, and also there be dragons.
    eugene yokota
    @eed3si9n
    subproject is more reliable than Ivy configuration
    Mike Slinn
    @mslinn
    You said yourself in our last discussion that subprojects are the official way to put together SBT builds.
    eugene yokota
    @eed3si9n
    yes. subprojects are great
    Mike Slinn
    @mslinn
    Let's see if we can't straighten out what is known to work, and provide warnings for potentially problematic setups
    eugene yokota
    @eed3si9n
    like I said the trap is ->test
    it's tempting but it's a trap
    Mike Slinn
    @mslinn
    OK. I'm unclear as to the exact setup where that might be a problem, so please tell me about it
    eugene yokota
    @eed3si9n
    anytime you depend on some other external project or subproject's test dependency one would run into various issues
    when sbt publishes tests, it encodes using Maven classifier for example
    Mike Slinn
    @mslinn
    BTW, I think there I've seen a suggestion in the official SBT docs (somewhere) that tests from dependencies can be referenced from a subproject's tests, but I also think it would be fine to put that in the category of "Things not to do"
    eugene yokota
    @eed3si9n
    that could effectively end up introducing test code into the depender's Compile configuration and drop the real dependency
    a lot of it is case by case if you're a library author, or an app developer
    Mike Slinn
    @mslinn
    There are more app developers, and they tend to be less advanced, so they are the ones for whom guidelines are most needed
    "how to boil water, in 3 easy steps"
    eugene yokota
    @eed3si9n
    sure
    I think the useful pattern would be how to share code during testing kind of stuff?
    Mike Slinn
    @mslinn
    Given the scenario of a non-trivial app - say a Play app, each subproject needs to be testable, and there needs to be integration tests too, and the webapp needs to also get built
    Play makes it more complex because the root subproject uses different a directory structure, etc due to the PlayScala plugin
    Mocking and stubbing is inevitably part of the conversation
    eugene yokota
    @eed3si9n
    Mike Slinn
    @mslinn
    Not a single mention of Provided in the Play docs
    Almost none in the SBT docs.
    eugene yokota
    @eed3si9n
    provided in general is a useful concept
    Mike Slinn
    @mslinn
    Let's give it some love
    My first post above had two places where that could be done
    eugene yokota
    @eed3si9n
    probably the best page to introduce the notion would be http://www.scala-sbt.org/0.13/docs/Library-Dependencies.html
    Mike Slinn
    @mslinn
    "provided" could indeed be mentioned on the introductory page for library dependencies. The next page discusses subprojects: http://www.scala-sbt.org/0.13/docs/Multi-Project.html, and "provided" should be mentioned again, this time for related subprojects. The other two spots I mentioned should still be enhanced.
    Mike Slinn
    @mslinn
    Of course, the mention of "provided" on the introductory page for library dependencies would be only of interest to library developers, whereas the discussion on the multi-project page would be aimed at app developers