I think so, I've no objection to someone reimplimenting it. Sent from my Samsung device. Include original message ---- Original message ---- From: Greg Trasuk <tras...@stratuscom.com> Sent: 12/02/2016 07:53:31 am To: dev@river.apache.org Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE build.xml
Is there anything other than org.apache.river.tool.classdepend.AbstractDependencyVisitor? I don’t like the idea of the River code being encumbered with INRIA’s license, so I wonder if we could simply re-implement that class. Cheers, Greg Trasuk > On Feb 11, 2016, at 4:20 PM, Peter <jini@zeus.netau> wrote: > > Yes thanks for fixing dep-libs. > > You may have misunderstood; River contains sources that are copyright of >INRIA, which are not AL2 licensed. > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Greg Trasuk <tras...@stratuscom.com> > Sent: 12/02/2016 05:36:04 am > To: d...@riverapache.org > Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE >buildxml > > > 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> 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> 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> >>> Sent: 11/02/2016 02:57:35 am >>> To: dev@river.apache.org >>> 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 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"/> >>>> >>>> >>> >>> >>> >> > >
