-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How is this plugin supposed to be used together with sbtOsgi #37
Comments
Can you share the project you're running this on? Are you using I haven't looked closely yet, but indeed perhaps the 2 plugins now side-step each other. |
We do something very similar in our build setup (https://github.com/woq-blended/blended/blob/1bb60a4c18c49e11bb61b9fc5f8f1bfcde43711c/project/BlendedBundle.scala#L70):
Maybe you can give an idea, how we should incorporate the reproducibleBuild step? The project is located at https://github.com/woq-blended/blended, in branch |
It looks like Your replacement So sbt-reproducible-builds post-processes the 'normal' |
Thanks for your answer. Unfortunately, I can't get the desired behaviour after following your advice to reload rb project settings after As the rb plugin has no explicit task key with which I can trigger the processing/creating of the stripped package, I find it very hard to experiment further. I'm currently looking for the presence of the |
Is this issue still current? How are you testing this? I just tried this branch and at first glance it seems blended-launcher_2.12.jar is correctly stripped (no |
Thanks for checking! Which branch/commit did you check ( As we've finished our migration to sbt, |
I tried How did you check for reproducibility after running But after running
From the filenames, it looks like those should all be stripped, except for Does that give you something to go on? |
Wow, I somehow missed that In summary, to integrate with sbtOsgi, one must re-apply the reproducible build settings after osgi settings. Some more thoughts: It would be great to have somewhat more info in the README about this, though. There was no information where the built artifact will be located, and also that the installed artifact in not the same as the one under So I suggest, to do at least one of the following
With the latter, everyone can easily depend on the stripped JAR, without any knowledge about your plugin. E.g. without it, I'n not exactly sure how to depend on the stripped JAR instead of the default JAR in the universal:packageBin task in same sub project |
Added #40 for the explicit intermediary task for producing the stripped |
Thanks for validating the solution appears to work for you, and the additional suggestions! I agree it would be good if users could use this plugin without having to learn about how it works internally too much. Actually overriding Because of this approach, AFAICS Of course this abstraction breaks down a bit when other plugins override |
I have a project that produces OSGi bundles with the sbtOsgi plugin. After adding the reproducibleBuildPlugin as described in the README, the produced packages still looks the same and e.g. contain non-reproducible manifest entries.
The text was updated successfully, but these errors were encountered: