geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Proposal for use of maven-remote-resources-plugin
Date Sun, 09 Mar 2008 08:53:24 GMT
I've comitted this stuff.

Here's a sample DEPENDENCIES file:

// ------------------------------------------------------------------
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// ------------------------------------------------------------------

Genesis Plugins :: Maven
From: 'an unknown organization'
   - Unnamed - ant:ant:jar:1.6.5 ($project.url) ant:ant:jar:1.6.5

   - Unnamed - junit:junit:jar:3.8.1 ($project.url) junit:junit:jar: 

From: 'Apache Software Foundation' (
   - Maven Artifact (  
       License: The Apache Software License, Version 2.0  (http://
   - Maven Artifact Manager ( 
manager) org.apache.maven:maven-artifact-manager:jar:2.0.4
       License: The Apache Software License, Version 2.0  (http://
   - Maven Model (  
       License: The Apache Software License, Version 2.0  (http://
   - Maven Plugin API (  
       License: The Apache Software License, Version 2.0  (http://
   - Maven Profile Model (  
       License: The Apache Software License, Version 2.0  (http://
   - Maven Project Builder (  
       License: The Apache Software License, Version 2.0  (http://
   - Maven Repository Metadata Model ( 
repository-metadata) org.apache.maven:maven-repository-metadata:jar: 
       License: The Apache Software License, Version 2.0  (http://
   - Maven Local Settings Model ( 
settings) org.apache.maven:maven-settings:jar:2.0.4
       License: The Apache Software License, Version 2.0  (http://
   - Maven Wagon API ($project.url) org.apache.maven.wagon:wagon- 
       License: The Apache Software License, Version 2.0  (http://

From: 'Codehaus' (
   - Plugin Support (  

From: 'Codehaus' (
   - Default Plexus Container ($project.url)  

   - Plexus Common Utilities ($project.url)  

From: 'The Apache Software Foundation' (
   - Commons JEXL ( commons- 
       License: The Apache Software License, Version 2.0  (/LICENSE.txt)
   - Lang ( commons- 
       License: The Apache Software License, Version 2.0  (/LICENSE.txt)
   - Logging ( commons- 
       License: The Apache Software License, Version 2.0  (/LICENSE.txt)

From: 'The Codehaus' (
   - classworlds (  


I think this might be fairly useful to people who want to look into  
what licenses they may be using to use the software, but I could be  
convinced to take it out.  There's a dependency report in the  
generated site but it appears to have slightly different info  
(license missing for instance) and is obviously not distributed with  
the jar.

I'm working on some site generate issues and hope to have genesis 1.4  
take 3 ready for a vote later today (sunday)

david jencks

On Mar 8, 2008, at 5:30 PM, David Jencks wrote:

> On Mar 8, 2008, at 4:40 PM, Kevan Miller wrote:
>> 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.
> yes
>> 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...
> I think it makes it easier to look for possible license problems in  
> dependent jars that are likely to be needed to use the jar  
> containing the dependency file.  I always thought that was the  
> reason why the m-r-r-p put that info in NOTICE
> Will commit this stuff later tonight or tomorrow.
> thanks
> david jencks
>> --kevan

View raw message