Updated ivysettings.xml with comments and commented out local repos. Added more docs on how to setup ivy.

Review Request #1979 — Created March 23, 2015 and submitted

zundel
pants
zundel/ivysettings-doc
1316
540c5a0...
pants-reviews
areitz, jsirois, lahosken
Updated ivysettings.xml with comments and commented out local repos.  Added more docs on how to setup ivy.

I moved the pants provided ivysetting.xml aside and subbed in the sample one I provided in the docs and pants builds.

I didn't do the same for publishing - that needs more careful eyes. I did get rid of the reference to include the ivy settings and the reference to the macro defined in the pants provided ivysettings.xml.

Ran ./build-support/bin/publish_docs.sh and looked at the output.

  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
JS
  1. It looks like you missed adding the ivysettings.xml comments / commented out bits or else the RB description is stale.
    1. Thanks, the changes are attached. They got lost when I was scrubbing unrelated changes out of the RB.

  2. 
      
ZU
ZU
JS
  1. 
      
  2. src/docs/setup_repo.md (Diff revision 2)
     
     
    These 2 properties can go.
    1. Are you sure? When I tried it at first without them pants broke. The resolved-*.xml report files couldn't be found.

    2. I'm sure - just replaced pantsbuild/pants master build-support/ivy/ivysettings with:

      $ cat build-support/ivy/ivysettings.xml 
      <?xml version="1.0"?>
      <ivysettings>
        <settings defaultResolver="chain-repos"/>
        <resolvers>
          <chain name="chain-repos" returnFirst="true">
            <ibiblio name="maven2"
                     m2compatible="true"
                     usepoms="true"
                     root="https://repo1.maven.org/maven2/"/>
            <!-- This is just for twitter-hosted jvm tools used by Pants -->
            <ibiblio name="maven.twttr.com-maven"
                     m2compatible="true"
                     usepoms="true"
                     root="http://maven.twttr.com/"/>
          </chain>
        </resolvers>
      </ivysettings>
      

      And ran this green:

      $ rm -rf ~/.ivy2/pants/com.google.guava/
      $ ./pants clean-all
      $ ./pants test examples/src/java/::
      
    3. I neglected the clean-all step, that accounts for the discrepancy.

  3. src/docs/setup_repo.md (Diff revision 2)
     
     
    This is default and could go.
    1. I only included them as examples of how to change it. Maybe I should change the value to make that clear.

    2. Agree to keeping this around, so people know how to adjust these knobs.

  4. 
      
AR
  1. LGTM, one nit below

  2. build-support/ivy/ivysettings.xml (Diff revision 2)
     
     
     

    Instead of "primarily for getting -SNAPSHOTs to work when working with two different build systems", how about:

    for sharing SNAPSHOT artifacts between different repos or build tools when developing locally.

    1. I would not like to encourage people to use this for build tools when developing locally. Having Ivy pull in from a local .m2 in my experience ranges from "it barely works" to "something is broken and I can't figure out why" I've had 3 separate instances of broken repos caused by using it. There are other ways to do it using 'mutable' attribte of jar() and a file url as documented in the contributor's guide.

    2. We have a specific workflow at Twitter, where while developing a change, engineers will publish SNAPSHOT jars to ~/.m2/repository from one git repository, and then consume them in another git repository. While we don't need the docs to point this use-case out, I'm not so sure that the docs should outright discourage it either.

      Maybe the thing to do is to document how to make pants read from a local .m2/ivy cache, and leave the specific workflow reasons why to do so as an exercise to the reader?

    3. Pants already expresses an opinion about SNAPSHOTS by not respecting them as always changing (mutable) by default.  IE: we already discourage sneakernet through mutable artifacts.  But more important than "Pants already discourages..." - I think it makes sense for pants to discourage one of the very things it was a reaction against.  Pants really does want to get you to stop thinking about artifacts except when you need to get code to "someone else" where "someone else" should be isolated from you by things you can't control like company boundaries.  Inside a company boundary pants really wants you to get all the dependencies you own source code for in one place.
    4. I mentioned this in a thread on pants-devel, but again, this would be good material for a 'Recipies' type of documentation page where you mention how to use Pants to solve different problems. I have some internal issues to work on this week, I'm not sure if I can get to it right away, but if someone else doesn't beat me to it I'll throw together an RB that shows "recipies" for developing with a local jar file, using from_target() and unpacked_jars(), and configuring a maven repo to live side by side with pants. This kind of document would be good for expressing opinions about the relative merits of these configurations too because they all seem to have their own controversies.

    5. This is a bit late to the discussion, but I'd just like to second what Eric said about users resolving from .m2--it becomes a support nightmare. Ivy always manages to cache the wrong thing, and figuring out how to invalidate that caching generally amounts to nuking subdirectories of .ivy2, running clean-all, and then nuking subsets of the local ivy artifact cache. At the very least if this knob is available, there should be a giant warning and some friendly documentation describing how badly Ivy will inevitably mess this up.

  3. 
      
ZU
JS
  1. Ship It!
  2. 
      
ZU
Review request changed

Status: Closed (submitted)

Change Summary:

Thanks for the reviews Andy and John. Commit 6f8d317

Loading...