commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 20:40:27 GMT

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 <> wrote:
> >>
> >>> 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 file.
> > 
> > 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?



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

View raw message