Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Build System Improvement - Part2 #3083
Conversation
|
build again |
| //**************** Lint *****************// | ||
|
|
||
| subprojects { | ||
| if (project.plugins.hasPlugin('com.android.application')) { |
gizemb
Nov 4, 2020
Contributor
what about library projects? storage, zmessaging, etc?
what about library projects? storage, zmessaging, etc?
mejdoo
Nov 8, 2020
•
Author
Contributor
lint was enabled only for the app module, if that makes sense we can enabled as well for the libraries.
lint was enabled only for the app module, if that makes sense we can enabled as well for the libraries.
gizemb
Nov 9, 2020
Contributor
hmm, ok. I saw that there is another configuration ready for library modules, but didn't know that it was disabled for them.
hmm, ok. I saw that there is another configuration ready for library modules, but didn't know that it was disabled for them.
| */ | ||
|
|
||
| //**************** Checkstyle *****************// | ||
|
|
gizemb
Nov 4, 2020
Contributor
I think we can break this thing down even more into their own files and add
apply from checkstyle
apply from pmd
...
here
I think we can break this thing down even more into their own files and add
apply from checkstyle
apply from pmd
...
here
mejdoo
Nov 4, 2020
•
Author
Contributor
I started by doing a single gradle file for each section in #3073 detekt.gradle and jacoco.gradle. Then, @BradleyWire suggested to do it in a single place quality.gadle. It's not a requirement but think it's better to follow the same approach of "reloaded".
I started by doing a single gradle file for each section in #3073 detekt.gradle and jacoco.gradle. Then, @BradleyWire suggested to do it in a single place quality.gadle. It's not a requirement but think it's better to follow the same approach of "reloaded".
BradleyIW
Nov 4, 2020
•
Contributor
Yes, we can still do a single quality.gradle file and apply that but the quality.gradle file can have its own scripts as described by Gizem above. Ideally we would only import quality.gradle for libraries or application projects
Yes, we can still do a single quality.gradle file and apply that but the quality.gradle file can have its own scripts as described by Gizem above. Ideally we would only import quality.gradle for libraries or application projects
android10
Nov 5, 2020
Member
I jump in here, because I was the one putting everything inside the quality file.
At the time being, the file is not big and perfectly understandable. Personally I found this the best way of organizing scripts by aspects. If we start creating these tiny scripts, we are loosing consistency, since there are aspects and technologies mixed up.
We have 2 options, either we put everything in one file as soon as the file does not grow until it turns into a God Script or we change our strategy and organization related to scripts.
If you feel like the second option, please drop your suggestions.
I jump in here, because I was the one putting everything inside the quality file.
At the time being, the file is not big and perfectly understandable. Personally I found this the best way of organizing scripts by aspects. If we start creating these tiny scripts, we are loosing consistency, since there are aspects and technologies mixed up.
We have 2 options, either we put everything in one file as soon as the file does not grow until it turns into a God Script or we change our strategy and organization related to scripts.
If you feel like the second option, please drop your suggestions.
| @@ -1,232 +0,0 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
gizemb
Nov 4, 2020
Contributor
what was the difference between this config and lint-config-with-unused.xml exactly?
what was the difference between this config and lint-config-with-unused.xml exactly?
|
|
| apply from: "./scripts/licensing.gradle" | ||
| apply from: "./scripts/customization.gradle" | ||
| apply from: "./scripts/whitelabel.gradle" |
android10
Nov 5, 2020
Member
👍
| subprojects { |
android10
Nov 5, 2020
Member
We have to be careful with this, because we do not want to get ownership over code taken from other projects. For Example there are some files that were taken from my project...I do not mind to be honest, but changing the author could bring even legal problems and as far as I understand, that will apply to all files right?
We have to be careful with this, because we do not want to get ownership over code taken from other projects. For Example there are some files that were taken from my project...I do not mind to be honest, but changing the author could bring even legal problems and as far as I understand, that will apply to all files right?
mejdoo
Nov 5, 2020
•
Author
Contributor
Good point, I totally agree with you opinion regarding copyright. This will apply to all files in the all the modules with the following extensions .java .scala, .gradle, .xml. .kt is missing btw. What do you suggest then? Should we ignore some specific files or disable completely the licensing plugin to stay in the safe side?
Good point, I totally agree with you opinion regarding copyright. This will apply to all files in the all the modules with the following extensions .java .scala, .gradle, .xml. .kt is missing btw. What do you suggest then? Should we ignore some specific files or disable completely the licensing plugin to stay in the safe side?
android10
Nov 5, 2020
Member
I would suggest a way to check whether this header exist first. If does not, then add it.
I do not know the plugin and I do it manually in my projects, actually the IDE does it for me within new files.
In any case, we have to be responsible if we are copying code from other projects. It is a commitment.
So just make sure we are taking any ownership from code that does not belong to us.
I would suggest a way to check whether this header exist first. If does not, then add it.
I do not know the plugin and I do it manually in my projects, actually the IDE does it for me within new files.
In any case, we have to be responsible if we are copying code from other projects. It is a commitment.
So just make sure we are taking any ownership from code that does not belong to us.
android10
Nov 5, 2020
Member
I guess we have to investigate a bit here, Unless someone else has experience on this topic.
cc @makingthematrix @gizemb @BradleyWire
I guess we have to investigate a bit here, Unless someone else has experience on this topic.
cc @makingthematrix @gizemb @BradleyWire
makingthematrix
Nov 5, 2020
Contributor
As far as I understand, every source code file should start with the header. If the code contains a snipped taken from elsewhere, that code should additionally be preceded by a comment about who is the author and where was it taken from. We should copy-paste whole files from other projects.
As far as I understand, every source code file should start with the header. If the code contains a snipped taken from elsewhere, that code should additionally be preceded by a comment about who is the author and where was it taken from. We should copy-paste whole files from other projects.
| */ | ||
|
|
||
| //**************** Checkstyle *****************// | ||
|
|
android10
Nov 5, 2020
Member
I jump in here, because I was the one putting everything inside the quality file.
At the time being, the file is not big and perfectly understandable. Personally I found this the best way of organizing scripts by aspects. If we start creating these tiny scripts, we are loosing consistency, since there are aspects and technologies mixed up.
We have 2 options, either we put everything in one file as soon as the file does not grow until it turns into a God Script or we change our strategy and organization related to scripts.
If you feel like the second option, please drop your suggestions.
I jump in here, because I was the one putting everything inside the quality file.
At the time being, the file is not big and perfectly understandable. Personally I found this the best way of organizing scripts by aspects. If we start creating these tiny scripts, we are loosing consistency, since there are aspects and technologies mixed up.
We have 2 options, either we put everything in one file as soon as the file does not grow until it turns into a God Script or we change our strategy and organization related to scripts.
If you feel like the second option, please drop your suggestions.
mejdoo
force-pushed the
feature/refactor_build_system_part_2
branch
from
52f577f
to
8469aa7
mejdoo
force-pushed the
feature/refactor_build_system_part_2
branch
from
2366f5d
to
4b4c713
What's new in this PR?
This is a follow up of #3073
Main improvements
quality.gradleand move all the configs below the root/configfolder