From odf-dev-return-440-apmail-incubator-odf-dev-archive=incubator.apache.org@incubator.apache.org Wed Dec 7 14:13:50 2011 Return-Path: X-Original-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5880A7356 for ; Wed, 7 Dec 2011 14:13:50 +0000 (UTC) Received: (qmail 20907 invoked by uid 500); 7 Dec 2011 14:13:50 -0000 Delivered-To: apmail-incubator-odf-dev-archive@incubator.apache.org Received: (qmail 20886 invoked by uid 500); 7 Dec 2011 14:13:50 -0000 Mailing-List: contact odf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: odf-dev@incubator.apache.org Delivered-To: mailing list odf-dev@incubator.apache.org Received: (qmail 20878 invoked by uid 99); 7 Dec 2011 14:13:50 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 14:13:50 +0000 Received: from localhost (HELO mail-vw0-f47.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 14:13:50 +0000 Received: by vbbfc21 with SMTP id fc21so402611vbb.6 for ; Wed, 07 Dec 2011 06:13:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.69.70 with SMTP id c6mr10788219vdu.65.1323267228913; Wed, 07 Dec 2011 06:13:48 -0800 (PST) Received: by 10.220.46.197 with HTTP; Wed, 7 Dec 2011 06:13:48 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Dec 2011 09:13:48 -0500 Message-ID: Subject: Re: RC2 binary package From: Rob Weir To: odf-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 7, 2011 at 4:13 AM, Devin Han wrote: > Thank you for point it out, Rob. When I deep into the jars which generate= d > by Maven, I notice the problem maybe easy to resolve. > Maven is really powerful, which have helped us do all of the 3 options. I= n > the following content, I will take > odfdom-java-0.8.8-incubating-rc2-jar-with-dependencies.jar and > odfdom-java-0.8.8-incubating-rc2.jar for example. > > 2011/12/7 Rob Weir > >> I looked some more at the binary package. =C2=A0We're currently includei= ng >> the base JARs of the Apache code, as well as the "with-dependencies" >> JARs that Maven generates. >> >> I think this interacts with the requirements for NOTICE.txt and >> LICENSE.txt. =C2=A0The with-dependencies JARs include the classes for al= l >> of our dependencies, and all of their dependencies, etc. =C2=A0So it is >> self-contained, except for system classes. =C2=A0But that makes us a >> distributor of these modules, and we would need to include all these >> licenses in our LICENSE.txt file, as well as any required notices in >> the NOTICE.txt file. >> > > Yes, we are the distributor of the modules. But, Maven centural repositor= y > should be the world biggest distributor, how can they do it? > The answer is: > > >> >> So, option 1 is to track down all of that information for the >> licenses. I think Devin has done it one-level deep. =C2=A0But I think we >> need to do this recursively and pull these licenses and notices into >> our own. =C2=A0Is that correct? >> > > Please open odfdom-java-0.8.8-incubating-rc2-jar-with-dependencies.jar wi= th > WinZIP. There is a directory called "license" which includes all of the > necessary licenses of the third party jars as long as they are contained = in > these jars when they were deliveried to Maven central repository. > But these are in separate license files in the JAR. What we need (I believe) is a single LICENSE.txt file that includes all of these. This is a benefit that Apache projects have for our developers. We make it easy for them to understand what license requirements they need to follow when they use our releases. We do this by aggregating all of the licenses together into one file, and all of the notices together in another file. > For odfdom-java-0.8.8-incubating-rc2.jar, you also can find the LICENSE > file in \META-INF\. If any other project has dependence on ODFDOM and bui= lt > by Maven, this file will copied automatically to its "with-dependencies" > jar. > > The issue is some of the third partys' jars don't contain LICENSE files > when deliveried... It also difficult for us to find these license files i= n > manual.. Right. With this approach, we rely on all of the dependencies clearly marking their license in a consistent way. > My question is whether it is enough for us to contain these licenses whic= h > listed in "license" =C2=A0directory? > I am not absolutely certain, but I think this is not enough. Maybe Nick or Yegor has some good advice? > If yes, the issue is resolved. If not, let's go to Option 2 ;) > > >> >> Option 2 would be to not ship the "with-dependencies" JARs. =C2=A0Just s= hip >> our own core JARs and list the third party dependencies in our release >> notes, perhaps with URL's and version pre-req's. >> > > We can do it in manual. But I think Maven has done it to us. See: > odfdom-java-0.8.8-incubating-rc2.jar\META-INF\ , there is a file called > DEPENDENCES. Its content is: > > // ------------------------------------------------------------------ > // Transitive dependencies of this project determined from the > // maven pom organized by organization. > // ------------------------------------------------------------------ > > ODFDOM > > From: 'Apache Software Foundation' (http://www.apache.org/) > =C2=A0- XML Commons External Components XML APIs ( > http://xml.apache.org/commons/components/external/) > xml-apis:xml-apis:jar:1.3.04 > =C2=A0 =C2=A0License: The Apache Software License, Version 2.0 =C2=A0( > http://www.apache.org/licenses/LICENSE-2.0.txt) > > From: 'The Apache Software Foundation' (http://www.apache.org/) > =C2=A0- ODF Custom Javadoc Taglets ( > http://incubator.apache.org/odftoolkit/odfdom/index.html) > org.apache.odftoolkit:taglets:jar:0.8.8-incubating-rc2 > =C2=A0 =C2=A0License: Apache 2 =C2=A0(http://www.apache.org/licenses/LICE= NSE-2.0.txt) > =C2=A0- Xerces2 Java Parser (http://xerces.apache.org/xerces2-j) > xerces:xercesImpl:jar:2.9.1 > =C2=A0 =C2=A0License: The Apache Software License, Version 2.0 =C2=A0( > http://www.apache.org/licenses/LICENSE-2.0.txt) > > > All of the detail information, such as, jar name, =C2=A0version, license = and > even homepage link are included. > OK. This is more useful and detailed than what we have now in CHANGES.txt. Would it make sense to put this info into CHANGES.txt? > > >> >> Option 3, a variation of 2, would be to also create a Maven >> Archetypesor a sample POM that would enable the user to jumpstart >> their application. =C2=A0All the structure would be setup, so the >> dependencies would automatically download for them from Maven Central. >> > > This is also included in the jar. > See:odfdom-java-0.8.8-incubating-rc2.jar\META-INF\maven\org.apache.odftoo= lkit\odfdom-java\ > , the pom.xml of ODFDOM is listed there. > user can use it directly. > I was thinking of something more like: http://maven.apache.org/guides/introduction/introduction-to-archetypes.html But this can wait for a future release, I think. -Rob > > >> -Rob >> > > So, based on the former information, I think the only thing we need to do > is just remind users where to find them. This way will let us avoid manua= l > work and the risk of out of sync. What's your opinion? > > -- > -Devin