 | Propensive / Fury | 16 Members |
| Fury build tool | 2 Servers |
| Propensive / Fury | 16 Members |
| Fury build tool | 2 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Dec 2020 | ||
 jozinek#0918 | * ah... so even if I can run build, fury would not allow it, I see | 20:21:54 |
 propensive | Yeah, even if you happen to know that everything is fine because the difference is irrelevant, Fury won't let you. | 20:22:00 |
| propensive | That's basically because we can't do better yet... | 20:22:16 |
| jozinek#0918 | cool, so now finally back to the original purpose of shading function | 20:22:29 |
| propensive | Did you get some output from fury universe projects? | 20:22:46 |
| propensive | It should list everything, but the conflicting project should appear twice with two different hashes after its name. | 20:23:08 |
| jozinek#0918 | exactly as you said | 20:23:23 |
| propensive | there are some tools for resolving conflicts like these, but they need to get a bit better before I make a release... | 20:24:19 |
| propensive | (there are also some bugs here, too...) | 20:25:12 |
| jozinek#0918 | so how I understand shading problem, I don't think renaming package will solve the problem with conflicting layer. Or do I miss something? | 20:25:41 |
| propensive | So, the problem is this: | 20:26:06 |
| propensive | Project X and Y depend on different versions of Z (Z1 and Z2). W depends on both X and Y. And we're going to say that it's impossible or inconvenient to make X depend on Z2 or Y depend on Z1. So we need both versions on the classpath. But all of Z's classes are in the com.z package, regardless of which version they're in. So they're going to get mixed up when both versions are on the same classpath. That will be discovered in W with a linking error (Method/ClassNotFound). (At least it would be, if Fury would allow it!) | 20:29:19 |
| propensive | So we need to have a way for W to use both Z1 and Z2, because it needs both X and Y, and shading lets us do that by renaming com.z to somethingelse.com.z for one of the versions (but not the other). That "renaming" will be done to the bytecode but it needs to be done to Z1 & X (or to Z2 and Y). That is, the original compiled Z1 needs to have its bytecode rewritten to use a new package, and also X needs to be rewritten to update all its references to Z1. | 20:32:30 |
| propensive | Luckily, there are some tools for doing the difficult part - the bytecode rewriting. We just need to wire that into Fury. | 20:33:08 |
| jozinek#0918 | Yep, that is fine. What I do not get is how this relates to resolving conflict of layers. | 20:34:04 |
| propensive | I'm not sure what libraries do the rewriting, so you'll need to find out what the options are. There are SBT and Maven plugins which do shading, so it should just be a matter of checking how they do it. | 20:34:05 |
| propensive | Ah, ok. | 20:34:22 |
| propensive | So the layers you've set up simulate the scenario of conflicting transitive projects. In practise, those layers may be owned by different users. Fury is currently doing its job correctly and stopping you from building something which might not work at runtime. | 20:35:33 |
| propensive | When we introduce shading into Fury's user interface, though, we'll be able to declare that in the process of importing X, we will shade certain projects within that layer. That will have the effect that Fury will add an additional step to the build which does the shading, but it will also "remove" the conflict you currently have. | 20:37:23 |
| propensive | So I'd like to add a command like, fury layer shade -i project-x -p project-z which would fix everything. 🙂 | 20:38:27 |
| jozinek#0918 | by removing you mean: I see 2 versions of some layer but I assume you can handle that by yourself by running fury layer shade ...? | 20:39:09 |
| propensive | Small correction: you see two versions of some project. | 20:39:34 |
| propensive | But yes, the shading command will associate with the layer import the detail that one (or more) of its projects should be shaded. | 20:40:22 |
| propensive | By the way, the point of my correction is that projects conflict, not layers. (You may also have two different versions of the "same" layer, but that might be fine if the projects inside them are identical.) | 20:41:42 |
| jozinek#0918 | I see, sorry for confusion, still getting the terminology 😊 | 20:42:22 |
| propensive | Yeah, it's subtle sometimes, especially when it's different from "other things"... 😉 | 20:42:57 |
| jozinek#0918 | I would continue: - writing first version of fury layer shade which will ignore the conflict and actually make compile time error- improving first version to make compilation happen by shading one of the dependency | 20:44:28 |
| jozinek#0918 | * I would continue wich: - writing first version of fury layer shade which will ignore the conflict and actually make compile time error- improving first version to make compilation happen by shading one of the dependency | 20:44:40 |
| jozinek#0918 | * I would continue with: - writing first version of fury layer shade which will ignore the conflict and actually make compile time error- improving first version to make compilation happen by shading one of the dependency | 20:44:45 |
| jozinek#0918 | but for both of those I need working fury build | 20:46:01 |