Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Samcfuchs
Copy link

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.

@JaciBrunning
Copy link
Member

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

@Samcfuchs
Copy link
Author

So, what is the issue then is what? I'm not sure I understand what the complaint is.

@JaciBrunning
Copy link
Member

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.

@Samcfuchs
Copy link
Author

Yes - I'm saying that those files shouldn't be tracked by git.

@JaciBrunning
Copy link
Member

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/

@Samcfuchs
Copy link
Author

But do you want to commit those files every time you update to a new version of a module?

@JaciBrunning
Copy link
Member

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

@Samcfuchs
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants