Provide zipped javadoc archive from make

[Erik Joelsson]

Hello Jiri,

Adding a build target for creating bundles of all our images, including 
docs, is currently on my todo here:

https://bugs.openjdk.java.net/browse/JDK-8136777

I believe our intention there is use tar.gz bundles for the most part. I 
would assume your usecase would require zip? This is certainly something 
to take into consideration if that's the case.

/Erik

On 2016-02-25 03:24, Jiri Vanek wrote:
> Hello!
>
> Firs, sorry for spamming three lists but imho it is really touching 
> all of them - it will be change in makefile, and it is new feature for 
> old docs....
>
>
> Currently, when you run make all, javadoc is generated as directory. I 
> do not wont to touch this. However, I would like to add target, which 
> will pack generated javadoc... Lets say correctly to zip archive.
>
> Having javadoc as directory have its advantages, but having javadoc as 
> archive have another set of advantages. (eg main user of javadoc are 
> IDEs. and all IDEs I know support archived javadocs. All library 
> javadocs distributed over  web are distributed as zips, and they are 
> not expected to be unpacked. Many tools crate archved javadocs by 
> default and so on...)
>
> I'm packaging openjdk for fedora, and next to 
> java-1.X.0-openjdk-javadoc, and I wonted to provide 
> java-1.X.0-openjdk-javadoc-zip so users have an choice to select 
> zipped/unzipped javadoc depending on theirs usage. You may argue that 
> size do not meter, but having four (6,7,8,9) jdks on machine, and so 
> having 4 javadocs - it metres if it is 4x250mb or 4x50mb.
>
> Also, when I was preparing this simple patch to my packages, I 
> realised - am I compressing all? Am I compressing it correctly and in 
> best way? Is delivering of *JDK's* javadoc as archive even safe?
>
> So I would say that having this supported in upstream is much better 
> then just pack zip it in distribution packages.
>
> What do you think?
>
> If you are interested, I will elaborate patch for jdk9 with wish for 
> jdk8. Change should be simple, and the benefits worthy.
>
> Thanx!
>  J.