Commit
mostly copied from apache/datafu@0f9b853
- Loading branch information
There are no files selected for viewing
7 comments
on commit 500ff00
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it should be generated by git-archive
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nobody except us should even use this. Not everything that’s included in our build scripts needs to work for random people; lots of things in there are developer- or maintainer-only, they’re just not marked that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptual question:
If we want to provide the source code as an archive (which I do not hereby take a stance on whether this is something to spend our time on :)) then why not harness the fact that we're using Java and do it the Java way = put it into the Jar with the classes, or a separate source Jar?
E.g. https://stackoverflow.com/questions/11474729/how-to-build-sources-jar-with-gradle
That would actually perhaps have a real usecase for me already:
Previously with Ant both the Eclipse and the Ant builder had to be enabled in order to debug fred: Ant to produce the Jar to run, and the Eclipse builder to have Eclipse itself be able to see the classes. It wasn't able to consume the output of Ant.
Perhaps doing it the "source Jar" way would allow an upcoming Eclipse project configuration to only use the Gradle builder and completely disable the Eclipse one - which would speed up compiling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanting to not be tied to a specific SCM is desirable, but excluding the build directory (to a small extent at least because it makes sense if the intent is to run in a fresh clone after building the jar) seems at odds with its behavior otherwise to include everything such as giant Coverity input archives in my case.
I'm still okay with this approach, but wanted to note this limitation / gotcha.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think excluding other non-build relevant parts would be good, too — as long as the tarball builds. It took a few iterations to get this to work, so if you can give the paths to directories to exclude I think we should add them.
The fact that you gziped this means that providing a checksum is redundant - gzips contain a checksum. To validate:
gzip --test *gz && echo Checksum OK || echo Wrong checksum