incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Date Thu, 04 May 2017 02:24:47 GMT
On Thu, May 4, 2017 at 9:22 AM, Craig Russell <> 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

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 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 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 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

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 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.

Niclas Hedhman, Software Developer - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message