On 02/25/2016 03:50 PM, Erik Joelsson wrote:
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.
Hello! Thank you for reply!
And thanx for link, I was not expecting somebody is already on it:)
Both zip api and gzip api are part of java, so most tool can be expected to work both with tar.gz
and zip however... Sometimes the tools are expecting javadocs in jar - so having the docs tar.gzed
is killing this.
Most troubeling case may be my beloved netbeans. I'm sure (tried few seconds ago) that they are not
able to add tar.gz-ed javadoc.
Because of NB and because of jar~=zip I would rather go with zip as default. But if gzip have
somehow better compression, then go with gzip, and force tools (like NB) to allow to use it.
Was there some special reason why you had chosen gzip over zip?
Thanx!
J.
/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.
