> 4. The javascript source files in playground/app/src are missing the
license header. They have a style that I do not recognize. Are these
generated files? The first several lines of storage-demo.js:
>
> /******/ (function(modules) { // webpackBootstrap
> /******/ // The module cache
> /******/ var installedModules = {};
>
> /******/ // The require function
> /******/ function __webpack_require__(moduleId) {
>
> /******/ // Check if module is in cache
> /******/ if(installedModules[moduleId])
> /******/ return installedModules[moduleId].exports;
All js files under 'ios/' or 'android/' is generated files, which can be
removed from source tarball.
On Thu, May 4, 2017 at 10:24 AM, Niclas Hedhman <nic...@hedhman.org> wrote:
> On Thu, May 4, 2017 at 9:22 AM, Craig Russell <apache....@gmail.com>
> wrote:
> > clr% find . -name "*.jar"
> > ./android/playground/gradle/wrapper/gradle-wrapper.jar
> > ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> > ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> > ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> > ./android/sdk/license/plexus-utils-3.0.24.jar
> > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> > ./android/weex_debug/libs/classes.jar
> > ./scripts/apache-rat-0.12.jar
>
> > 1. These jar files are not source and must not appear in the source
> release.
>
> These are convenience for building the system. Those who are overly
> concerned and don't trust Apache project members, are free to build using
> tools downloaded by themselves. I have argued that this will be changed to
> a "only source code" approach in the future, but should not hinder a
> release now.
>
> > 2. I appreciate the effort involved in compiling the
> POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am
> troubled by the difficulty actually finding the licenses of the projects.
> >
> > For example, the "possible notice" for animaitonjs (possible typo here)
> refers to https://www.npmjs.com/package/animationjs from which it is
> impossible (ok, perhaps possible but I could not find a link) to find the
> actual project.
> >
> > References to npmjs in this entire file should be removed and replaced by
> references to the home of the project. (Not relevant for this release
> because the files are not actually being distributed.)
>
> And YET, the argument is that this file SHOULD NOT BE INCLUDED AT ALL, so
> that downstream packagers have to not only worry about what you are listing
> above, BUT ALSO figuring out what to start looking for. For fak sake,
> man.... Get a grip on reality!
>
> > 3. The java source files in android/commons/src are still in the
> com.alibaba name space. Assuming that these are actually weex source files,
> they must be repackaged to org.apache.
>
> YES, that is on purpose to avoid breaking compatibility with hundreds of
> people using Weex in their projects right now. org.apache.weex namespace is
> slated for a later release when compatibility is sacrificed.
>
> > 4. The javascript source files in playground/app/src are missing the
> license header. They have a style that I do not recognize. Are these
> generated files? The first several lines of storage-demo.js:
> >
> > /******/ (function(modules) { // webpackBootstrap
> > /******/ // The module cache
> > /******/ var installedModules = {};
> >
> > /******/ // The require function
> > /******/ function __webpack_require__(moduleId) {
> >
> > /******/ // Check if module is in cache
> > /******/ if(installedModules[moduleId])
> > /******/ return installedModules[moduleId].
> exports;
>
> I don't know about this one.
>
> > 5. The java files in playground/app/src/main/java_zxing are in the
> com.google name space. They have a google license header.
>
> I have missed that one. But it is bundled source code from elsewhere, and
> should be mentioned in top-level NOTICE, not only the localized one.
>
> Before you complain about the NOTICE and LICENSE in playground, that is due
> to the intent that the playground/ is expected to be copied elsewhere as a
> sample project that uses the Weex SDK. Hence its location there.
>
> > 6. The packages/weex-html5 contains LICENSE and NOTICE files. These
> should be in the top level directory of the release.
>
> This one is less than clear cut. The content in packages/ will be uploaded
> to npm registry, and the files in the directory will be moved there. There
> is relatively little information (compared to Maven Central uploads) how
> that is to be handled, since the content that is uploaded need to be part
> of a source release.
>
> > 7. The scripts/rh contains LICENSE and NOTICE files. These should be in
> the top level directory of the release.
>
> The scripts/ directory is mistakenly included in the dist.
>
> > 8. There is an executable file that doesn't belong:
> >
> > clr% ls -l start
> > -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
>
> What's the problem with "executable file"? It is a shell script, and since
> when are we not allowed to ship that?
>
> Granted; lacking license header, but that is not your complaint.
>
> > 9. There is an executable gradlew in sdk/gradle that doesn't belong in a
> source release.
>
> Port of your point 1, and gradlew is another shell script. ARE YOU SAYING
> that shell scripts are not allowed in source distros?
>
> > 10. There are shared objects in sdk/libs that don't belong in a source
> release.
>
> Alright, this is a issue that I am not convinced either way. I agree that
> "doesn't belong", but on the other hand, the steps to set up (and get
> working) the Android Native Development Kit (not talking about the Android
> SDK) is substantial. By allowing these built binaries, we can avoid that
> for most users, who normally never touch the NDK. By demanding that these
> binaries are taken out, then you just condemned this project to produce a
> Binary Release as well, which was not planned for this release.
>
> > 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
> executable files.
> > clr% ls -l ios/sdk
> > total 40
> > -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
> > -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
>
> An honest mistake, and shouldn't stop a release.
>
> > 12. The README.md doesn't tell me how to build/use org.apache.weex. The
> first several lines refer to third-party projects from Alibaba and
> cocoapods. How do I use the Apache project?
>
> Well, you just introduced more complexity in "using the project" with your
> insistence on no binaries, and more so if your "no execute flag" is also
> now not allowed. AFAIK, there is no obligation that the source distribution
> must contain all details needed to build the project, only that it can be
> built. But for you convenience;
>
> 1. Install Gradle and learn how to use it.
> 2. Install Maven and learn how to use it.
> 3. Install Android NDK and learn how to use it.
> 4. Install Android SDK and learn how to use it.
> 5. Install Xcode and learn how to use it.
> 6. Install IOS SDK and learn how to use it.
> 7. Build each part with the tool needed.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
sospartan
Phone:13588488290
HangZhou
