Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of kevan.miller@gmail.com
 designates 66.249.82.238 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer;
        b=Z/+UutJd+Q4HcB2wLudT3VFL3UjxzRW+AknWBzeUTJysfHwey0Pbg++bJ4Y7wHR0zvtysthnruZl0R18lyJ5t1HLnAU5P7AJJFDkjYzr2J1tSq2JNszb3Ct9K7wx1ZGXGvUYeXBhdR0JjppRo03ySsPFr2jbff/cm84eNnz6ecU=
Message-Id: <7EC033B1-83BA-4F17-8EB3-C3A666A3C9B0@gmail.com>
From: Kevan Miller <kevan.miller@gmail.com>
To: dev@geronimo.apache.org
In-Reply-To: <D9BB254D-5E5E-4134-B4B3-EEFB61B0671E@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Proposal for use of maven-remote-resources-plugin
Date: Sat, 8 Mar 2008 19:40:32 -0500
References: <D9BB254D-5E5E-4134-B4B3-EEFB61B0671E@yahoo.com>


On Mar 8, 2008, at 1:09 PM, David Jencks wrote:

> There's been a bunch of discussion on legal-discuss recently about  
> exactly what should be in the license and notice files and after  
> looking over the remote-resource-plugin I think we could use it to  
> provide correct and useful information by doing the following:
>
>
> 1. Produce 3 files: LICENSE, NOTICE, and DEPENDENCIES (new)
> 2. The standard LICENSE and NOTICE files would be ALv2 and the  
> standard NOTICE (with ".vm" appended to the file name).  No  
> processing except date range if appropriate.
> 3. Additional licenses and notices need to be ascertained by hand  
> and files containing these additions put in src/main/appended- 
> resources.  For instance src/main/appended-resources/LICENSE and src/ 
> main/appended-resources/NOTICE
> 4. In addition, for the convenience of our users, we provide a list  
> of transitive dependencies with origin.  This would be pretty  
> similar to what the standard resource bundle puts into the NOTICE  
> file.
>
> 5. genesis would be modified to use this plugin and this bundle by  
> default.
>
> David Blevins has a dependencies plugin at codehaus/swizzle that  
> provides hierarchy information by indenting but doesn't seem to  
> provide provenance.  At this point I think I'd prefer the provenance  
> info to the  indentation.  If someone has an idea about how to get  
> both easily I'm all ears.
>
> I'd prefer it if there was an easy way to roll up NOTICES and  
> LICENSES for projects that physically include jars from other  
> projects (such as our servers and jee applications and plugins) but  
> I think that leaving that capability to future developments in the m- 
> r-r-p might be wise.
>
> I'm having some trouble getting the genesis release OK without the m- 
> r-r-p so I'd kinda like to get this implemented in the next day or  
> two.


Sounds good to me. To make sure I understand...

So, it sounds like this is essentially creating the same information  
that we currently have in our geronimo/server (LICENSE and NOTICE  
files) and subprojects. Correct? Difference being whitespace/editorial  
in nature. As long as we have essentially the same info and aren't  
adding the cruft that the m-r-r-p wants to add by default, I think  
I'll be fine with this...

IIUC, this proposal means we remove most of the LICENSE and NOTICE  
files in our svn (e.g. server/trunk/framework/modules/geronimo-kernel/ 
LICENSE.txt). The one exception is the LICENSE/NOTICE files in the  
root of a src distribution file, which must be maintained in svn, and  
perhaps license/notice files in assemblies (perhaps). Some modules and  
configs which require additional license/notice info, will have this  
info placed in src/main/appended-resources. This information will be  
automatically appended to the standard license/notice info. One  
example of a module requiring this treatment would be server/trunk/ 
framework/modules/geronimo-crypto/LICENSE.txt.

I don't really have any objections to a DEPENDENCIES file, but I am  
not sure what it adds. It's certainly not a requirement. I'd be  
interested to hear how you think it will be used...

--kevan