RFR: JDK-8238534

[Erik Joelsson]

Hello René,

It's good to see an open solution to this, but I have some opinions on 
the patch.

The concept of building into "temp dirs" that are then removed is a 
practice we try to avoid in the build. Whenever possible, each rule 
should be a well defined transformation from a set of source files to a 
target file. There is just no reason to remove the jdk-signed dir here. 
If something goes wrong, you would want the dir around to investigate. 
This also keeps incremental builds working as expected. Your current 
patch will always rebuild the bundles, which is not ok.

I would recommend putting the jdk-signed dir in 
$(IMAGES_OUTPUTDIR)/jdk-signed and just leave it there. I would create a 
separate rule for the signing part, where the target file is the 
CodeResources file that codesign actually creates, and the prerequisite 
files simply $(COPY_SIGNED_JDK_BUNDLE).

Separate rules for creating a top level directory are not needed. The 
rules generated from SetupCopyFiles will create all directories needed.

I would also keep using the existing SetupBundleFile for the actual 
bundling, even if most of the functionality in it is not used, just to 
avoid more separate code paths than necessary.

/Erik

On 2020-02-07 02:05, René Schünemann wrote:
> For the Apple notarization process, the whole bundle in its final form
> has to be signed with the codesign tool.
> See the discussion here: https://bugs.openjdk.java.net/browse/JDK-8238225
>
> This change copies all JDK/JRE files to a temporary directory, which
> is then passed to the codesign tool. The temporary directory is then
> used as the base directory for the bundle archive and is getting
> removed after the archive has been created. This only applies when a
> valid code signing identity is set and the build type is release.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238534
> WebRev: http://cr.openjdk.java.net/~rschuenemann/wr/2020/8238534-macos_sign_bundles/01/
>
> Rene