incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: RC2 binary package
Date Wed, 07 Dec 2011 14:13:48 GMT
On Wed, Dec 7, 2011 at 4:13 AM, Devin Han <devinhan@apache.org> wrote:
> Thank you for point it out, Rob. When I deep into the jars which generated
> by Maven, I notice the problem maybe easy to resolve.
> Maven is really powerful, which have helped us do all of the 3 options. In
> 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 <robweir@apache.org>
>
>> I looked some more at the binary package.  We're currently includeing
>> 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.  The with-dependencies JARs include the classes for all
>> of our dependencies, and all of their dependencies, etc.  So it is
>> self-contained, except for system classes.  But 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 repository
> 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.  But I think we
>> need to do this recursively and pull these licenses and notices into
>> our own.  Is that correct?
>>
>
> Please open odfdom-java-0.8.8-incubating-rc2-jar-with-dependencies.jar with
> 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 built
> 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 in
> 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 which
> listed in "license"  directory?
>

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.  Just ship
>> 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/)
>  - XML Commons External Components XML APIs (
> http://xml.apache.org/commons/components/external/)
> xml-apis:xml-apis:jar:1.3.04
>    License: The Apache Software License, Version 2.0  (
> http://www.apache.org/licenses/LICENSE-2.0.txt)
>
> From: 'The Apache Software Foundation' (http://www.apache.org/)
>  - ODF Custom Javadoc Taglets (
> http://incubator.apache.org/odftoolkit/odfdom/index.html)
> org.apache.odftoolkit:taglets:jar:0.8.8-incubating-rc2
>    License: Apache 2  (http://www.apache.org/licenses/LICENSE-2.0.txt)
>  - Xerces2 Java Parser (http://xerces.apache.org/xerces2-j)
> xerces:xercesImpl:jar:2.9.1
>    License: The Apache Software License, Version 2.0  (
> http://www.apache.org/licenses/LICENSE-2.0.txt)
>
>
> All of the detail information, such as, jar name,  version, 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.  All 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.odftoolkit\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 manual
> work and the risk of out of sync. What's your opinion?
>
> --
> -Devin

Mime
View raw message