Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org
 designates 67.222.39.38 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=BkQtoMiH2YJryEAq1NWfCs/c3P+0nfEuFjqeE7at8x3j1A11LzgYUtyAgv7aOsjlwxf04KTG1qXMfw1tAbYrQP/C4QafNUDfoM6q4a/aRnlgh23cWjI+f26lTHeflHWQ;
Message-ID: <4C179EA7.1060700@ungoverned.org>
Date: Tue, 15 Jun 2010 11:39:19 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: NOTICE/DEPENDENCIES files for Felix subproject releases
References: <4C0FD59D.1030502@ungoverned.org> <4C176DF9.8000404@gmail.com>
In-Reply-To: <4C176DF9.8000404@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/15/10 8:11, Felix Meschberger wrote:
> Hi,
>
> I have created FELIX-2411 as a container to fix all our subprojects over
> time.
>
> I have also updated an earlier patch to the parent POM attached to
> FELIX-1747 to use the latest Apache Parent POM 7, which already is
> correctly configured to use the Maven Remote Resources plugin and
> generate valid ASF source artifacts to vote upon.
>
> IMHO we should really be using the Maven Remote Resources plugin to
> generate the legal files.
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/FELIX-2411
> [2] https://issues.apache.org/jira/browse/FELIX-1747
>    

Thanks for looking into this Felix.

I played with it a little bit by trying to build framework and OBR with 
it...it didn't give me the best results, but this is likely because it 
doesn't understand that we are embedding source and or byte code. Any 
subproject using BND to embed byte code from other dependencies will 
likely not be correct.

So, we could potentially use this to automate information gathering, but 
it doesn't help us with the verification. We should probably create some 
documentation and perhaps an example on how to use it and augment its 
results.

Thanks.

-> richard

> On 09.06.2010 19:55, Richard S. Hall wrote:
>    
>> With the latest release of the framework and Gogo modules, we've tried
>> to update the release process for how we handle the NOTICE file. Our
>> past usage is apparently not aligned with the intended usage, where the
>> NOTICE file should only contained notices for included third-party
>> software whose license requires notice. Our new approach (for now) is this:
>>
>>    1. Include a NOTICE file which contains only required notices.
>>    2. Include a DEPENDENCIES file which contains our acknowledgments
>>       about the software the subproject uses.
>>
>> For the most part, this isn't a major hassle and largely boils down to
>> this:
>>
>>    1. Rename the current NOTICE file to DEPENDENCIES.
>>    2. Create a new NOTICE file that contains notices only for the "used"
>>       software requiring notices in the DEPENDENCIES file.
>>
>> Although the new DEPENDENCIES file is very similar to the old NOTICE
>> file, the template is slightly different as indicated here:
>>
>>
>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>
>>
>> Of course, in the long term we can try to move to automating the
>> generation of the NOTICE and/or DEPENDENCIES files, which would make our
>> lives simpler. If any subprojects currently are able to automate this
>> information, as long as the generated files contain information
>> consistent with what is proposed here, then the exact formatting is not
>> that important. But for hand generated files, follow this template.
>>
>> If you want to see examples, look in the framework or gogo subprojects.
>>
>> ->  richard
>>
>> p.s. This is obviously all open for discussion to the specifics, but
>> until then we should use this approach for releases in an effort to
>> better align with Apache process (with perhaps the exception of Karaf
>> since if/when it goes TLP then its PMC will decide how to do releases).
>>
>>