[Nerps!] MapTool Fork based on 1.4.1.x

[Cederien]

I wouldn't rule it out, I only checked https://wiki.debian.org/Java/ which claims it's not on Wheezy, but while that page was edited recently the Debian Wiki isn't always up to date or free from errors.

[Cederien]

32 bit.

Avast did pop out, but it said it was just scanning something (a thing I had never seen before, with an animated icon of a parser going through a sheet full of binary code) and didn't give me warnings nor told me anything about menaces or quarantine.

Hmm don't have a 32 bit Windows to test with, except for a VERY venerable XP Virtual Machine, couldn't get it to run on that for sure (launcher works... sort of, but just closes without MT ever starting), not really proofing or disproving anything I'm afraid.

[JamzTheMan]

Cool beans. re the data folders, are you talking about the .maptool folder? Don't bother with that one, it gets created by MT on first launch. Really, you just need to package the two jar files and related icons for launcher/MT. And FYI, although I have a icon for "MapTool" they currently both call the Launcher JAR, just with a -skip_prompt parameter so you pick up at least some parameters for MT.

Now he tells me, after I've completed packaging everything. Hmpf, ok I will remove those parts again...

But sorry, you telling me you hardcoded the .maptool folder, ignoring the MAPTOOL_DATADIR set in the mt.cfg? For what reason?
As for calling the launcher, I could do that, but it's not really necessary as both are called from a script that gives the full arg line to MT anyway.

Anyway I've a working debian package and I should be able to write a script that pulls all necessary files from a clean install for future builds.

Another question, given that maptool 1.4.0.0 runs quite well with Java-7 is there a reason your fork requires Java-8? You won't be able to install the .deb I made on your wheezy install for example, as it lists Java-8 (either openjdk or oracle) as dependencies and wheezy does not offer any of those through the regular repositories, AFAIK at least. Would be much better if Java-7 would suffice as long as only the Nerdiness factor suffers from that at least.

Wait, what? I think there's confusion... I didn't hard code MAPTOOL_DATADIR, the launcher will use whatever you set it to, but there are "defaults". To be clear, I have done nothing with how the Launcher or MapTool jars setup/use/handle the datadir. MapTool has always been like this, I thought it was general knowledge (as packaged as a JAR, MT has always had to handle creating .maptool on first launch) so sorry if there was confusion. I'm sure a few responses were after being up 20+ hours.

Regarding Java 8, yes. For one, to get ahead of the game for once. We always have to limit our development to the lowest Java JRE. Java 8 give us new options and if we can package the JRE, then why not?

Regarding Wheezy, I DO have it installed, I don't recall from where. And to be honest, it may be worth packaging the JRE with the .deb? The packaging follows all of Oracle's guidelines for redistribution, although I don't know if that violates debian protocol? If the debian package installs 1.8, does it leave 1.7 installed? (I believe this is mostly a windows issue living with more than 1 JRE).

[Cederien]

Ah yes, misunderstood you then, sorry my fault.

Packaging a JRE is kinda defeating the purpose of the dependencies system. It also violates protocol, bloats the size of the installer as well as the install (potentially twice on multi-user systems) and if you plan to eventually have MT included in official repositories instead of just hosting your own there is no chance of that with the Oracle engine packaged. There is a reason you don't find the Oracle JRE's in the official repos of the big distros. The licensing terms do not permit it.
Finally a lot of Linux folks will not want Oracles proprietary stuff on their system (after being done with the the testing and making sure OpenJDK-8 worked fine, the Oracle engine was the first thing to go). People don't trust Oracle for a reason, the permanently listening JRE's a while ago just being one of them.
And yes if you install a newer JRE, the old is not removed automatically. Actually on Ubuntu based systems (and lots of others) the default JRE isn't changed. So even if you have 6, 7 and 8 installed and 7 is default all Java programs will be called with the Java-7 JRE. Unless of course you manually change the default, manually select a different engine for just this program call or if the program was installed via a package listing Java-8 as dependency.

Well if you use Java-8 features fine, but just requiring Java-8 because you may (or may not) use Java-8 features in the future is simply doing it just for the Nerd-Factor. It's common among us Nerds, but still bad practice. There is nothing keeping you from bundling Java-8 already, yet still keeping the Program itself Java-7 compatible until you actually start using Java-8 features. It's simply good practice to do so. (Who knows if you will ever use any Java-8 specific functionality? While I understand the jump Java-6 to Java-7 was kinda substantial I also heard Java-8 wasn't exactly a quantum leap from Java-7. I admit I'm not following Java developments to closely though, unlike Python or PHP changes they do not usually affect me directly.)

Anyway if you got Java-8 on your wheezy, did the Debian package install fine for you? It should, but I only checked it on Ubuntu systems so far, so I'm curious.

[JamzTheMan]

No issues, I can be long winded sometimes so my posts tend to suffer from TL;DR lol

Regarding distribution, not to nit pick, but the license does allow for redistribution under certain terms. http://www.oracle.com/technetwork/java/ ... 37594.html

However, I'm not packaging it for a ZOMG IT MUST USE THIS JRE OR I OWN YOUR BASES! It's just a convenience package and targeted more for Windows users. Just take a look at the number of forum posts that deal with MT not running because or 32 vs 64 bit installations, or no JRE, or corrupted JRE or Oracle autoupdated my JRE to xyz and broke MT. I have 3 friends alone at my table that couldn't run MT. I would fix it, it would run for 2-3 weeks then break. I just gave up. Now, not an issue.

With all that said, I really don't have a problem with just using dependencies for the debian build. (I would prefer it myself as a end user). It accomplishes the same thing (that is harder to do on windows) and that is just to make sure Java 1.x is available and will be used. And I see no reason keeping the dependency at version 1.7. It'll be obvious when MT breaks and NEEDS 1.8 and the debian package could be updated easily enough to require 1.8 at that time.

I only have Debian because I run OpenMediaVault on a fileserver (with about 24tb of storage, woot!). But I REALLY do like how apt-get/update works and how it keeps my system updated. And to that, I don't recall having to add any special repositories for Java 1.8 so I believe it was a straight up install (it was last year so um...). But since then I know it's updated normally 4-5 times without issue with all the other updates.

I believe, at least for testing, I can host the .deb package, you would just need to add my server to your repository for testing, right? I'm backlogged currently with tasks but it's something I'll look into. Hopefully this is a "gradle makes it a snap" thing and not a "omg gradle stop being a #!#@#"

[Jagged]

Packaging a JRE is kinda defeating the purpose of the dependencies system.

I sort of understand your position, I have to deal with these issues at work. However for most of our users having to install Java is a significant issue. Then there is the fact that Java 7 reached end of life in April 2015. So including the Java 8 run time into a single file is a must.

For the advanced user the option of just downloading the jars will still be an option, I think.

[JamzTheMan]

Yep, there is no reason the Jar's won't be available. And on that sight, slightly easier as they will be single jars, one for the Launcher and one for MT...unless I combine those...hmmm

mt.cfg will have a new home under user/home, ie .maptool so that it persists across installations and should be there anyway.

[Full Bleed]

mt.cfg will have a new home under user/home, ie .maptool so that it persists across installations and should be there anyway.

I've created separate bat files with different data directories for different games to preserve different memory configs and layouts. That, of course, means that I don't even use the MT launcher (or mt.cfg file). Will the proposed move of the cfg file impact that in any way? I.e. will any configuration data (other than the cfg file) be moved to a default user directory?

[Jagged]

I will leave Jamz to answer that "officially" but what I have seen so far suggests he is adding to the launch options, rather than taking away.

[Cederien]

Packaging a JRE is kinda defeating the purpose of the dependencies system.

I sort of understand your position, I have to deal with these issues at work. However for most of our users having to install Java is a significant issue. Then there is the fact that Java 7 reached end of life in April 2015. So including the Java 8 run time into a single file is a must.

For the advanced user the option of just downloading the jars will still be an option, I think.

Well I assume you talking about Windows here, because installing Java with a Debian package that calls for it consists of clicking 'yes' if the installer asks you if you wish to install those other required packages (i.e. the java engine from the repositories). If you refuse... you are simply aborting the install then. OpenJDK7 is still getting security patches btw.
At any rate the script for creating Deb packages I sent James is requiring Java 8 currently (either Oracle or OpenJDK). If Wheezie got it, then among the big Distros it it's probably just Ubuntu 14.04 LTS and possibly CentOS (didn't check in a while, but then CentOS is using RPM instead of Deb anyway) still lacking Java8 in the standard repos. Ubuntu got a new LTS (with Java8) just 3 days ago, so the problem should be limited, even if 14.04 will still receive updates for at least another year.

Just the jars works, sort of, but is kinda uncomfortable.

The main problem with packaging a JRE is that you are 100% responsible for keeping it current. Bundled JRE's do not currently check for updates themselves (unlike full Oracle Java installs). So you have to watch for security updates and issue a new version of MT in a timely manner every single time a security patch for Java comes out. (And probably need to have MT check for updates.) Especially since you are not just using it in a closed environment, you are using it with an application that is likely to make a connection to the net, hence exposing itself. Hence a vulnerable JRE is comparably risky to use with MT.

[JamzTheMan]

mt.cfg will have a new home under user/home, ie .maptool so that it persists across installations and should be there anyway.

I've created separate bat files with different data directories for different games to preserve different memory configs and layouts. That, of course, means that I don't even use the MT launcher (or mt.cfg file). Will the proposed move of the cfg file impact that in any way? I.e. will any configuration data (other than the cfg file) be moved to a default user directory?

It's moved to the "data directory" so if pass a different "data directory" it will use that. You should be able to do this today even using the Launcher as you can set data directory via mt.cfg. Although I suppose you can't pass a mt.cfg today so mmmm...

Perhaps I should add parameter do pass a -config=some_mt_config.cfg file and then you can use whatever you want. I could probably even have the launcher create new "icon" for a given config... Although you should be able to do this manually as well.


@Cederien regarding packaging JRE's. For a lot of users, the benefits outway the negatives. Sure, we would have to maintain it/upgrade it when needed BUT that also means we control when that happens. We''ve experienced even a minor .xx update has broken something. So this lets us fix that before upgrading to 1.x.yy. Even "Flavors" may or may not break things. I just had to remove a com.sun package from TokenTool because it was JRE specific and it was causing issues.

Again, power users can just use the JAR files. And even if they don't, the launcher lets you choose a different JRE. If it becomes an issue, the launcher COULD delete the installed JRE possibly.

Packaging JRE's is NOT uncommon. JavaFX 8 even supports this now as part of the JavaFX deployment process (which may be a future alternative to jWrapper).

[Cederien]

Yep I know it's not uncommon to pack JRE's and I agree it's convenient. I also found it's common that they are not kept current. Extreme case: I did downloaded the Java backend for a cloud backup service about a month ago and when I checked it came with V1.7.0_21 ... needless to say I counted that as an example how well they maintain their stuff and accordingly decided against using their services.

[Full Bleed]

Especially since you are not just using it in a closed environment, you are using it with an application that is likely to make a connection to the net, hence exposing itself. Hence a vulnerable JRE is comparably risky to use with MT.

I was under the impression that "Self Contained Application" packaging of a JRE with an app was limiting the JRE to be used with that app.

[Cederien]

I was under the impression that "Self Contained Application" packaging of a JRE with an app was limiting the JRE to be used with that app.

Yes and no, usually it's only the program that brings the JRE that uses it (as other programs normally don't scan for or know the path to the bundled JRE). There is no inbuilt mechanism to prevent other programs from finding, accessing and using the JRE however.

[JamzTheMan]

One could also say, blindly updating or auto updating your JRE to the latest can also introduce security flaws

But yes, I get your point. And like we said, for the security minded/cautious, the JAR's will be provided. And of course, for the Ultra-security minded, the source code is posted on Git-Hub and you are welcome to look it over, download it, build it, and deploy it however you wish.

For those who want to put a little trust in others and save time, they can use the various packaging methods we'll provide.