Closed bgyori closed 2 years ago
Thanks @bgyori !
I am not sure what is causing this. Maybe @kwalcock can take a look?
I did see this come in yesterday. It shouldn't take long to figure out. Probably a duplicate file was added to an updated library dependency and needs to be filtered. It will hopefully be taken care of by Monday.
Thanks Keith!
On Sat, Nov 27, 2021 at 12:33 Keith Alcock @.***> wrote:
I did see this come in yesterday. It shouldn't take long to figure out. Probably a duplicate file was added to an updated library dependency and needs to be filtered. It will hopefully be taken care of by Monday.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/clulab/eidos/issues/1098#issuecomment-980789814, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI75TRPTYTCRMOADR7OIMLUOEXBHANCNFSM5I3U5HHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
This is being addressed with #1099, which is being tested right now.
The tests passed, so I merged the branch and will close this. The tests don't try to run assembly, but it was working on the local computer. What wasn't tested at all was the result of the assembly. I hope @bgyori will report any problems with that, whether related to this issue or anything else that has happened since last time.
Thanks a lot, I'm trying it now! This has happened a few times in the past (#1098, #823, #794, #694), I wonder if - despite it being a resource intensive and somewhat slow task - it would be possible to test this (i.e., sbt assembly
) automatically so that we can see if there are issues with it. What do you think?
Maybe there's some subset of assembly that can be more quickly tested that includes the merging but not actually the slow building of the final jar. I'll see if there is an obvious way to do that.
The complete assembly just took 25 minutes on my computer (in power saving mode but with an SSD that the server doesn't have), so I don't think it's an option. I don't see any easy way to run only part of the assembly. The messages about merge strategies being applied appears fairly quickly, but I don't see an easy way to stop processing there. I could perhaps fork the assembly plugin and have it stop early or maybe use some script that runs sbt assembly and observes the log for a short while before killing the process. It's not obvious what to do.
We will probably be publishing eidos to maven more often soon. One could then have a completely different project that uses the published artifact and runs assembly from there. This would not work on just any master branch of eidos unless perhaps one published it locally. Otherwise, it is like using an older version of eidos.
I haven't tried doing this for a while but I found that there are issues with
sbt assembly
again on the latest master:I tried deleting various caches but keep getting the same.