_Windows
Club 4000 Member
Posts: 7,881
| Likes: 9,611
|
Post by _Windows on Dec 29, 2019 15:13:21 GMT
This is more of a suggestion for devs than anything else, but certain issues can be prevented simply by having any plugins compiled with the same version of JDK. JDK 8 would IMO be the ideal version to use for the server (it runs on this version). As for getting it you either need an Oracle account, or use the Netbeans installer (it comes with JDK 8).
|
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Dec 29, 2019 15:18:51 GMT
Why would people mix and match versions anyway?
Also it might be worth looking at the 11 upgrade sooner rather than later, I started looking into it about 6 months ago for the main TFM build as 8 was going EOL fairly soon and 11 IIRC was the next LTS release.
But yeah, we should only ever be compiling in the single JDK Version, and generally that should match what you need it to run on...
|
|
_Windows
Club 4000 Member
Posts: 7,881
| Likes: 9,611
|
Post by _Windows on Dec 29, 2019 16:24:14 GMT
Why would people mix and match versions anyway? Also it might be worth looking at the 11 upgrade sooner rather than later, I started looking into it about 6 months ago for the main TFM build as 8 was going EOL fairly soon and 11 IIRC was the next LTS release. But yeah, we should only ever be compiling in the single JDK Version, and generally that should match what you need it to run on... It has happened or I would not have made this thread. The problem is that when multiple people are doing the compiling, they may have different versions installed. Agreeing on a set JDK version would eliminate the binary compatibility issues that can arise. Before the plugins can be compiled for anything above 8, the server needs to be upgraded to a new Java version.
|
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Dec 29, 2019 20:35:48 GMT
Why would people mix and match versions anyway? Also it might be worth looking at the 11 upgrade sooner rather than later, I started looking into it about 6 months ago for the main TFM build as 8 was going EOL fairly soon and 11 IIRC was the next LTS release. But yeah, we should only ever be compiling in the single JDK Version, and generally that should match what you need it to run on... It has happened or I would not have made this thread. The problem is that when multiple people are doing the compiling, they may have different versions installed. Agreeing on a set JDK version would eliminate the binary compatibility issues that can arise. Before the plugins can be compiled for anything above 8, the server needs to be upgraded to a new Java version. Yes, Sorry I had assumed it was an issue or you wouldn't have posted, I just am not understanding how it happens. Generally if you're using an IDE as part of those project settings it sets the JDK Required, Ie Netbeans certainly always did, and IntelliJ I'm fairly sure also does. I think given the server is on 8 at the moment it does certainly make sense to build everything on 8, I'm just unsure how this even started to be an issue unless the IDE you're now all using doesn't have the same project level settings Netbeans seemed to have which enforced the Java version unless you manually went out of your way to change it? Other sensible thing to do would be to use something like TravisCI like we do on the main TFM repo to actually drive the builds, that way every "Production Ready" build has been properly built on a known piece of infrastructure and not just someones local PC.
|
|
|
Post by Polaris Seltzeris on Dec 30, 2019 1:16:47 GMT
It has happened or I would not have made this thread. The problem is that when multiple people are doing the compiling, they may have different versions installed. Agreeing on a set JDK version would eliminate the binary compatibility issues that can arise. Before the plugins can be compiled for anything above 8, the server needs to be upgraded to a new Java version. Other sensible thing to do would be to use something like TravisCI like we do on the main TFM repo to actually drive the builds, that way every "Production Ready" build has been properly built on a known piece of infrastructure and not just someones local PC. Yes, an actual production system as opposed to people bashing together binaries on their computer and FTPing it into a server like monkeys.
|
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 30, 2019 2:22:57 GMT
Other sensible thing to do would be to use something like TravisCI like we do on the main TFM repo to actually drive the builds, that way every "Production Ready" build has been properly built on a known piece of infrastructure and not just someones local PC. Yes, an actual production system as opposed to people bashing together binaries on their computer and FTPing it into a server like monkeys. GitHub Actions/TravisCI does exist, it's just that it's not configured to release builds. I set it up to well, see myself and other's commits actually build. (and pull requests too if we have any)
|
|
|
Post by Polaris Seltzeris on Dec 30, 2019 2:24:42 GMT
Yes, an actual production system as opposed to people bashing together binaries on their computer and FTPing it into a server like monkeys. GitHub Actions/TravisCI does exist, it's just that it's not configured to release builds. I set it up to well, see myself and other's commits actually build. (and pull requests too if we have any) Having a workflow on GitHub is good, but you should have a production/deployment system for the server itself.
|
|
super
Veteran Member
Among Us
Posts: 1,282
|
Post by super on Dec 30, 2019 2:35:36 GMT
Yes, an actual production system as opposed to people bashing together binaries on their computer and FTPing it into a server like monkeys. GitHub Actions/TravisCI does exist, it's just that it's not configured to release builds. I set it up to well, see myself and other's commits actually build. (and pull requests too if we have any) lmao you can see all the broken aero commits
|
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 30, 2019 2:48:37 GMT
GitHub Actions/TravisCI does exist, it's just that it's not configured to release builds. I set it up to well, see myself and other's commits actually build. (and pull requests too if we have any) Having a workflow on GitHub is good, but you should have a production/deployment system for the server itself. basically jenkins you're saying?
|
|
|
Post by Polaris Seltzeris on Dec 30, 2019 3:45:09 GMT
Having a workflow on GitHub is good, but you should have a production/deployment system for the server itself. basically jenkins you're saying? Not necessarily referring to any particular utility. I'm just saying that there *should* be a system set up for production so that we don't have to worry about the stupidest of issues like this thread and file transfer problems. Jenkins is a tool that in our case could be used to generate builds, but we don't need Jenkins because we have Travis/GitHub. For production/deployment, you would be interested in different tools like Docker and Puppet which would be used to automatically configure and deploy the server without needing some monkey to manually build jars on their Windows Server 2003 machine and bust out FileZilla to upload jars and manually edit a bunch of configuration and shit. Since we have GitHub/Travis, you can use Docker/Puppet to pull consistent, automated builds from there then configure & deploy the server.
|
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 30, 2019 3:46:12 GMT
basically jenkins you're saying? Not necessarily referring to any particular utility. I'm just saying that there *should* be a system set up for production so that we don't have to worry about the stupidest of issues like this thread and file transfer problems. Jenkins is a tool that in our case could be used to generate builds, but we don't need Jenkins because we have Travis/GitHub. For production/deployment, you would be interested in different tools like Docker and Puppet which would be used to automatically configure and deploy the server without needing some monkey to manually build jars on their Windows Server 2003 machine and bust out FileZilla to upload jars and manually edit a bunch of configuration and shit. Since we have GitHub/Travis, you can use Docker/Puppet to pull consistent, automated builds from there then configure & deploy the server. i'm pretty new to using docker, but i'll try to see what i can do in order to make it work
|
|
|
Post by Polaris Seltzeris on Dec 30, 2019 3:51:31 GMT
Not necessarily referring to any particular utility. I'm just saying that there *should* be a system set up for production so that we don't have to worry about the stupidest of issues like this thread and file transfer problems. Jenkins is a tool that in our case could be used to generate builds, but we don't need Jenkins because we have Travis/GitHub. For production/deployment, you would be interested in different tools like Docker and Puppet which would be used to automatically configure and deploy the server without needing some monkey to manually build jars on their Windows Server 2003 machine and bust out FileZilla to upload jars and manually edit a bunch of configuration and shit. Since we have GitHub/Travis, you can use Docker/Puppet to pull consistent, automated builds from there then configure & deploy the server. i'm pretty new to using docker, but i'll try to see what i can do in order to make it work Docker would provide a container containing the Minecraft server as an application, but you would want to use something like Puppet (I think Wild1145 knows some other tools which are targeted for Minecraft) which configures that container so that it has all of the necessary crap for automatically deploying the full server. This type of system is also useful with a server control panel, which I know we have, they go hand-in-hand and you can use a web control panel to configure the server you want to deploy (or you can have it just be completely automatic and update the entire server upon a new GitHub release or master branch update), or configure a web control panel to use to manage the container/server. This type of stuff is useful to learn not only to improve the server but also useful later on if you want to work a job which utilizes a production/deployment system, which are many.
|
|
Fleek
Veteran Member
Posts: 3,548
|
Post by Fleek on Dec 30, 2019 5:11:43 GMT
i'm pretty new to using docker, but i'll try to see what i can do in order to make it work Docker would provide a container containing the Minecraft server as an application, but you would want to use something like Puppet (I think Wild1145 knows some other tools which are targeted for Minecraft) which configures that container so that it has all of the necessary crap for automatically deploying the full server. This type of system is also useful with a server control panel, which I know we have, they go hand-in-hand and you can use a web control panel to configure the server you want to deploy (or you can have it just be completely automatic and update the entire server upon a new GitHub release or master branch update), or configure a web control panel to use to manage the container/server. This type of stuff is useful to learn not only to improve the server but also useful later on if you want to work a job which utilizes a production/deployment system, which are many. Sorry if I’m not understanding you correctly but Travis CI can build the jar and upload it to the server if you configure it.
|
|
|
Post by Polaris Seltzeris on Dec 30, 2019 5:24:06 GMT
Docker would provide a container containing the Minecraft server as an application, but you would want to use something like Puppet (I think Wild1145 knows some other tools which are targeted for Minecraft) which configures that container so that it has all of the necessary crap for automatically deploying the full server. This type of system is also useful with a server control panel, which I know we have, they go hand-in-hand and you can use a web control panel to configure the server you want to deploy (or you can have it just be completely automatic and update the entire server upon a new GitHub release or master branch update), or configure a web control panel to use to manage the container/server. This type of stuff is useful to learn not only to improve the server but also useful later on if you want to work a job which utilizes a production/deployment system, which are many. Sorry if I’m not understanding you correctly but Travis CI can build the jar and upload it to the server if you configure it. I'm not referring to just building the jar and uploading it, I'm referring to an actual deployment/production system, in which uploading the jar is just one simple part of it. Some people use Travis CI with their Puppet modules and that works, but the point of additionally using Puppet/Docker is that you configure the entire server and deploy it in a container automatically.
|
|
Fleek
Veteran Member
Posts: 3,548
|
Post by Fleek on Dec 30, 2019 5:44:39 GMT
Sorry if I’m not understanding you correctly but Travis CI can build the jar and upload it to the server if you configure it. I'm not referring to just building the jar and uploading it, I'm referring to an actual deployment/production system, in which uploading the jar is just one simple part of it. Some people use Travis CI with their Puppet modules and that works, but the point of additionally using Puppet/Docker is that you configure the entire server and deploy it in a container automatically. Ah okay.
|
|