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