Binaries are useful. Publishing them to maven central is again useful. It definitely increases the uptake of a code base.
Bryan On Friday, February 12, 2016, Gregg Wonderly <ge...@cox.net> wrote: > I suppose that one of the details of shipping binaries is that it creates > “users” rather than “community members”. The interesting question from my > perspective, is what value, overall, is there in making that distinction. > That is, if you only provide source, then a “user” has to “build”, and if > they can build and have source, they can create diffs and participate in > the projects community by requesting their diffs become part of the > project. While that is an important part making a community function, I > think that there are people who literally will never make use of something > unless it’s already built for them. It comes down to how much time/money > do you have to spend on technology. > > I’d suggest that at least what it takes to build things is in a > “document”. Greg left behind those details in comments for now. It might > be good to request people to “ask” or “plead” for build artifacts on this > list if it seems valuable to know if that is actually a detriment to > community participation. > > Gregg > > > > On Feb 11, 2016, at 1:36 PM, Greg Trasuk <tras...@stratuscom.com > <javascript:;>> wrote: > > > > > > One more data point - > > > > - Many Apache projects do not ship binaries. Check out httpd.apache.org > and subversion.apache.org. Both say they do not officially endorse any > binaries (although they do point to committer-created binaries). > > > > Cheers, > > > > Greg Trasuk > > > >> On Feb 11, 2016, at 2:31 PM, Greg Trasuk <tras...@stratuscom.com > <javascript:;>> wrote: > >> > >> > >> A little while ago I asked a question - “Does it make sense to release > a binary package”? > >> > >> I don’t think we need to. Here are a few reasons: > >> > >> - Apache’s products are source distributions. Officially, if we build > a binary package, it’s a “convenience binary”, and not a released product. > i.e. Apache doesn’t really recognize a binary package, but will insist that > if we distribute a binary, the LICENSE and NOTICE files need to correctly > reflect the other libraries that are included in that binary. > >> - The build.xml has been modified so it uses Ivy to download the > build-time dependencies when you go to build. That saves us from having to > manage a “build-deps” library and distribute it separately. This means > that _we_ are not distributing those dependencies, so we don’t have to > reference them in the NOTICE and LICENSE files. Which is good, because it > doesn’t impose any requirements on downstream users of River who don’t use > ‘asm’. > >> (I asked about this on the list - you asked me to go ahead and fix > the issue with distributing jars in the source package). > >> > >> - ‘classdep’ is built as part of the build process. Prior to that, > ‘build.xml’ calls ‘Ivy’ to download ‘asm’. We don’t distribute ‘classdep’ > through Maven Central. We don’t even recommend using it, why would we > distribute it? > >> - As I explained before, the JTSK binary on its own doesn’t do > anything. You can’t run “reggie” out of it, for example (this is one > reason people find it so confusing to startup using Jini). All you can do > with the JTSK distribution is run the tests. If you run the integration > tests, it starts by recompiling, hence there’s no need for a binary to run > the integration tests. > >> - We _do_ ship the generated jar files as artifacts in Maven Central, > which is realistically how developers will be using the jar files. For > example, you can build the examples project without downloading or building > the main River distribution. Harvester gets its jars from Maven Central. > I’m pretty sure that Rio does too (not sure if Rio uses Maven or Gradle for > its build, but either one uses Maven Central as the artifact repo). The > pom files include the transitive dependency references. > >> > >> I left my question as “how about if I comment out the bits that make > the binary release, and if anyone wants it badly enough they can do the > work to build the binary properly”. That’s what I did. There’s a note > next to the commented-out part telling what work needs to be done. As it > stands now, the ‘release’ target does not generate a binary release > artifact, just the source and doc artifacts. As I’ve explained above, that > makes sense as far as I can tell. > >> > >> On a practical level, if you desperately want the binary release, > somebody who is not me has to do the work to generate it properly and then > manage the ‘3.0’ release. If we’re good to go without the binary artifact, > I’ll be happy to spin the ‘3.0’ release as soon as the vote on ‘2.2.3’ is > finished. > >> > >> Cheers, > >> > >> Greg Trasuk > >> > >>> On Feb 11, 2016, at 1:35 PM, Peter <j...@zeus.net.au <javascript:;>> > wrote: > >>> > >>> > >>> Greg, > >>> > >>> Please revert this. > >>> > >>> ASM licensed code exists in classdepend, which classdep uses, in the > tools package. > >>> > >>> As far as I'm aware were still releasing a binary for River 3, but > you've found an issue with how we currently do that? > >>> > >>> Regards, > >>> > >>> Peter. > >>> > >>> Sent from my Samsung device. > >>> > >>> Include original message > >>> ---- Original message ---- > >>> From: Greg Trasuk <tras...@stratuscom.com <javascript:;>> > >>> Sent: 11/02/2016 02:57:35 am > >>> To: dev@river.apache.org <javascript:;> > >>> Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE > NOTICE build.xml > >>> > >>> > >>> Just note - this change is on the trunk branch - anyone know if it’s > possible to change the commit message retroactively? > >>> > >>> Cheers, > >>> > >>> Greg > >>> > >>>> On Feb 10, 2016, at 11:55 AM, gtra...@apache.org <javascript:;> > wrote: > >>>> > >>>> Author: gtrasuk > >>>> Date: Wed Feb 10 16:55:24 2016 > >>>> New Revision: 1729654 > >>>> > >>>> URL: http://svn.apache.org/viewvc?rev=1729654&view=rev > >>>> Log: > >>>> The generated release artifacts for the 2.2 branch are now only the > source and documentation artifacts, and do not include the release tooling > like 'roll_release.sh'. Those files are only used by the release manager, > so shouldn't be in the source distribution. > >>>> > >>>> The LICENSE and NOTICE files also are no longer duplicated to > 'LICENSE.TXT' and 'NOTICE.txt', as per Apache release recommendations. > >>>> > >>>> LICENSE and NOTICE files have been modified to reflect the fact that > 'asm' and 'animal-sniffer' are no longer distributed with the source, but > are downloaded at build time. > >>>> > >>>> Modified: > >>>> river/jtsk/trunk/LICENSE > >>>> river/jtsk/trunk/NOTICE > >>>> river/jtsk/trunk/build.xml > >>>> > >>>> Modified: river/jtsk/trunk/LICENSE > >>>> URL: > http://svn.apache.org/viewvc/river/jtsk/trunk/LICENSE?rev=1729654&r1=1729653&r2=1729654&view=diff > >>>> > ============================================================================== > >>>> --- river/jtsk/trunk/LICENSE (original) > >>>> +++ river/jtsk/trunk/LICENSE Wed Feb 10 16:55:24 2016 > >>>> @@ -199,39 +199,3 @@ > >>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > >>>> See the License for the specific language governing permissions and > >>>> limitations under the License. > >>>> - > >>>> - > >>>> -APACHE RIVER SUBCOMPONENTS: > >>>> - > >>>> -Apache River includes some external software components. Your use of > these > >>>> -components is subject to the terms and conditions of the following > licenses: > >>>> - > >>>> -ASM libraries (tools/asm-5.0.1.jar and tools/asm-commons-5.0.1.jar) > >>>> - > >>>> - ASM: a very small and fast Java bytecode manipulation framework > >>>> - Copyright (c) 2000-20011 INRIA, France Telecom > >>>> - All rights reserved. > >>>> - > >>>> - Redistribution and use in source and binary forms, with or without > >>>> - modification, are permitted provided that the following conditions > >>>> - are met: > >>>> - 1. Redistributions of source code must retain the above copyright > >>>> - notice, this list of conditions and the following disclaimer. > >>>> - 2. Redistributions in binary form must reproduce the above > copyright > >>>> - notice, this list of conditions and the following disclaimer > in the > >>>> - documentation and/or other materials provided with the > distribution. > >>>> - 3. Neither the name of the copyright holders nor the names of its > >>>> - contributors may be used to endorse or promote products > derived from > >>>> - this software without specific prior written permission. > >>>> - > >>>> - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > CONTRIBUTORS "AS IS" > >>>> - AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED > TO, THE > >>>> - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A > PARTICULAR PURPOSE > >>>> - ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR > CONTRIBUTORS BE > >>>> - LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, > OR > >>>> - CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT > OF > >>>> - SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > BUSINESS > >>>> - INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > WHETHER IN > >>>> - CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR > OTHERWISE) > >>>> - ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF > ADVISED OF > >>>> - THE POSSIBILITY OF SUCH DAMAGE. > >>>> > >>>> Modified: river/jtsk/trunk/NOTICE > >>>> URL: > http://svn.apache.org/viewvc/river/jtsk/trunk/NOTICE?rev=1729654&r1=1729653&r2=1729654&view=diff > >>>> > ============================================================================== > >>>> --- river/jtsk/trunk/NOTICE (original) > >>>> +++ river/jtsk/trunk/NOTICE Wed Feb 10 16:55:24 2016 > >>>> @@ -23,11 +23,3 @@ The original two releases of the Service > >>>> and code, are available from: > >>>> > >>>> http://www.artima.com/jini/serviceui/index.html > >>>> - > >>>> -Copyright (c) 2000-2005 INRIA, France Telecom > >>>> -This product includes the ASM library (http://asm.ow2.org/) > >>>> - > >>>> -This product includes the animal-sniffer library from codehaus.org. > >>>> -The original software is available from > http://mojo.codehaus.org/animal-sniffer/ > >>>> -Licensed under the MIT license. > >>>> - > >>>> > >>>> Modified: river/jtsk/trunk/build.xml > >>>> URL: > http://svn.apache.org/viewvc/river/jtsk/trunk/build.xml?rev=1729654&r1=1729653&r2=1729654&view=diff > >>>> > ============================================================================== > >>>> --- river/jtsk/trunk/build.xml (original) > >>>> +++ river/jtsk/trunk/build.xml Wed Feb 10 16:55:24 2016 > >>>> @@ -87,7 +87,7 @@ > >>>> </target> > >>>> > >>>> <target name="release" description="Create source and binary > release packages" > >>>> - depends="clean, all.build, release-src, release-bin, > release-doc"> > >>>> + depends="clean, all.build, release-src, release-doc"> > >>>> </target> > >>>> > >>>> <fileset id="river.bin.files" dir="${basedir}"> > >>>> @@ -117,7 +117,13 @@ > >>>> <include name="README*"/> > >>>> </fileset>--> > >>>> > >>>> - <target name="release-bin" description="Create a binary release" > depends="all.build"> > >>>> + <!-- This target is unused - the distribution doesn't have > functionality on its > >>>> + own, so there's no point in having a binary distribution. If > someone wants to > >>>> + reactivate the binary distribution, they will also need to > create the appropriate > >>>> + license and notice files that cover the binaries (no other > products are > >>>> + distributed with the source distribution). > >>>> + --> > >>>> + <target name="unused-release-bin" description="Create a binary > release" depends="all.build"> > >>>> <!-- TODO: add depends: javadoc-internals and remove from > ci-build --> > >>>> > >>>> <mkdir dir="${dist.dir}"/> > >>>> @@ -149,6 +155,8 @@ > >>>> <exclude name="nbproject/**"/> > >>>> <exclude name="build.properties"/> > >>>> <exclude name="tar_release_test/**"/> > >>>> + <exclude name="roll_release.sh"/> > >>>> + <exclude name="release.xml"/> > >>>> <!-- > >>>> TODO: why were these excluded from the source archive? > >>>> <exclude name="${doc}/release-notes/new.html"/> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > -- ---- Bryan Thompson Chief Scientist & Founder Blazegraph e: br...@blazegraph.com w: http://blazegraph.com Blazegraph products help to solve the Graph Cache Thrash to achieve large scale processing for graph and predictive analytics. Blazegraph is the creator of the industry’s first GPU-accelerated high-performance database for large graphs, has been named as one of the “10 Companies and Technologies to Watch in 2016” <http://insideanalysis.com/2016/01/20535/>. Blazegraph Database <https://www.blazegraph.com/> is our ultra-high performance graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints APIs. Blazegraph GPU <https://www.blazegraph.com/product/gpu-accelerated/> andBlazegraph DAS <https://www.blazegraph.com/product/gpu-accelerated/>L are disruptive new technologies that use GPUs to enable extreme scaling that is thousands of times faster and 40 times more affordable than CPU-based solutions. CONFIDENTIALITY NOTICE: This email and its contents and attachments are for the sole use of the intended recipient(s) and are confidential or proprietary to SYSTAP, LLC DBA Blazegraph. Any unauthorized review, use, disclosure, dissemination or copying of this email or its contents or attachments is prohibited. If you have received this communication in error, please notify the sender by reply email and permanently delete all copies of the email and its contents and attachments.
