incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Date Fri, 05 May 2017 10:25:20 GMT
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 <sospartan@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 <ptgoetz@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 <ptgoetz@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 <niclas@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.clr@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 <niclas@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
> > >>> clr@apache.org http://db.apache.org/jdo
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >>> For additional commands, e-mail: general-help@incubator.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Niclas Hedhman, Software Developer
> > >> http://polygene.apache.org - New Energy for Java
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> sospartan
> Phone:13588488290
> HangZhou
>

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