james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jsieve] Any more TODO before 0.2 release?
Date Wed, 18 Jun 2008 16:33:55 GMT

On Jun 18, 2008, at 1:25 AM, Stefano Bagnara wrote:

> David Jencks ha scritto:
>> On Jun 17, 2008, at 4:18 PM, Stefano Bagnara wrote:
>>> David Jencks ha scritto:
>>>> The source and binary jars do not include junit so their LICENSE  
>>>> and NOTICE files must not include them.  The distro assemblies do  
>>>> include them so require a different LICENSE/NOTICE file.  So do  
>>>> the required LICENSE/NOTICE files in svn at the checkout root.
>>>
>>> You say "MUST NOT" include them: I thought it was a "SHOULD NOT",  
>>> but maybe the board had different directives?
>> I don't think there's total consensus except that what the m-r-r-p  
>> used to generate was wrong :-) To me it's unacceptable to  
>> distribute a jar with a NOTICE file that any user has to display  
>> somewhere claiming that there's say junit included when it is not  
>> included, likewise for license files.  They are supposed to be the  
>> users guidance as to what is legally going on with the jar they are  
>> working with.
>
> Sorry David, I didn't want to mean that if it is an opinion of you  
> it is not important :-)
>
> I just wanted to be sure there was no new directives I wasn't aware  
> of, so we can give this issue (and I agree this is an issue) the  
> right priority.
>
>>>> For me this would be enough to put the stage repo in a different  
>>>> module with separate legal goo files, so that the build  
>>>> requirements don't get mixed up so much with the actual apache  
>>>> code in the module.  However opinions may differ on this.
>>>> Anyway I'm not sure what is breaking and what problems you are  
>>>> seeing.
>>>
>>> I'm not sure I understand how to place it in a different module,  
>>> still create all of our artifacts and have different license/ 
>>> notice files in each artifact: can you drive me there?
>> I don't know how to produce these different legal files in one  
>> module except by hardcoding them in each case, so I'm suggesting  
>> separating into more than one module: the regular java module can  
>> just use the m-r-r-p with the latest resource bundle and no (AFAIK)  
>> additions, and the external jars can go in a stage bundle with a  
>> hardcoded LICENSE/NOTICE file suitable to the contents.  Maybe I've  
>> drunk too much maven kool-aid but I find the mixing of repositories  
>> and code rather bizarre.
>
> I would like maven to address this issue someway: are we the only  
> maven based project creating the jar, source-jar, javadoc-jar, bin- 
> zip-with-runtime-dependencies, src-zip-with-all-dependencies ? I  
> don't this so.
> The LICENSE/NOTICE for the binary jar is the most simple to do: most  
> time it does not include 3rd party code, so maven should IMHO  
> address the most complex ones (the LICENSE/NOTICE for big packages  
> including some scope of dependencies)
>
> I don't like what you propose (to manually create SOME license/ 
> notice files for the other packages): IMHO it is worse than creating  
> a single NOTICE/LICENSE including the largest set with right  
> references about what is an internal dependency, what is a runtime  
> dependency and what is needed to build the sources. People reading  
> it will have the option to understand that the binary-jar does not  
> really include the build time dependencies and we would have a  
> single tuple to review.
>
> Maybe the assembly plugin should support NOTICE/LICENSE compilation/ 
> aggregation.
>
>> I may well be pushing in an inappropriate direction for the project  
>> here, so feel free to ignore me or tell me to shut up :-)
>
> David, your feedback is really appreciated and I'm very happy to  
> learn new ways to do things. Even if we won't probably delay this  
> jsieve-0.2 release for this issue I think I will give a try to the  
> multimodule approach.
>
> What scare me is that maven is an ASF project and after so many  
> years it still does not accomplish ASF requirements out of the box.  
> People keep finding naive poms and plugin mixtures in order to have  
> the right stuff in the right place. E.g: my understanding from the  
> board is that LICENSES for every artifact redistributed should be  
> aggregated at the bottom of the LICENSE file, instead m-r-r-p puts  
> license references in the NOTICE file. I also tried to tell this to  
> maven-dev at the first releases of m-r-r-p and the apache bundle but  
> I've been ignored :-(

AFAICT until I asked a lot of questions on legal discuss it was really  
unclear what the m-r-r-p should be doing.  I think there's consensus  
that the latest resource bundle (1.4) is doing what is expected, and  
AFAIK it is not aggregating anything from the dependencies into either  
LICENSE or NOTICE files: it does generate an auxilliary DEPENDENCIES  
files listing the dependencies by license.

I don't think expecting maven to deal with generating legal files for  
a svn-based repo is reasonable or likely to happen in the standard  
maven plugins, since it is counter to one of the main purposes of maven.

Thinking about the situation a little more....

the normal maven generated artifacts (jar, source, javadoc jars) can  
get  the m-r-r-p generated legal files as they include what maven  
expects from these artifacts
On the other hand, you need to have hardcoded LICENSE and NOTICE files  
in svn at the expected checkout root that apply to everything in the  
checkout.  Since you have the maven repo in the checkout, you have to  
include all the legal goo for everything in the repo in those LICENSE  
and NOTICE files; thus they will also be suitable for the distro zip/ 
tar.gzs.

Does that make sense?

thanks
david jencks

>
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message