src/python/pants/backend/jvm/ivy_utils.py (Diff revision 1)

I prefer going to @staticmethod when the cls is not needed and there is no intention of over-riding on a subclass.

1. 

   Benjy Weinberger Nov. 6, 2014, 10:07 p.m.

   Yeah, I think I did that for uniformity with xml_report_path. Changed.

src/python/pants/backend/jvm/tasks/provides.py (Diff revision 1)

Odd indent, how about a higher-level break and:
      outpath = os.path.join(self.workdir,
                             '{0}.{1}.provides'.format(IvyUtils.identify(targets)[1], conf))

1. 

   Benjy Weinberger Nov. 6, 2014, 10:07 p.m.

   Done.

src/python/pants/backend/codegen/tasks/thrift_linter.py (Diff revision 1)

I know this isn't a changed line, but it's missing the fact that it can now be set with an ENV variable too, right?

src/python/pants/backend/jvm/ivy_utils.py (Diff revision 1)

I don't use this, but I see how it could be helpful if you are routinely using -SNAPSHOT jars when debugging libraries outside the repo. But I rarely do this and setting the 'mutable' flag on the individual jar() decls has always worked for me.

1. 

   Benjy Weinberger Nov. 6, 2014, 10:06 p.m.

   Yeah, after talking this over with jsirois, we concluded that the ability to set 'mutable' in the BUILD file is enough.

src/python/pants/backend/jvm/tasks/ivy_resolve.py (Diff revision 1)

I am pretty sure this is slower than it could be.  I think it would be faster to resolve these all at once instead of invoking ivy multiple times inside a loop.

1. 

   Benjy Weinberger Nov. 6, 2014, 10:06 p.m.

   You may be right, this has been refactored so many times. It's probably worth taking another look at, but Ivy has always been a tricky beast, and sometimes things have to be a certain way for non-obvious reasons (that should be documented but aren't always).

Ship It!