game_unpacker.dat is the name of the file when downloaded in the
.jagex_cache_32/runescape directory. However, the other files containing
code are all named after the files on the web/JAGGRAB server.
This commit uses unpackclass.pack for consistency with all the other
files.
Signed-off-by: Graham <gpe@openrs2.dev>
I'm very keen on being able to use the jdk.jartool module (which is only
available in JDK11 onwards) as it allows us to avoid shelling out to
jarsigner entirely.
11 is the current LTS release and is already widespread in Linux
distributions, so I think it's reasonable to require it.
This commit removes the jsobject module. We might need to re-add it in
the future (if jdk.jsobject is removed from the JDK). However, it was
only necessary in 8 because modern versions of 8 tended to be
distributed without plugin.jar. JDK11 is distributed with the
jdk.jsobject module.
Signed-off-by: Graham <gpe@openrs2.dev>
I've been considering this for a long time, and have decided to switch to it at
the last minute before opening the repository up publicly. My reasons include:
* It's a much simpler license. GPL's complexity adds some risk - for example, it
might be incompatible with future open-source licenses (like the well-known
GPLv2/Apache v2 incompatibility problem). The "or any later version" clause
requires placing some trust in the Free Software Foundation.
* The simplicity makes it easier for people to understand and comply with the
license.
* Dishonest users who disobey the GPL would have an advantage over honest users
who refuse to do so. The ISC license provides a much more even playing field.
* OpenRS2 will primarily be server software accessible over a network. As such,
the GPL can do little to prevent use of the code in a proprietary system, as
the code is never distributed. (While the AGPL would fix this, I have already
discounted it. Enforcement would be too difficult and dishonest users would
have an unfair advantage.)
* It's much easier to switch to a stricter license in future versions, if it
turns out that is desirable (as the ISC license allows users to sublicense
the code). However, switching from the GPL to the ISC license requires all
copyright holders to grant permission.
* Other open-source projects in the community, such as Apollo, use the ISC
license and will be able to make use of OpenRS2 code if they so desire.
I've removed the FAQ entry about the reasons for using the GPL license, as I
think the ISC license is less controversial and therefore does not require an
entry.
I've discussed this with Desetude, and he's okay with his commit being
relicensed.
I've been thinking about this for a while. On the one hand, using the
"or later" clause means we have to place some trust in the Free Software
Foundation. On the other hand, being able to adopt newer versions of the
license without having to contact all contributors is useful for
compatibility (e.g. Apache 2 and GPLv3).
I recently noticed that Section 14 states that new versions of the
license will be "similar in spirit" to the current version. I think this
reduces the amount of trust we need to place in the FSF, as I'd hope
that if a future license did diverge too much from the original spirit
that a court might not consider it valid.
Furthermore, if the FSF went totally crazy, there are many bigger and
more important projects who would experience the same problem.
This is the bare minimum required to build the client. Returning null in
getWindow() makes this class appropriate for use at runtime too, as the
function is documented as returning null if the application is not
connected to a browser.
It is an LTS release that will remain supported for a while. It is also
supported by Quasar 0.8.x, but JDK 13 is not (and JDK 12 will not be
supported for much longer).
This is for several reasons:
* It makes building the main OpenRS2 repository easier, as it no longer
requires a C compiler.
* Pre-built versions for all platforms will be available in the Maven
repository. Many versions might not have access to build environments
for all of the supported operating systems and architectures.
* The bundler module should be able to depend on the pre-built versions
in the Maven repository. The Maven reactor isn't quite clever enough
for this to work, especially when depending on .nar artifacts with a
different operating system or architecture.
