| 28 Nov 2024 |
 Tomodachi94 (they/them) | * I think that depends on when they're planning on releasing Maven 4. We could also include the upstream patch(es) making reproducibility the default until then | 05:42:36 |
 Toma | I haven't looked into maven4 yet, so I don't have an opinion abot that yet. | 05:46:00 |
| Toma | Not very related but what I would like to happen sometime in the futute is that we try to figure out how to handle the default lifetime plugin issue with maven.
It's good and all that we have a FOD, but it's horrible that the hash changes every time maven is updated. | 05:46:22 |
| Toma | Maybe bundle the version-defaults with maven, and remove those from the FOD.? | 05:47:00 |
| Tomodachi94 (they/them) | 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 but not pinned, updating them one-by-one after a Maven update is merged I proposed this up here | 05:47:33 |
| 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 |
