Elaine Byrne wrote:I feel I still don’t have a clue whether what I currently have on the site after pushing my NetBeans project includes irrelevant items or does not include necessary items, or both (probably the latter).
Here's a simple guideline:
You should commit everything that is needed to build or document your project, except stuff that can be gotten from other repositories. Don't commit more than that. In particular, binaries that result from your build should not be committed.
Of course, it's not as cut and dry as that, but that's the basic principle. Here are some caveats:
Dependencies in general should not be committed. However, if it's difficult to get a specific version of a dependency (or you don't trust the dependency to be publicly available consistently) then you can commit it to your repository.IDE-specific project files are usually separated into general project configuration and user-specific configuration files. Commit general project configuration. Don't commit user-specific configuration.Don't commit environment-specific configuration files, especially not if they contain sensitive data such as passwords, private keys or tokens.
On my simple website (linked from my account profile), I offer the NotAgain program for anyone who wants to run it in a zipped folder containing three items: binary JARs for NotAgain and the external JNativeHook library (a ‘dependency’?)
GitHub offers the possibility to add releases to your repository. These are separate from your source code commits. That way you have a centralized place for people to download different versions of the build result of your application, which might be just a zip with binaries or it might be an installer or whatever else you want.
it uses, plus a text file “WordleSolutions” which it also needs (also called a dependency, or not?)
This is called a "resource". Any static file that your application needs at runtime that is not compiled code (such as images, scripts, configuration, data) is typically called an application resource. Resources should be committed to your repository.
and to push the changes to GitHub if I feel I’m producing something follows basic expectations for the site.
The point of Git is not only that your source code is versioned, but also that it is stored in a decentralized manner, so that when your development system goes up in flames, you still have a backup of the source code. Nobody expects a GitHub repo to be perfectly curated. Development is messy.
A Git mantra that you might have heard before is "commit early, commit often". Well, that also applies to pushing commits. Use development branches to push whatever you want, and then you can always curate your commit history later when you merge to a release branch.
So maybe the simplest thing would be to just have NotAgain.java and WordleSolutions.txt present and add a link to the JNativeHook.jar in my README file? I get the impression that uploading the actual binaries for external libraries (dependencies) is not good form. Then, for moment forget about the option to generate a ‘release’...I assume this would require encoding the link to the dependency in a way that a build tool (e.g. Maven) would produce, but this seems to be a whole other level of complexity that seems inappropriate for my very small/simple programs(?)
Honestly, I think a Maven POM IS the easiest way you can set up a repository. That way anybody who clones your repo has everything they need to build and run it, and for small projects Maven POMs can also be really simple.