And our parallelism protection might be defeated

imo there should just be one way to do this, and pants should control it

@bored-art-40741: ...unless somebody has injected it manually

Why should we allow that?

They have the exact same knobs in pants.ini

because we have caches configured in other places

hm

i think i can give you our configs.

It's only the resolution cache that I care about forcing, to be clear

hm, maybe I actually can get away with making this optional

@jolly-chef-92794: what’s the dependency elements in the ivy.xml that is generated end up looking like?

@fancy-queen-20734: Currently (ie without that if-statement commented out), like this:

<dependency org="org.apache.hadoop"
                name="hadoop-common"
                rev="2.0.0-cdh4.6.0"
                
                
                
    >
      <conf name="default" mapped="default"/>
      <exclude matcher="exact" org="org.jboss.netty" module="netty"/>
      <exclude matcher="exact" org="tomcat" module="jasper-compiler"/>
      <exclude matcher="exact" org="org.sonatype.sisu.inject" module="cglib"/>
      <exclude matcher="exact" org="org.slf4j" module="log4j-over-slf4j"/>
      <exclude matcher="exact" org="org.mockito" module="mockito-all"/>
      <exclude matcher="exact" org="org.mortbay.jetty" module="jsp-2.1"/>
      <exclude matcher="exact" org="org.glassfish.web" module="javax.el"/>
      <exclude matcher="exact" org="hsqldb" module="hsqldb"/>
      <exclude matcher="exact" org="org.mortbay.jetty" module="servlet-api-2.5"/>
      <exclude matcher="exact" org="tomcat" module="jasper-runtime"/>
      <exclude matcher="exact" org="org.assertj" module="assertj-core"/>
      <exclude matcher="exact" org="org.mortbay.jetty" module="servlet-api"/>
      <exclude matcher="exact" org="org.bouncycastle" module="bcprov-jdk15on"/>
      <exclude matcher="exact" org="javax.servlet" module="servlet-api"/>
      <exclude matcher="exact" org="org.eclipse.jetty.orbit" module="javax.servlet"/>
      <exclude matcher="exact" org="com.google.guava" module="guava"/>
      <exclude matcher="exact" org="commons-logging" module="commons-logging"/>
    </dependency>

so with it commented out, what do you get?

that plus a artifact?

Let me dig up the file

Untitled.txt

@fancy-queen-20734: Yes ^

hmm. maybe something else pulls in the test-jar? And then because the empty artifact isn’t there, the jar isn’t pulled down.

It looks like ivy always pulls down both jars, but only actually includes one of them in the xml report (and the generated classpath)

Depending on what sets of targets I run together on the CLI, I either get the normal jar or the test-jar

Despite none of the unrelated targets directly mentioning hadoop-common (it’s only referenced transitively, except in the one place I specifically declare it to try to fix this issue)

I was thinking that there might be a transitive “jar” dependency

ie, ivy downloads something that depends on one

but it could just be that ivy gets buggy without explicit artifact entries

wrt the artifact if clause deletion, #shipit!

It also depends on the "conf" you're resolving with respect to

e.g. runtime or test vs compile

Yeah, but with an explicit dependency like:

jar_library(name='extra',
  jars=[
    sjar('org.apache.hadoop', 'hadoop-common', rev='2.0.0-cdh4.6.0', ext='jar', classifier=None),
  ],
)

There’s no excuse for not pulling that jar in =P

I’ll put up a review to delete that clause

Ah yes