hmm, okay

if you use url it turns of trnasitive dep resolution

because .... no corresponding pom url is added

so you could fix that if you want, or doc it

I don’t think that’s quite the problem I’m getting. With some fiddling I can get it past the javadoc problem, but I instead get a:

FAILURE: Classpath entry /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/lib/tools.jar for target integration/hibernate/criteriabuilders/src/main/java:aux-jar_files is located outside the buildroot.

Which seems odd because I just specified a

url=‘file:///Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/lib/tools.jar'

, so I had assumed ivy would just “download” it into the buildroot.

The resolve report / ivydata.properties will clear up confusion

My guess is "location" is listed as the local fs location for url

So our code needs to handle that case and does not today

Yeah, that seems to be the case

<artifacts>
                                        <artifact name="tools" type="jar" ext="jar" status="no" details="" size="18215783" time="0" location="/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/lib/tools.jar">
                                                <origin-location is-local="true" location="/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/lib/tools.jar"/>
                                        </artifact>
                                </artifacts>

K - so thats a bug in our handling - 2 bugs, dealing with this, and then an enhancement to allow url to mean try to find the parallel pom too, fall back to no metadata if none though

I have 3 bugs to file, but I'll do that a bit later after I get up an RB diff

Actually - @jolly-chef-92794 do you use useOrigin in your ivysettings.xml in a custom cache setup?: http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html

We do have this in `ivysettings.xml`:

<caches default="default" lockStrategy="no-lock" useOrigin="true">
    <cache name="default" basedir="${ivy.cache.dir}"/>
  </caches>

That's the problem here then

useOrigin="false", the default, should find that artifact getting copied into the ivy cache

The only need I've found for userOrigin="true" is an esoteric use-case, I think, for you - resolving -SNAPSHOT publications from sbt local publishes

So I thinj this is likely cargo cult and you can safely kill

I think you can kill the whole <caches/> in fact

Thats all default stuff save for useOrigin

Looks like that’s working. Thanks john!

Excellent - you're welcome

@mammoth-pharmacist-54215: https://rbcommons.com/s/twitter/r/2835/

@fancy-queen-20734: post https://rbcommons.com/s/twitter/r/2835/, are you happy with https://rbcommons.com/s/twitter/r/2827/ ?

That should cover my concerns I think.

has the commit process changed wrt the CHANGELOG?

because we might want to update the contrib guide

@witty-crayon-22786: If we do updates to CHANGELOG on release, I’m good with 2827, otherwise I’d like to see it updated first

you mean the review description? sure.

oh, yeah—the review descriptions are added to the changelog now, right?

I think we should clarify that in the docs.