I'll remove whole playground sample app from artifacts innext release. So #7 would be a problem anymore. As the gradle wrapper will be removed too. I'll suggest use installed gradle to create that. These will be put in new "how to build from source" doc in root folder. Pierre Smits <pierre.sm...@gmail.com>于2017年5月5日 周五下午6:32写道：
> I forgot to address in my conclusion aspect #7 (classes.jar). > > This seems to be quite the issue, as I could not find a license associated > with it when I did the cursory review. Nor could I find in the proposal > anything more than a single reference. My question(s): > > - where does this originate from, and what is the license? > - was this intended to be part of the Weex solution? And If so, does the > ASF have an SGA for this? > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Fri, May 5, 2017 at 12:25 PM, Pierre Smits <pierre.sm...@gmail.com> > wrote: > > > Hi All, > > > > To understand part of the problem correctly, in currently proposed > release > > there are many compiled components (jar files)that aren't allowed to be > > included.... > > > clr% find . -name "*.jar" > > > > 1. > ./android/playground/gradle/wrapper/gradle-wrapper.jar > > 2. > ./android/sdk/gradle/wrapper/gradle-wrapper.jar > > 3. > ./android/sdk/license/license-gradle-plugin-0.12.1.jar > > 4. > ./android/sdk/license/maven-license-plugin-1.10.b1.jar > > 5. > ./android/sdk/license/plexus-utils-3.0.24.jar > > 6. > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar > > 7. > ./android/weex_debug/libs/classes.jar > > 8. > ./scripts/apache-rat-0.12.jar > > > > > > So lets break this down: > > > > Re 1 & 2 and 6 : gradle-wrapper.jar > > This is an 3rd party solution provided by the Gradle > > community/organisation build through the 'gradle wrapper' task. Licensed > > under AL2.0. This can be included in the source repo, however it can NOT > > (per current conventions) be included in source releases. But it can be > > included in convenience downloads based on source releases; > > > > Re 3: license-gradle-plugin-0.12.1.jar > > This is apparently a 3rd party solution available through e.g. > > mvnrepository.com. Licensed under AL2.0. This can be included in the > > source repo, however it can NOT (per current conventions) be included in > > source releases. But it can be included in convenience downloads based on > > source releases; > > > > Re 4. maven-license-plugin-1.10.b1.jar > > This is apparently a 3rd party solution available through e.g. > > mvnrepository.com. Licensed under AL2.0. This can be included in the > > source repo, however it can NOT (per current conventions) be included in > > source releases. But it can be included in convenience downloads based on > > source releases; > > > > Re 5: plexus-utils-3.0.24.jar > > This is apparently a 3rd party solution available through e.g. > > mvnrepository.com. Licensed under AL2.0. This can be included in the > > source repo, however it can NOT (per current conventions) be included in > > source releases. But it can be included in convenience downloads based on > > source releases; > > > > Re 7: classes.jar > > Cursory analysis of the jar shows that it stemming from com.taobao java > > code, used in [1] and referenced in the Weex proposal (see [2]). > > > > Re 8: apache-rat-0.12.jar > > This is an artefact produced by Apache Creadur project (see [3]). This > can > > be included in the source repo, and CAN be included in source releases > (as > > it is ASF own).And it can be included in convenience downloads based on > > source releases; > > > > [1] https://github.com/apache/incubator-weex/tree/master/ > > android/weex_debug/src/main/java/com/taobao/weex > > [2] https://wiki.apache.org/incubator/WeexProposal~) > > [3] http://creadur.apache.org/rat/ > > > > Conclusion(s): > > > > 1. Many of the 3rd party solutions (jar files) used in the Apache Weex > > product are available in artefact repos like mvnrepository.com, and > > need not be included in the code base, source releases and convenience > > downloads as they can be retrieved through the dependency mgt > solution used > > by the project (gradle in this case); > > 2. Convenience downloads (jar files) of ASF projects can be included > > when downloaded from ASF sources. However, if these are not available > > through ASF or 3rd party artefact repos ( e.g. mvnrepository.com) it > > is advised that the project contacts the (appropriate) ASF project > that > > delivers such solutions and have them included in these artefact > repos. The > > project can then have such retrieved through the depency mgt solution > used > > by the project; > > 3. gradle-wrapper.jar is generated by executing a gradle task > > (./gradle wrapper), and is based on > > 1. the gradle version used (by the person having downloaded the > > source) > > 2. potential gradle configuration elements included in the > > project's source code (build.gradle, etc). > > > > No gradle-wrapper.jar artefact was found via mvnrepository.com. The > ideal > > situation (to resolve the major issue discussed in this thread) would be > if > > such convenience download would be made available through the various jar > > repos (e.g. mvnrepository). This should (preferably) be done by the > Gradle > > community/organisation. However, in the short term, the project could > > adjust the gradlew scripts in the codebase to have that invoke the > > download from the project's repo ((in ./gradlew for linux initiate e.g. > > wget), and in ./gradlew.bat initiate an equivalent)) > > > > > > I trust the above helps to clear the air. > > > > Best regards, > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Fri, May 5, 2017 at 3:57 AM, sospartan <sospar...@gmail.com> wrote: > > > >> Taylor, > >> Can you point out which objections you are agreed exactly? > >> > >> > >> > >> On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <ptgo...@gmail.com> > >> wrote: > >> > >> > Apologies for the auto correct. > >> > > >> > Please sub "Niclas" for "Nicolas". > >> > > >> > -Taylor > >> > > >> > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <ptgo...@gmail.com> > >> wrote: > >> > > > >> > > Nicolas, > >> > > > >> > > I understand and appreciate your passion, but would respectfully ask > >> > that you step down your tone a little bit. Craig and John have both > >> taken > >> > time to review the release candidate (which you should be appreciative > >> of > >> > -- getting IPMC members to review a release can be difficult). In my > >> > opinion their reviews bring up some valid points that need to be > >> considered. > >> > > > >> > > Weex, by its nature, has a complicated codebase with respect to > >> > licensing and building from source. It is a far cry from a java > project > >> > with a Pom and a a "src" directory. It pulls in a lot of different > code > >> > that needs to be considered and evaluated. Going forward the (P)PMC > will > >> > need to understand that and as a TLP will need to be able to address > >> issues > >> > accordingly. > >> > > > >> > > What may seem like "Incubator hazing" right now, I would argue, is > an > >> > exercise in making sure the podling has what it takes to operate as a > >> fully > >> > functional TLP. No two podlings are the same, and some face certain > >> burdens > >> > that others do not. > >> > > > >> > > For now can we try to turn the thread toward a more constructive > path > >> > that benefits both the podling and the Incubator? > >> > > > >> > > For what it's worth, I agree with some (not all) of the objections > >> that > >> > have been raised. So I would be a -1 as well. > >> > > > >> > > -Taylor > >> > > > >> > > > >> > > > >> > >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <nic...@hedhman.org> > >> wrote: > >> > >> > >> > >> Sorry, but if you don't know the background on that file, then > >> perhaps > >> > you > >> > >> think I am "not civil"... The fact is that NOTICE file doesn't > >> require > >> > any > >> > >> inclusion of what the project depends on, since they are not > bundled, > >> > but > >> > >> will be downloaded during build. In a previous round, we were told > to > >> > take > >> > >> it out of NOTICE for that reason (not bundled) and I argued that we > >> > should > >> > >> keep it in to make it more reasonable for downstreams to get an > idea > >> of > >> > >> what a binary distro will actually contain. This file was the > >> > compromise of > >> > >> providing such details to downstream. > >> > >> > >> > >> Now you say, "Uhhh, it is unclear..." when in reality it would be > >> even > >> > more > >> > >> unclear if we left it out, as some people on this very list pushed > >> for > >> > on a > >> > >> previous RC. > >> > >> > >> > >> So, yes, I get pissed off as well. The incubator over time is > getting > >> > more > >> > >> and more intolerant at podling's first release, and I think it is > the > >> > wrong > >> > >> way to go. It is disheartening... truly... > >> > >> > >> > >> > >> > >> Niclas > >> > >> > >> > >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell < > apache....@gmail.com > >> > > >> > wrote: > >> > >>> > >> > >>> I'm going to call foul on this one. > >> > >>> > >> > >>> If you cannot be civil, then leave the discussion to others. > >> > >>> > >> > >>> Craig > >> > >>> > >> > >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <nic...@hedhman.org> > >> > wrote: > >> > >>>> > >> > >>>> BUT ALSO figuring out what to start looking for. For fak sake, > >> > >>>> man.... Get a grip on reality! > >> > >>> > >> > >>> Craig L Russell > >> > >>> Secretary, Apache Software Foundation > >> > >>> c...@apache.org http://db.apache.org/jdo > >> > >>> > >> > >>> > >> > >>> ------------------------------------------------------------ > >> --------- > >> > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> > >>> For additional commands, e-mail: > general-h...@incubator.apache.org > >> > >>> > >> > >>> > >> > >> > >> > >> > >> > >> -- > >> > >> Niclas Hedhman, Software Developer > >> > >> http://polygene.apache.org - New Energy for Java > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> > For additional commands, e-mail: general-h...@incubator.apache.org > >> > > >> > > >> > >> > >> -- > >> sospartan > >> Phone:13588488290 > >> HangZhou > >> > > > > > -- sospartan Phone:13588488290 HangZhou
