Re: Windows distribution format

[Chris H.]

Max brought up an interesting idea via a pm and I felt that this should be discussed by our group of devs.
 

Hi Chris,

There's a problem many people have with Forge.
viewtopic.php?f=26&t=10060

I think many users have faced a similar one. Most of them have no dedicated archive-processing program installed and get stuck with the strange archive.

How can I help you to deliver all windows distributions in a good old zip format? I also think that *nix users are more experienced and they will be able to unpack a .zip archive as well.

 
I responded:
 

Good question.

We have a small section in the changes.txt file and the announcement message which recommends the 7zip application. This appears to be a good choice for people who use the Windows OS.

We used to release forge initially as a zip when the archive was small sized.

We changed over to 7z when the archive size increased.

We went to the tar.bz2 in response to the java heap space problems that people were having. I created a Macintosh shell script that could be double clicked and it would launch the Widows/Unix version while increasing the java heap space.

I needed to use tar.bz2 because the other archive formats would not save the permissions that were necessary to make this shell script work on other people's Mac's when they extracted the forge archive.

Dave kept the tar.bz2 archive system as he set up our current Maven based build and deploy system.


Sorry about the lengthy response.

Changing over to zip might create or not create problems. I do not think that I have enough knowledge to change our current system.

[Max mtg]

Thank you Chris, for posting it here. So I'll proceed with a response.

It's great to have a section devoted to decompressing in changes.txt, especially when one has to decompress the archive first to read the file.
Announcement message is accessible, but I don't think that everyone reads them. It's certainly their own problem, but since a number of developers care so much about user experience, why not to give users a hand and use the archive type that is easier for them to deal with?

Personally I would never approve the idea of making the installation harder in favour of 0.6MB gain on archive size.
As my measurements have shown, the built and zipped svn snapshot is 29 267 121 bytes long, while today's snapshot forge-1.3.12-20130411.111349-14.tar.bz2 takes 28 661 064 bytes

Speaking of MACOS - looks like maven configuration options allow us to save that archive format for the named platform.

Please find below the patch-file for pom.xml, apply it and test if correct distibutives are built.

Code: Select all

mvn -U -B clean -P osx,windows-linux install

My run of this test has produced a windows-linux distributive but has failed when it came to macos build - the OS says it cannot run program "ln", and that's not a big surprise on a Windows system.

[Chris H.]

It's great to have a section devoted to decompressing in changes.txt, especially when one has to decompress the archive first to read the file.
Announcement message is accessible, but I don't think that everyone reads them. It's certainly their own problem,

 
I agree. We try to provide as much information as we can.

Some people do not speak or read English and they are unable to read our instructions. I wish them good luck as I am not fluent in any language other than English.

Some people might speak and read English but be too busy or in too much of a hurry. They will try to extract the archive and then play the game. Beyond that they do not have the free time or the interest needed to read our written instructions or to participate in the forums here at CCGH.

We devs do our best but there is only so much that we can do.

[Chris H.]

Speaking of MACOS - looks like maven configuration options allow us to save that archive format for the named platform.

Please find below the patch-file for pom.xml, apply it and test if correct distibutives are built.

Code: Select all

mvn -U -B clean -P osx,windows-linux install

My run of this test has produced a windows-linux distributive but has failed when it came to macos build - the OS says it cannot run program "ln", and that's not a big surprise on a Windows system.

 
I downloaded your patch and will test it soon.

Today might be a bad day and tomorrow we have the beta to release. I might have to wait until this weekend.

[myk]

I agree that building a .zip would probably be more familiar for windows users. It is a good point that .zip fails to preserve executable permissions, though, making the forge scripts unrunnable on mac and linux without manual changes. A lot of other projects distribute both .zip and .tar.bz2 for this reason. It would not be difficult to separate the windows build from the linux build in the pom to achieve this.

[Max mtg]

myk, macos distributive has a separate build script, that is to say tar format is preserved for that platform. Yet for linux systems the lack of attributes set up right from archive may be problematic.

Would you take care of this problem? I suspect you have more experience with maven build files and have a linux system at hand's reach to test the linux setup.

[Chris H.]

I agree that building a .zip would probably be more familiar for windows users. It is a good point that .zip fails to preserve executable permissions, though, making the forge scripts unrunnable on mac and linux without manual changes. A lot of other projects distribute both .zip and .tar.bz2 for this reason. It would not be difficult to separate the windows build from the linux build in the pom to achieve this.

 
With your recent work Myk the size of the archives has decreased substantially. Having separate Windows, MacOS and *nix archives should not create too much of a problem for our user base.

[myk]

macos distributive has a separate build script, that is to say tar format is preserved for that platform.

The OSX build profile produces a .dmg installation package, but OSX users can (and I suspect many do) still use the tarball distributable.

Having separate Windows, MacOS and *nix archives should not create too much of a problem for our user base.

Ok, I'll see if I can make that change. I'll update this thread (and the wiki) with the new build commands once I add the additional build profile. Give me a few days, though. I've been very busy recently, and this weekend looks no better : /

[Chris H.]

I downloaded your patch and will test it soon.

Today might be a bad day and tomorrow we have the beta to release. I might have to wait until this weekend.

 
I ran the test and discovered that Max's idea appears to work OK.

I first reverted my local copy to rev 20944 and I then applied Max's patch via an Eclipse command. I then built a local copy of both archives.

I extracted the forge-1.3.12-SNAPSHOT.zip archive and I can double click on the jar file and forge will launch but I expected that this would work as the memory footprint has decreased over the last year or so.

I also extracted the forge-1.3.12-SNAPSHOT-osx.tar.bz2 archive and then mounted the disk image and copied the Mac OS app package to my desktop. I was able to launch the forge package as a Mac OS app.

That said, I seem to remember a similar experience a couple of years ago -- that is, it would work for me as the release dev but other mac users were not able to use the launch forge .command shell script that I was providing in the archive.


As an additional test I zipped the extracted Mac OS X disk image and was able to extract and to then run the forge Mac OS package app. Does the disk image file contain and keep the permissions/attributes of the files that are included in the disk image?

While we are at it we might want to consider using zip to archive the Mac OS X disk image after it is created. This may ease the user experience for the non-tech Mac users.

I guess that using .tar.bz2 for the *nix distribution is required for the *nix shell script launcher but we can use .zip for the other two distributions.


An interesting test for our discussions but I think that we should go with the 3 separate archives as it will be the safest solution to this idea.