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 <j...@zeus.net.au> 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: dev@river.apache.org > Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE > build.xml > > > 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"/> >>>> >>>> >>> >>> >>> >> > >
