Re: Questions about geronimo-plugin.xml content
On Sep 6, 2007, at 5:31 PM, David Jencks wrote: On Sep 6, 2007, at 10:42 AM, Kevan Miller wrote: On Sep 6, 2007, at 12:52 PM, David Jencks wrote: I think we should start using the maven-remote-resources- plugin. I will get to it eventually for sufficiently distant values of eventually... :-) I would love to have license and notice file generation to be automated. I have my doubts that it will work for a project with as many diverse dependencies as Geronimo. The example you provide below indicates that m-r-r-p (or the available maven meta-data descriptions) is not ready, yet -- note the multiple occurrences of "... developed by $project.organization.name ($project.organization.url)." saying "including problems that haven't been overridden yet" was supposed to imply that these are fixable through additional configuration so you wouldn't say that :-) I'm not sure where these particular ${}'s came from since when I converted apacheds to use the m-r-r-p I thought I got rid of all of them. My understanding which could be quite wrong is that any aggregate we ship is licensed under the asl2 only no matter what's in it and that this may limit what we can include in an aggregate work. Our aggregate is not licensed solely under ASL V2. Far from it... We develop source code which is, almost entirely, ASL v2 licensed. However, our aggregate contains artifacts that are covered my multiple licenses. These licenses are "acceptable" for use within an Apache product (as determined by our PMC). I don't think Apache DS has done a very good job of indicating the licenses that apply to their aggregate (at least in their noarch distribution it's terrible). Looking at 1.5.1 unstable binary (i couldn't find a "stable" binary), the apacheds-noarch/target/ apacheds-noarch-installer-1.5.1-app.jar contains the following license files: ASL V2 Spring SL4J jzlib JDBM (LICENSE.txt in a separate format from the other license files) I don't understand this so I'll stop talking about it. I'm not sure the m-r-r-p will be useful for assemblies but I think it will work fine for jars and cars. Heh. I think you are probably right about jars and cars. --kevan
Re: Questions about geronimo-plugin.xml content
On Sep 6, 2007, at 10:42 AM, Kevan Miller wrote: On Sep 6, 2007, at 12:52 PM, David Jencks wrote: I think we should start using the maven-remote-resources-plugin. I will get to it eventually for sufficiently distant values of eventually... :-) I would love to have license and notice file generation to be automated. I have my doubts that it will work for a project with as many diverse dependencies as Geronimo. The example you provide below indicates that m-r-r-p (or the available maven meta-data descriptions) is not ready, yet -- note the multiple occurrences of "... developed by $project.organization.name ($project.organization.url)." saying "including problems that haven't been overridden yet" was supposed to imply that these are fixable through additional configuration so you wouldn't say that :-) I'm not sure where these particular ${}'s came from since when I converted apacheds to use the m-r-r-p I thought I got rid of all of them. My understanding which could be quite wrong is that any aggregate we ship is licensed under the asl2 only no matter what's in it and that this may limit what we can include in an aggregate work. Our aggregate is not licensed solely under ASL V2. Far from it... We develop source code which is, almost entirely, ASL v2 licensed. However, our aggregate contains artifacts that are covered my multiple licenses. These licenses are "acceptable" for use within an Apache product (as determined by our PMC). I don't think Apache DS has done a very good job of indicating the licenses that apply to their aggregate (at least in their noarch distribution it's terrible). Looking at 1.5.1 unstable binary (i couldn't find a "stable" binary), the apacheds-noarch/target/ apacheds-noarch-installer-1.5.1-app.jar contains the following license files: ASL V2 Spring SL4J jzlib JDBM (LICENSE.txt in a separate format from the other license files) I don't understand this so I'll stop talking about it. I'm not sure the m-r-r-p will be useful for assemblies but I think it will work fine for jars and cars. thanks david jencks --kevan The m-r-r-p includes the apache license and a notice file which lists all the dependencies and their origin. Here's a sample, including problems that haven't been overridden yet: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for ApacheDS Server Main // -- ApacheDS Server Main Copyright 2003-2007 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). This product includes software, Spring Framework: Beans, developed by Spring Framework (http://www.springframework.org/). This product includes software, AOP alliance, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Extra Schemas, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Apache Directory MINA ASN.1 Codec Shared, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Daemon, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Constants, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, ApacheDS Utils, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Unnamed - logkit:logkit:jar:1.0.1, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Core, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, JDBM, developed by JDBM (http://jdbm.sourceforge.net/). thanks david jencks On Sep 6, 2007, at 9:14 AM, Paul McMahan wrote: On Sep 4, 2007, at 9:49 AM, Kevan Miller wrote: Looking at the dojo jetty/tomcat configs, we're not handling the license/notice files very well. IMO, the META-INF/LICENSE.txt file should contain both the ASL V2 license and the Dojo licenses. The META-INF/NOTICE.txt should contain the Apache Geronimo copyright notice and the Dojo notice. Thanks for pointing this out. I added the Dojo license and notice to applications/geronimo-dojo, configs/dojo-tomcat, and configs/dojo-jetty in trunk and branches/2.0. Best wishes, Paul
Re: Questions about geronimo-plugin.xml content
On Sep 6, 2007, at 12:52 PM, David Jencks wrote: I think we should start using the maven-remote-resources-plugin. I will get to it eventually for sufficiently distant values of eventually... :-) I would love to have license and notice file generation to be automated. I have my doubts that it will work for a project with as many diverse dependencies as Geronimo. The example you provide below indicates that m-r-r-p (or the available maven meta-data descriptions) is not ready, yet -- note the multiple occurrences of "... developed by $project.organization.name ($project.organization.url)." My understanding which could be quite wrong is that any aggregate we ship is licensed under the asl2 only no matter what's in it and that this may limit what we can include in an aggregate work. Our aggregate is not licensed solely under ASL V2. Far from it... We develop source code which is, almost entirely, ASL v2 licensed. However, our aggregate contains artifacts that are covered my multiple licenses. These licenses are "acceptable" for use within an Apache product (as determined by our PMC). I don't think Apache DS has done a very good job of indicating the licenses that apply to their aggregate (at least in their noarch distribution it's terrible). Looking at 1.5.1 unstable binary (i couldn't find a "stable" binary), the apacheds-noarch/target/apacheds- noarch-installer-1.5.1-app.jar contains the following license files: ASL V2 Spring SL4J jzlib JDBM (LICENSE.txt in a separate format from the other license files) --kevan The m-r-r-p includes the apache license and a notice file which lists all the dependencies and their origin. Here's a sample, including problems that haven't been overridden yet: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for ApacheDS Server Main // -- ApacheDS Server Main Copyright 2003-2007 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). This product includes software, Spring Framework: Beans, developed by Spring Framework (http://www.springframework.org/). This product includes software, AOP alliance, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Extra Schemas, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Apache Directory MINA ASN.1 Codec Shared, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Daemon, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Constants, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, ApacheDS Utils, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Unnamed - logkit:logkit:jar:1.0.1, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Core, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, JDBM, developed by JDBM (http://jdbm.sourceforge.net/). thanks david jencks On Sep 6, 2007, at 9:14 AM, Paul McMahan wrote: On Sep 4, 2007, at 9:49 AM, Kevan Miller wrote: Looking at the dojo jetty/tomcat configs, we're not handling the license/notice files very well. IMO, the META-INF/LICENSE.txt file should contain both the ASL V2 license and the Dojo licenses. The META-INF/NOTICE.txt should contain the Apache Geronimo copyright notice and the Dojo notice. Thanks for pointing this out. I added the Dojo license and notice to applications/geronimo-dojo, configs/dojo-tomcat, and configs/ dojo-jetty in trunk and branches/2.0. Best wishes, Paul
Re: Questions about geronimo-plugin.xml content
I think we should start using the maven-remote-resources-plugin. I will get to it eventually for sufficiently distant values of eventually... My understanding which could be quite wrong is that any aggregate we ship is licensed under the asl2 only no matter what's in it and that this may limit what we can include in an aggregate work. The m-r-r-p includes the apache license and a notice file which lists all the dependencies and their origin. Here's a sample, including problems that haven't been overridden yet: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for ApacheDS Server Main // -- ApacheDS Server Main Copyright 2003-2007 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). This product includes software, Spring Framework: Beans, developed by Spring Framework (http://www.springframework.org/). This product includes software, AOP alliance, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Extra Schemas, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Apache Directory MINA ASN.1 Codec Shared, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Daemon, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Constants, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, ApacheDS Utils, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, Unnamed - logkit:logkit:jar:1.0.1, developed by $project.organization.name ($project.organization.url). This product includes software, ApacheDS Core, developed by The Apache Software Foundation (http://www.apache.org/). This product includes software, JDBM, developed by JDBM (http://jdbm.sourceforge.net/). thanks david jencks On Sep 6, 2007, at 9:14 AM, Paul McMahan wrote: On Sep 4, 2007, at 9:49 AM, Kevan Miller wrote: Looking at the dojo jetty/tomcat configs, we're not handling the license/notice files very well. IMO, the META-INF/LICENSE.txt file should contain both the ASL V2 license and the Dojo licenses. The META-INF/NOTICE.txt should contain the Apache Geronimo copyright notice and the Dojo notice. Thanks for pointing this out. I added the Dojo license and notice to applications/geronimo-dojo, configs/dojo-tomcat, and configs/ dojo-jetty in trunk and branches/2.0. Best wishes, Paul
Re: Questions about geronimo-plugin.xml content
On Sep 4, 2007, at 9:49 AM, Kevan Miller wrote: Looking at the dojo jetty/tomcat configs, we're not handling the license/notice files very well. IMO, the META-INF/LICENSE.txt file should contain both the ASL V2 license and the Dojo licenses. The META-INF/NOTICE.txt should contain the Apache Geronimo copyright notice and the Dojo notice. Thanks for pointing this out. I added the Dojo license and notice to applications/geronimo-dojo, configs/dojo-tomcat, and configs/dojo- jetty in trunk and branches/2.0. Best wishes, Paul
Re: Questions about geronimo-plugin.xml content
On Sep 1, 2007, at 8:34 PM, David Jencks wrote: I've been working on generating geronimo-plugin.xml from the pom.xml and am really confused about what should be in some of the elements. I wonder if we need to add more information for more clarity. For instance, the dojo configs currently say: http://dojotoolkit.org/ Dojo Foundation BSD and Academic Free License v2.1 This is appropriate for dojo itself but I think its misleading for our repackaging of dojo to run in geronimo. Since we are distributing the car file from apache I think the license has to be asl2. That's certainly what we're including in the car file itself. Similarly the dojo guys don't know anything about our distribution so pointing to them seems a bit misleading. What I can set up automatically from the pom uses the info there, which I think is more appropriate. I get http://geronimo.apache.org/ The Apache Geronimo development community The Apache Software License, Version 2.0 I think it would be more appropriate to put the stuff about the dojo organization in the description or in some additional optional "content-author" type elements. thoughts? Agreed that the geronimo-plugin.xml should reference the Apache Geronimo project and the the Apache license info. The plugin, itself, is covered by multiple licenses (since it contains both Geronimo and Dojo artifacts). As such, it might be appropriate to reference both projects... Looking at the dojo jetty/tomcat configs, we're not handling the license/notice files very well. IMO, the META-INF/LICENSE.txt file should contain both the ASL V2 license and the Dojo licenses. The META-INF/NOTICE.txt should contain the Apache Geronimo copyright notice and the Dojo notice. --kevan
Re: Questions about geronimo-plugin.xml content
On Sep 1, 2007, at 8:34 PM, David Jencks wrote: What I can set up automatically from the pom uses the info there, which I think is more appropriate. I get http://geronimo.apache.org/ The Apache Geronimo development community The Apache Software License, Version 2.0 I think it would be more appropriate to put the stuff about the dojo organization in the description or in some additional optional "content-author" type elements. thoughts? I put that vendor related info into the metadata thinking it would help automate the creation of pages like: http://geronimoplugincentral.org/index.php? option=com_content&task=view&id=18&Itemid=29 But giving it a second thought I agree that those fields should be used for the plugin itself rather than what is "inside" the plugin. might work OK, or to facilitate usage like the page referenced above, and some other interesting scenarios, we could introduce an element that provides information about embedded components. For example: Dojo plugin for Jetty http://geronimo.apache.org/ The Apache Geronimo development community The Apache Software License, Version 2.0 Dojo Toolkit The Dojo foundation 0.4.2 http://dojotoolkit.org/ BSD and Academic Free License v2.1 This element is different from the and elements because it describes something that is actually inside the plugin. Best wishes, Paul
Re: Questions about geronimo-plugin.xml content
On Sep 1, 2007, at 8:34 PM, David Jencks wrote: I think it would be more appropriate to put the stuff about the dojo organization in the description or in some additional optional "content-author" type elements. I think your probably right David. We are distributing our component which should be AL 2.0 and we are including another project in that component that allows redistribution under a compatible license. We should clearly document the Dojo info in our NOTICES file. thoughts? thanks david jencks
Questions about geronimo-plugin.xml content
I've been working on generating geronimo-plugin.xml from the pom.xml and am really confused about what should be in some of the elements. I wonder if we need to add more information for more clarity. For instance, the dojo configs currently say: http://dojotoolkit.org/ Dojo Foundation BSD and Academic Free License v2.1license> This is appropriate for dojo itself but I think its misleading for our repackaging of dojo to run in geronimo. Since we are distributing the car file from apache I think the license has to be asl2. That's certainly what we're including in the car file itself. Similarly the dojo guys don't know anything about our distribution so pointing to them seems a bit misleading. What I can set up automatically from the pom uses the info there, which I think is more appropriate. I get http://geronimo.apache.org/ The Apache Geronimo development community The Apache Software License, Version 2.0 I think it would be more appropriate to put the stuff about the dojo organization in the description or in some additional optional "content-author" type elements. thoughts? thanks david jencks