-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore module jar files for toast #3
base: master
Are you sure you want to change the base?
Conversation
Usually I would agree, however I can see this being an inconvenience. To avoid this problem, the module files should be added as a maven dependency or something of the like, however if this is implemented I can see a lot of build errors that people won't try to figure out |
So, what is the issue then is what? I'm not sure I understand what the complaint is. |
Do you mean with the repo as a whole? I'm mostly talking about codebases where the distribution jar built from the source contained in the same repo is included in the git repo, something that will change with every commit but it otherwise entirely dependent on other files inside of the codebase. |
Yes - I'm saying that those files shouldn't be tracked by git. |
The thing is, anything under modules/ or libs/ isn't a duplicate, compiled version of source code in the git tree. Files under those directories are usually release-level versions of libraries, like those provided by manufacturers. The files we're looking to ignore reside under build/libs, as their contents are directly related to anything under src/main/ |
But do you want to commit those files every time you update to a new version of a module? |
I'd put that up to the discretion of the module writer. Ideally, you should not be changing versions of a library commonly over the course of a season. Nevertheless, if this file were to be committed, it would prevent forks of the project from retaining an incorrect version of the library, causing potential issues |
I would think that if you were using any but the most recent version of a module, you'd indicate that in the README or in a text file in the modules folder. |
You don't want to commit these, but I like to put a text or markdown file in the folder to keep track of module versions and provide links to get them.