commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 20:55:34 GMT
simon wrote:
> On Thu, 2008-01-10 at 21:20 +0100, Dennis Lundberg wrote:
>> Simon Kitching wrote:
>>> ---- Jochen Wiedmann <> schrieb:
>>>> On Jan 10, 2008 9:04 AM, Simon Kitching <>
>>>>> No. What I am saying is that the NOTICE file should have *only* information
about the files in the current maven module. The NOTICE should *never* *never* have information
about files in other maven modules, ie data should *never* be pulled from other poms in order
to generate the NOTICE file.
>> Is this ASF policy? I studied the "ASF Source Header and Copyright 
>> Notice Policy", but the docs on the contents of the NOTICE file is 
>> rather scarce.
> No, there is no policy doc that says this. And yes, unfortunately docs
> on the NOTICE file is indeed rather scarce.
> This is just my personal untrained legal opinion - as I indicated in the
> original email (this bit appears to have got trimmed away). I have asked
> this question on legal-discuss and got no answer.
> However this has always been the practice up to now, and there have been
> no legal issues. What is being proposed is something new.


>>> It's the bit about NOTICE file generation that I care about.
>>> I know that the remote-resources plugin is capable of pulling in a copy of the
LICENSE file from a central location. I don't personally think this is a good idea, and that
checking in a copy manually to each project is better, but care less about this than the NOTICE
>>> Is there something else that the remote-resources plugin would do for commons
projects *other* than handle NOTICE and LICENSE? If so, I'm not aware of it..
>> It can be used for *any* remote resource bundle that we'd care to 
>> create. One common use case is to package configuration files for 
>> Checkstyle and PMD into a jar file. That jar file is deployed to the 
>> central repository and can be downloaded by mrrp, thus ensuring that a 
>> bunch of related projects all share the same configuration.
> That looks really useful functionality, and I'm all in favour of it.
> That hadn't been mentioned AFAIK.
> The only bits I am worried about are NOTICE and LICENSE. And if we
> receive a proper legal opinion that the new approach is acceptable, then
> I would certainly not veto any release using generated files. I still
> don't *like* them as I think they are not as user-friendly as a file
> checked in to SVN, but that's not nearly so important.
> So, given that you've explained that maven-remote-resources has other
> uses, I'd be happy to see it defined in the parent dependencyManagement
> - as long as it does *not* generate any notice files by default. And
> that means not just stopping if one exists in the filesystem, but
> actively having to be told to generate one. Would you be willing to add
> a config flag for that?

Not sure I understand your question here.

If we add mrrp to the pluginManagement section in the commons-parent 
pom, nothing will be generated by default. If a component wants to 
actually download and use any remote resource bundles, that component 
would have to activate/configure this in that component's pom.

> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message