just noticed that tools.build changed coordinates from org.clojure/tools.build to io.github.clojure/tools.build. Having migrated over, I now have an issue that it pulled in a much newer version of tools-deps and now antq, which I use as a library in my project, is broken because it relies on a broken 2-arity version of deps.util.maven/remote-repos.
I notice that antq is not being maintained, and somewhat ironically all its dependencies are really old.
Any idea how I get this fixed? I have an https://github.com/liquidz/antq/pull/302 where I have bumped all the deps and fixed all the deprecation issues, but I have zero faith it will be merged at the moment.
I've managed to hack a workaround using with-redefs in my project, so I'm not dependent on this being fixed upstream right now... I suspect things will only get worse as antq's deps fall further behind though.
@liquidz.uo not sure if you are active on Clojurians Slack, but it would be great if antq could get a little love. Let me know how I can help in any way.
I use antq as a command-line tool instead of as a library embedded in my build, but I run it as part of my build, programmatically using b/java-command.
I am very happy to help maintain antq in place or as part of clj-commons ❤️
> I use antq as a command-line tool instead of as a library embedded in my build, but I run it as part of my build, programmatically using b/java-command. yeah, we used to do that, but we were troubled by inconsistent use, so we added antq as a dep to our internal tools-build helper lib and standardised the invocations. I guess that's an uncommon usage pattern, hence we hit this issue. Regardless, I think it is not great that antq's deps are so far behind, so I hope my pull request gets merged.
Indeed. I checked the member list and uochan is "Inactive" as far as Slack is concerned, so maybe reaching out via email is worthwhile...
From their GitHub: <mailto:liquidz.uo@gmail.com|liquidz.uo@gmail.com>
I think they should get an appropriate notification from GitHub via the pull request... but if they have gone off-grid, there isn't much we can do
As @lee says, we'd be happy to have antq in clj-commons and actively maintain it there. I rely on it for all of my OSS projects, as well as work.
It really is a nice project, would love to give it some love
They have an automated dependencies GHA but it has been failing for over a year, presumably because of this issue 😞
I DMed uochan a while ago with no response, I’ll give the email route a shot
@t.denley Presumably, you could depend on your PR via git deps for now? Can you explain why you still need the with-redefs hack?
could do, but then I probably wouldn't notice if the upstream did make an official release
Well, you'd be notified that your PR was merged... I've run with git deps against one of my PRs for over a year before it got merged...
now that tools.build is available in bb, perhaps antq can finally full work in bb too (or maybe it already does?)
I had a brief look at the source: it has some Maven-y Java interop in it.
$ bb -Sdeps '{:deps {com.github.liquidz/antq {:mvn/version "RELEASE"}}}' -m antq.core
----- Error --------------------------------------------------------------------
Type: java.lang.Exception
Message: Unable to resolve classname: org.apache.maven.model.Model
Location: antq/util/maven.clj:14:3
:/well nothing that could not be helped :)
you can :override-deps in your :antq alias if you need an older version of tools.build
now that I have tools.build working in bb, I might make a mild fork of antq that works with neil. Neil not working with private repos and other mvn specific things was something on my list to fix!
Ok, I sent an email to uochan! I'll let you know if I get a response.
meanwhile locally.
$ bb -Sdeps '{:deps {com.github.liquidz/antq {:local/root "."}}}' -m antq.core
[##################################################] 22/22
| :file | :name | :current | :latest |
|------------------------------------|-------------------------|--------------|---------------|
| .github/workflows/coverage.yml | actions/cache | v4 | v6.1.0 |
| | actions/checkout | v4 | v7.0.1 |
...have you timed it?
bb's version starts way faster but since it scans 22 libraries over mvn, github actions, etc, bb is finished in 7 seconds vs clojure in 9
not bad at all
You're a monster @borkdude 🙂
I'd be interested to test it via bb over our repo since we have to programmatically construct a huge command-line so it scans all the projects/*/deps.edn files in our Polylith repo. But I think it would be easy to switch from a Java process to a bb shell...
@borkdude Just swapped our build/ancient task over to use your bb-compat fork of antq and it works identically to our old JVM/Clojure approach. Nice!
@seancorfield uh ... oh! It probably needs more testing before I want to make it public, but .... I guess someone is already using it... I'm not done with it yet :)
No worries, just wanted to do a sanity check on it.
thanks! :)
That's scanning two dozen projects in our Polylith monorepo at work.
I fixed one NPE bug in bb because of this branch, a pom with an empty <version></version> node caused an NPE.
But other than that, it seems to work pretty well.
I'm going to tidy the code a bit more before I go more public with it
need to check a few things
Perhaps bb can expose a public mvn interface so I don't have to redo a lot of stuff that bb already does internally for its mvn stuff (but under impl namespaces)