| 28 Nov 2024 |
 Tomodachi94 (they/them) | * I proposed something related up here | 05:47:40 |
| Tomodachi94 (they/them) | In reply to@tomasajt:matrix.org
Maybe bundle the version-defaults with maven, and remove those from the FOD.? That seems like the ideal path. Or maybe having them in separate packages that expose Maven repository-ish paths | 05:49:07 |
| Tomodachi94 (they/them) | * I proposed something related up here (don't know if it would work) | 05:50:18 |
 Toma | In reply to @tomodachi94:matrix.org
I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them after a Maven update is merged An alternative would be to just pin maven for every package.
Very simple solution, but not very pretty.
Though, I doubt the plugin patching solution would be much prettier. | 06:00:39 |
 emily | to an exact minor version? | 06:01:31 |
| emily | or just a major version? | 06:01:36 |
| Toma | Exact version | 06:01:52 |
| emily | I don't think we want/can sustain that level of version proliferation | 06:02:04 |
| Toma | You're right, it would just delay the inevitable manual re-pinning in the future | 06:03:56 |
| Toma | By the way I have a package that uses mill as the build system (IIRC it's the only one in the tree), which also fetches jar files from Ivy. What's much worse about that is that we can't pin any internal plugin versions, like with maven. As a solution I just locked the version of mill.
Not sure if there was anything better I could have done. | 06:09:33 |
| emily | you know, you don't have to deal with FOD stability issues if you just build everything separately from source :) | 06:12:37 |
| emily | (I know, I know, but I gotta keep beating the drum…) | 06:12:43 |
| Tomodachi94 (they/them) | (I wonder how much effort it would take?) | 19:57:09 |
| Tomodachi94 (they/them) | We could introduce mavenRepository attrset which exposes JARs with Maven-friendly paths (many build systems speak Maven, including Maven, Gradle, and Ivy). The packages would just be derived from ones that are in the mainspace (or another namespace; maven.plugins could be one) | 19:59:07 |
| Tomodachi94 (they/them) | The idea would be to symlinkJoin the packages and then pass the path to whichever build system | 19:59:33 |
| Tomodachi94 (they/them) | In other news: I have a fully built-from-source version of Ant locally (with the exception of three censored JARs that I intend to build from source) | 20:00:58 |
| Tomodachi94 (they/them) | * In other news: I have a fully built-from-source version of Ant locally (with the exception of three vendored JARs that I intend to build from source) | 20:01:05 |
| Tomodachi94 (they/them) | * In other news: I have a fully built-from-source version of Ant locally (with the exception of three vendored JARs that I intend to also make from-source packages out of) | 20:01:26 |
| Tomodachi94 (they/them) | (jj threw up on itself after I switched away from that revision, so it's stuck in there somewhere) | 20:14:51 |
| Tomodachi94 (they/them) | Turns out my Git repo is corrupted. Always push your work to a remote, kids | 20:19:09 |
| Tomodachi94 (they/them) | (Aside: wondering if it's because I used a blobless clone) | 20:29:03 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
In other news: I have a fully built-from-source version of Ant locally (with the exception of three vendored JARs that I intend to also make from-source packages out of) Fun times, one of those dependencies uses Maven, so all changes to Maven would now need to go to staging | 21:50:18 |
| Tomodachi94 (they/them) | * Fun times, one of those dependencies uses Maven, so all changes to Maven would now need to go to staging if we chose to do that | 21:51:22 |
| Tomodachi94 (they/them) | (The cumulative number of rebuilds would be about a thousand. Ant is about 800, Maven is a little under 200 iirc) | 22:54:18 |
| Tomodachi94 (they/them) | * (Aside: wondering if it's because I used a --reference clone) | 23:19:30 |
| 29 Nov 2024 |
| Tomodachi94 (they/them) | Could someone take a look at <https://github.com/pull/360019>? It modernizes Ant to make it follow modern conventions (where it didn't cause rebuilds) | 01:28:08 |
| Tomodachi94 (they/them) | * Could someone take a look at <https://github.com/NixOS/nixpkgspull/360019>? It modernizes Ant to make it follow modern conventions (where it didn't cause rebuilds) | 01:37:33 |
| Tomodachi94 (they/them) | (Probably would help to give the correct link) | 01:37:44 |
| Tomodachi94 (they/them) | * Could someone take a look at <https://github.com/NixOS/nixpkgs/pull/360019>? It modernizes Ant to make it follow modern conventions (where it didn't cause rebuilds) | 01:55:17 |
| Tomodachi94 (they/them) | * (Probably would help to give the correct link 🙃) | 03:17:10 |
