it is done in the default selector

hadn’t even thought of that.

special handler there, I'll send you classname in a moment

that is the default

DependencyTraverser

I disabled that, and my resolution of things like ElasticSearch ended up being like 300 artifacts instead of 80

so it obviously does something

I think newer publishing takes them out of dependency list and moves them into relocations only, but not every publishing is new, or using the automatic maven pom generation that handles that

interesting. i’m still not entirely sure we shouldn’t just embed aether

I have a much faster Aether, I can share it with you later today

it basically stops Aether from doing the same action 1000 times

heh

by blocking it when it goes in to repeat the same action again

you give it all dependencies and it resolves them all at same time, and blocks anything from happening twice

(allow local metadata lookups again, because that is hard to block)

when I get home I can publish it to a stand-alone brikk module

and you can try it and see it

it also can ignore the embedded repos in other poms if you want to report them but not allow them, normally aether can only just ignore them.

(brikk doesn't allow them to be used, it reports their use as an error and has you accept that repo or not in case you don't want it. prevents attacks on JARs and ensures only repos you intend are used)

...when back home I can publish it github+maven central

if you use brikk which is using Aether, you'll start to get conflict checking and resolution for free from brikk as well. lock file for build, local copy of dependencies, etc.

I'll post here in a bit after I publish the FastAether module

@evanchooly: there is some logic about poms that have repos in them, and finding an artifact in one of those repos, how it is supposed to behave. I'm trying to figure out the exact logic, because I did optimization of controlling aether that ended up having it pull pom from one site, and sha signature mismatched because it was from another repo.

(and why don't the two repos match?!?)

unwinding my optimization for now

I did what seemed logical, and it doesn't work. so it does something sillier

if i could change anything about how deps like these are handled is that we’d have a federated system rather than one maven central or bintray

something discovery based like torrent seeding

though that does make signing/verifying a touch more difficult

reliability of people's repos would probably suffer. why not just one true publishing place that is highly tolerant, geo distributed, and works? and a better pubilshing with good rules that people don't screw up.