[
https://issues.apache.org/jira/browse/STORM-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008912#comment-15008912
]
P. Taylor Goetz commented on STORM-1213:
----------------------------------------
A compiled binary is by definition not open source, and is very different from
an image file (which doesn't require compilation). This is why the RAT (Release
Audit Tool) will flag binaries, but not fail the build -- RAT can't distinguish
between an image file and a compiled binary.
See http://incubator.apache.org/guides/releasemanagement.html#check-list :
"Release consists of source code only, no binaries." ... "This package may not
contain compiled components (such as "jar" files) because compiled components
are not open source, even if they were built from open source."
also http://www.apache.org/dev/release.html#what-must-every-release-contain :
"It is also necessary for the PMC to ensure that the source package is
sufficient to build any binary artifacts associated with the release."
This should be as second nature to us as checking for Apache license headers in
new source files.
And I don't _want to break windows_. I want to be able to create a release that
complies with ASF policy, which we can't if we include those binaries. As I
mentioned in the original description, this is an interim solution (not ideal)
that allows us to release. I hope we can find a better way.
> Remove sigar binaries from source tree
> --------------------------------------
>
> Key: STORM-1213
> URL: https://issues.apache.org/jira/browse/STORM-1213
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.11.0
> Reporter: P. Taylor Goetz
> Assignee: P. Taylor Goetz
>
> In {{external/storm-metrics}} sigar native binaries were added to the source
> tree. Since Apache releases are source-only, these binaries can't be included
> in a release.
> My initial thought was just to exclude the binaries from the source
> distribution, but that would mean that distributions built from a source
> tarball would not match the convenience binaries from a release (the sigar
> native binaries would not be included.
> The solution I came up with was to leverage the fact that pre-built native
> binaries are included in the sigar maven distribution
> ({{sigar-x.x.x-native.jar}}) and use the maven dependency plugin to unpack
> them into place during the build, rather than check them into git. One
> benefit is that it will ensure the versions of the sigar jar and the native
> binaries match. Another is that mavens checksum/signature checking mechanism
> will also be applied.
> This isn't an ideal solution since the {{sigar-x.x.x-native.jar}} only
> includes binaries for linux, OSX, and solaris (notably missing windows DLLs),
> whereas the non-maven sigar download includes support for a wider range of
> OSes and architectures.
> I view this as an interim measure until we can find a better way to include
> the native binaries in the build process, rather than checking them into the
> source tree -- which would be a blocker for releasing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
