The change is not that insignificant (and depends a bit on the archive type)

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist.zip 09-Oct-2017 03:32 30M

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist-max.zip 09-Oct-2017 03:32 45M

(50% more)

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist.tar.gz 09-Oct-2017 03:32 23M

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist-max.tar.gz 09-Oct-2017 03:32 37M

60% more

The biggest denominators:

• documentation (in 8.0.0 with missing Admin Guide) it's : 47MB of which DevGuide is 3MB and javadocs are whooping 44MB! (we could skip javadocs in basic -dist archive)

• jars/ 21,5M vs 37M (which doesn't compress much more), and the biggests:

  • groovy-all - 7MB - do we need -all version? In theory we could use @groovy-jsr223@? %andrzej.wojcik ?

  • tigase-web-ui - 3,3MB - not sure if we need it in the basic dist package (installer and admin UI are in different packages)

  • derby driver (3,2M) and derby-tools (230K) -- I think we could drop derbytools altogether, driver - we probably want to keep (if we are to switch to hsqldb [vide #5381] then it's jdbc driver is only 1,5M).

Comments:

• I would drop javadocs (at least from -dist package);

• I would investigate whether we need groovy-all and use lighter groovy dependency.

addendum - Admin_Guide is about 10M but as it's text it should compress well

Wojciech Kapcia wrote:

The change is not that insignificant (and depends a bit on the archive type)

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist.zip 09-Oct-2017 03:32 30M

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist-max.zip 09-Oct-2017 03:32 45M

(50% more)

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist.tar.gz 09-Oct-2017 03:32 23M

[ ] tigase-issue #8.0.0-SNAPSHOT-b5023-dist-max.tar.gz 09-Oct-2017 03:32 37M

60% more

The biggest denominators:

• documentation (in 8.0.0 with missing Admin Guide) it's : 47MB of which DevGuide is 3MB and javadocs are whooping 44MB! (we could skip javadocs in basic -dist archive)

• jars/ 21,5M vs 37M (which doesn't compress much more), and the biggests:

** groovy-all - 7MB - do we need -all version? In theory we could use @groovy-jsr223@? %andrzej.wojcik ?

** tigase-web-ui - 3,3MB - not sure if we need it in the basic dist package (installer and admin UI are in different packages)

** derby driver (3,2M) and derby-tools (230K) -- I think we could drop derbytools altogether, driver - we probably want to keep (if we are to switch to hsqldb [vide #5381] then it's jdbc driver is only 1,5M).

Comments:

• I would drop javadocs (at least from -dist package);

Yes, I think javadoc should not be included in either of the packages. It should be a separate package.

• I would investigate whether we need groovy-all and use lighter groovy dependency.

Yes.

• I also think the tigase-web-ui should go to dist-max only.

However, it is still not clear to me what is the exact difference in content between dist and dist-max.

If we can get the disk package down to less than 10MB, then I think it makes sense to maintain it, otherwise I would consider dropping it. Or maybe we should start thinking of it right away. What is purpose of the dist and what is purpose of dist-max package? Who uses dist and who dist-max? Looking at the download stats, it seems there is significantly higher interest in dist-max than it is in dist package. However, this might be result of lack of information of what is the difference and people downloading the 'max' just in case to have everything that may need.

I guess the jar and exe are dist-max too?

Artur Hefczyc wrote:

Yes, I think javadoc should not be included in either of the packages. It should be a separate package.

It's already packaged as @tigase-server-*-javadoc.jar@. However I think that majority of people using it pulls it from maven via their IDE (it's also published on docs.tigase.org)

However, it is still not clear to me what is the exact difference in content between dist and dist-max.

I think that in the beginning you wanted to have in dist really basic server installation: tigase-server + utils + xmltools (and db drivers and I think MUC and PubSub) and then dist-max would have -extras (with monitoring for example), socks5 (with it's dependencies) and other components that used additional dependencies.

Currently the distinction is still noticeable (66 binaries vs 12, and before web-installer it was 66 binaries vs 8).

If we can get the disk package down to less than 10MB, then I think it makes sense to maintain it, otherwise I would consider dropping it.

I think shrinking it to 10MB could be tricky (groovy itself takes 7MB).

Or maybe we should start thinking of it right away. What is purpose of the dist and what is purpose of dist-max package? Who uses dist and who dist-max? Looking at the download stats, it seems there is significantly higher interest in dist-max than it is in dist package. However, this might be result of lack of information of what is the difference and people downloading the 'max' just in case to have everything that may need.

I guess the jar and exe are dist-max too?

jar/exe are the IzPack (which we dropped and nightlies for 8.0.0 don't contain it anymore (vide http://build.tigase.org/nightlies/dists/2017-10-13/) but yes - they contained everything because at one step you were presented with selection of the functionality/packages that you want in your installation.

As for the dist and dist-max -- I'm usually getting dist-max because the different is not that significant and then I don't have to deal with something missing (even though I usually need http-api/muc/pubsub and... JMX).

I think that if we wanted to maintain two packages then we should make "installable" packages for all components not included in dist but included in dist-max so it would be possible to "install them" (by extracting over tigase-server directory). Simple binary won't work in all cases as we extracted the schema in some components so it requires additional files to be included -- we include it in the jar file as resource and it's extracted while preparing the server package but SchemaLoader uses only extracted files).

Thank you for your comments. This just convinces me more and more that we should drop dist packages. I no longer see an advantages of having the dist package.

In the past, when Tigase package was around 1MB and compared to Openfire which was around 300MB and both offered more or less the same XMPP functionality and Tigase, additionally offered clustering, presenting the size difference gave a good impression.

We could still make a good impression if we had a dist package which offers all the standard XMPP capabilities with clustering in a package of less than 10MB in size. What we must include in the dist?

1. + Tigase XMPP Server binary

2. + MUC

3. + PubSub

4. ACS clustering

5. +/- Groovy - not necessarily groovy-all if it is not required

6. +/- Database drivers (but maybe even without Derby) or maybe just for MySQL and PostgreSQL

7. - Documentation is not really that important as it is available online on doc.tigase.org. We could make a separate package with all documentation

8. - tigase-web-ui - I do not think it needs to be there

I think such a dist package would be useful to, acrtually anybody wanting to run more or less standard XMPP service. But, more importantly we could still show that the Tigase offers complete XMPP server software with clustering in a package so small.

Final result:

-rw-r--r--   1 wojtek  staff    44M Nov 23 19:37 tigase-issue #8.0.0-SNAPSHOT-b5075-dist-max.tar.gz
-rw-r--r--   1 wojtek  staff    52M Nov 23 19:36 tigase-issue #8.0.0-SNAPSHOT-b5075-dist-max.zip
-rw-r--r--   1 wojtek  staff    11M Nov 23 19:36 tigase-issue #8.0.0-SNAPSHOT-b5075-dist.tar.gz
-rw-r--r--   1 wojtek  staff    12M Nov 23 19:36 tigase-issue #8.0.0-SNAPSHOT-b5075-dist.zip
-rw-r--r--   1 wojtek  staff   6.6M Nov 23 19:35 tigase-issue #8.0.0-SNAPSHOT-b5075-javadoc.jar

I've removed:

• tigase-web-ui

• documentation

• derby driver and tool

• jTDS (MS SQL server open source driver)

• openDMK:jdmkrt (AFAIR this is used for SNMP; JMX works just fine without it)

It seems to be working, Web installer works (though, we could/should calculate list of available databases dynamically as currently all are present and Derby is default -- %andrzej.wojcik - comments)

(web installer crashed, but it's most likely due to authentication changes)

What do you think? it's not less than 10MB but it's not significantly higher (and it's way smaller than before)

I have hardcoded list of all supported databases. We can make it dynamic list by checking if particular DB drivers are available.

I have hardcoded list of all supported databases. We can make it dynamic list by checking if particular DB drivers are available.

I thought as much, but let's Artur decide.

Ok, the size of dist packages is close enough to 10MB. In such a case I think it is worth keeping both kinds of packages.

Please work on the dynamic DB list for the installer.

Artur Hefczyc wrote:

Ok, the size of dist packages is close enough to 10MB. In such a case I think it is worth keeping both kinds of packages.

I've pushed updated assembly configuration.

Please work on the dynamic DB list for the installer.

Andrzej, please adjust the installer as per your previous comment.

I've added code checking if database driver is available.

In case of :

1. web-based setup

It will make impossible to select drivers which are not available (option will be disabled).

1. SchemaManager

It will present all options but after selection of a database which driver is missing it will report that driver is missing. This will allow anyone who wants to add missing driver manually.

I decided not to remove options for which drivers are missing as it could make a bad impression. We would advertise support for some database on our pages and this support will be missing in the setup utilities. Instead, I mark them as unavailable if drivers are missing to make user/admin aware that option is possible to use but the driver is missing.

Thank you, works ok.