 | Propensive / Fury | 16 Members |
| Fury build tool | 2 Servers |
| Propensive / Fury | 16 Members |
| Fury build tool | 2 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Dec 2020 | ||
 GitHub#0000 | [fury:issue/1592] 1 new commit
| 11:10:34 |
 chuchulo | propensive Hi, I am able not to build the issue/1592 branch. Please let me know when It will be sorted out, thank you. Now I have issue with | 16:54:03 |
| chuchulo | * propensive Hi, I am able not to build the issue/1592 branch. Please let me know when It will be sorted out, thank you. Now I have issue with | 16:54:37 |
| 3 Dec 2020 | ||
 jozinek#0918 | propensive I am quite surprised how difficult for me is to create project with dependencies requiring shading. I am not familiar with scala libraries which break compatibility. I believe you mentioned it should have been straightforward, would you please give me some hint about possible libs? | 22:24:41 |
| 4 Dec 2020 | ||
| chuchulo | jozinek what about this https://stackoverflow.com/questions/13620281/what-is-the-maven-shade-plugin-used-for-and-why-would-you-want-to-relocate-java would it be helpful? | 00:03:01 |
| jozinek#0918 | Well, I am not sure. Ideally I would like to have 2 libraries, A and B, where B.v2 is transitive dependency of A. I want to use A and B.v1 in my layer, but different version of B (thus v1 and v2). v2 should not be compatible with v1 so I cannot simply use v2 and must repackage v1 | 00:13:24 |
 propensive | Hi chuchulo and jozinek | 09:48:24 |
| propensive | Sorry I've been a bit tied up with other things recently (Functional Africa talk for the Functional Scala conference is now done, and my two-weeks-of-training will finish this evening, and then I only have one more talk to do at a Java conference on Saturday...) | 09:49:41 |
| propensive | But the problem chuchulo is getting is somewhat known to me. My best guess is that the remote versions of the repositories have lost certain commit hashes when I went and deleted some old branches. The repositories exist, but the particular commit is missing. However I think I'm seeing this more than I should be. I've seen problems where I didn't expect to. So I have a suspicion that something else is wrong. | 09:57:46 |
| propensive | There's an open PR where I start to fix some of these issues by updating to the latest commit hashes in the relevant repos, but I've hit a different problem which is that my latest version of Contextual contains a bug which stops some later projects compiling, and I want to fix the bug rather than revert back to the earlier version. | 10:02:40 |
| propensive | Anyway, I hope to work on this on Monday now. | 10:03:32 |
| propensive | jozinek I think it would be better to start by creating your own "libraries" that are incompatible. Create a simple library with one object and one method, and publish it in a Git repository (and tag it, if you like), then update it to use the same object (we need them to conflict to demonstrate the problem) but change the method name. We want a compile error, not a runtime error, at least to begin with, so don't just change the method implementation. Then create two new projects with different names which both depend on your first project, but different versions. | 10:07:35 |
| propensive | Then it should be possible to create a fourth project which depends on both of the intermediate projects. | 10:08:48 |
| propensive | Now, in terms of publishing, we'll need to set things up to be "realistic", which means that the different projects will be in different layers. | 10:09:21 |
| propensive | So, I think in all cases, you can create a new layer for each project, and you should be able to fury layer share it. That should give you a fury:// URL you can import without needing to publish a tagged name. | 10:11:42 |
| propensive | Now, as long as both different versions of the root project are set up with the same name, Fury will report a conflict and forbid you to build. | 10:13:33 |
| propensive | I'm going to change the UI to support a "shading" transformation to take place on-import. | 10:14:18 |
| GitHub#0000 | [fury:issue/1569] 1 new commit
| 10:42:17 |
| GitHub#0000 set a profile picture. | 10:42:29 | |
| GitHub#0000 | [fury:issue/1569] 1 new commit
| 10:42:29 |
| chuchulo | propensive Appologize, I didn't want to rush you. I just wanted to know if that it is already fixed, or I do something wrong. So thank you anyway. | 18:00:15 |
| chuchulo | * propensive Appologize, I didn't want to rush you. I just wanted to know if that it is already fixed, or I do something wrong. So thank you anyway.😇 | 18:01:20 |
| jozinek#0918 | Does depends on here mean adding a github repo to project? | 21:48:42 |
| jozinek#0918 | * Does depends on here mean adding a github repo to project? I.E. use something like fury repo add gh:... | 21:50:00 |
| propensive | chuchulo No worries at all, I was just trying to set your expectations appropriately! | 23:16:29 |
| propensive | jozinek Yes, it's probably easiest to use a git repository to store the sources. Nothing to stop you using the same repository for all the versions of all the projects. You'll need to add the same repo to each layer, but you can choose different source directories for each of the projects. | 23:18:59 |
| propensive | So, to get started, I'd do this (you might need to fix some typos/bugs):then do the same again with conflict-bThen set up new projects depends-on-a and depends-on-b which are basically,and then create a fifth layer which imports the layer containing depends-on-a and depends-on-b. When you try to build this one, it should fail with a conflict on the conflict project, which is pulled in transitively by different layers. | 23:26:26 |
| propensive | And it's considered a conflict because the the definition of conflict will be subtly different in each of those two transitive layers. | 23:27:19 |
| propensive | I'm planning on implemented some commands (or maybe you'd like to try?) which would be something like:which would be run in the final layer and would shade the version of the conflict project coming from the <import-name> layer, as seen from the layer it's run in. | 23:32:49 |
| propensive | It would effectively allow conflict and (say) conflict#shaded different names so they could coexist in the same layer. The projects would have different names, and some additional code would run which rewrites the bytecode before it's used in the final layer. | 23:34:05 |