On the DEPENDENCIES, i guess we should first discuss what we want this file to be used for exactly. "acknowledgments about the software the subproject uses" is a bit vague. Is that at runtime ? compile time ? build-time (including maven, plugins and all...) ? I do think maven is in a good position to actually know all the things we need.
As for the formatting of the NOTICE file, I don't really get why we wouldn't leverage the work that has been done by other people in trying to integrate those legal requirements in maven. Just want to mention that every other project using maven I know about use the maven-remote-resources-plugin. It's even in the root apache pom iirc. Anyway, looking at the gogo/runtime as an example, I see the following NOTICE ======= Apache Felix Gogo Runtime Copyright 2010 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Licensed under the Apache License 2.0. This product includes software developed at The OSGi Alliance (http://www.osgi.org/). Copyright (c) OSGi Alliance (2000, 2009). Licensed under the Apache License 2.0. ======= Not sure why we say it *includes* software developped at the OSGi Alliance. In that case, nothing comes from the Alliance. All the classes in the final jar comes from this module, hence from the ASF. I think the case where we include software is rare: it's the case when we ship an api package, that's mostly it. I would suggest investigating the use of the maven-remote-resources-plugin and keep the DEPENDENCIES file generated by maven. I'll try to provide a patch on gogo as an example so that we can discuss things further. On Thu, Jun 10, 2010 at 15:52, Richard S. Hall <[email protected]> wrote: > On 6/10/10 9:47, Guillaume Nodet wrote: > >> I think we should keep the amount of legal files to the bare minimum, i.e. >> make sure the LICENSE and NOTICE files are correct wrt the ASF ways of >> doing >> things. Anything else is not mandatory and imho, should be removed, >> unless >> generated, to avoid the extra work of maintaining those files for no real >> added value. >> >> > > Not sure to what you are referring, this is exactly what is being done now. > The DEPENDENCIES file is not a legal file, so that is a non-issue. If you > are saying you are against acknowledging the software we depend on, then we > can have that discussion, but it has nothing to do with the legal files. > > -> richard > > > On Thu, Jun 10, 2010 at 15:41, Richard S. Hall<[email protected]> >> wrote: >> >> >> >>> On 6/10/10 9:03, Justin Edelson wrote: >>> >>> >>> >>>> On 6/10/10 8:54 AM, Richard S. Hall wrote: >>>> >>>> >>>> >>>> >>>>> On 6/9/10 17:11, Justin Edelson wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a >>>>>> reference to codehaus, but I didn't think the framework depends upon >>>>>> codehaus libraries, just some Maven plugin. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I think it was the RAT plugin, but this has since moved to Apache, >>>>> right? >>>>> >>>>> >>>>> >>>>> >>>> My (albeit very vague) understanding is that it is in the process of >>>> being moved. In any case, the framework pom still references the >>>> codehaus version. >>>> >>>> >>>> >>>> >>> Yeah, that should probably be upgraded at some point. >>> >>> >>> I think it very classy to acknowledge plugins like this. It just isn't >>> >>> >>>> clear to me that, based on your original email, that was your intent. >>>> >>>> >>>> >>>> >>> As I said, we'll have to clear that up...when I find the time, I'll edit >>> the wiki page... >>> >>> -> richard >>> >>> >>> Justin >>> >>> >>>> >>>> >>>> >>>> >>>>> -> richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Justin >>>>>> >>>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The DEPENDENCIES file is completely optional as far as apache policy >>>>>>> is concerned. I wrote the maven code that generates these with the >>>>>>> intention of giving users hints about the other software that would >>>>>>> likely be needed to actually use the artifact containing the >>>>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped) >>>>>>> dependencies, not all the maven stuff that may have been used to >>>>>>> generate the artifact. >>>>>>> >>>>>>> Since felix is an osgi based project that uses osgi to hook up >>>>>>> bundles, and avoids require-bundle like the plague, and there's no >>>>>>> good reason to suppose that the maven dependencies will be the actual >>>>>>> providers of the required imports, a strong case could be made that >>>>>>> felix should simply not include DEPENDENCIES files. >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 6/9/10 14:52, Justin Edelson wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Richard- >>>>>>>>> Perhaps this is supposed to be obvious, but I think it would be >>>>>>>>> helpful to >>>>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, >>>>>>>>> it >>>>>>>>> includes dependencies (in any scope) as well as software executed >>>>>>>>> as part of >>>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may >>>>>>>>> not be >>>>>>>>> intuitive. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> True. We need to be clearer... >>>>>>>> >>>>>>>> -> richard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Justin >>>>>>>>> >>>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S. >>>>>>>>> Hall<[email protected]>wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> With the latest release of the framework and Gogo modules, we've >>>>>>>>>> tried to >>>>>>>>>> update the release process for how we handle the NOTICE file. Our >>>>>>>>>> past usage >>>>>>>>>> is apparently not aligned with the intended usage, where the >>>>>>>>>> NOTICE file >>>>>>>>>> should only contained notices for included third-party software >>>>>>>>>> whose >>>>>>>>>> license requires notice. Our new approach (for now) is this: >>>>>>>>>> >>>>>>>>>> 1. Include a NOTICE file which contains only required notices. >>>>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments >>>>>>>>>> about the software the subproject uses. >>>>>>>>>> >>>>>>>>>> For the most part, this isn't a major hassle and largely boils >>>>>>>>>> down to >>>>>>>>>> this: >>>>>>>>>> >>>>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES. >>>>>>>>>> 2. Create a new NOTICE file that contains notices only for the >>>>>>>>>> "used" >>>>>>>>>> software requiring notices in the DEPENDENCIES file. >>>>>>>>>> >>>>>>>>>> Although the new DEPENDENCIES file is very similar to the old >>>>>>>>>> NOTICE file, >>>>>>>>>> the template is slightly different as indicated here: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Of course, in the long term we can try to move to automating the >>>>>>>>>> generation >>>>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our >>>>>>>>>> lives simpler. >>>>>>>>>> If any subprojects currently are able to automate this >>>>>>>>>> information, as long >>>>>>>>>> as the generated files contain information consistent with what is >>>>>>>>>> proposed >>>>>>>>>> here, then the exact formatting is not that important. But for >>>>>>>>>> hand >>>>>>>>>> generated files, follow this template. >>>>>>>>>> >>>>>>>>>> If you want to see examples, look in the framework or gogo >>>>>>>>>> subprojects. >>>>>>>>>> >>>>>>>>>> -> richard >>>>>>>>>> >>>>>>>>>> p.s. This is obviously all open for discussion to the specifics, >>>>>>>>>> but until >>>>>>>>>> then we should use this approach for releases in an effort to >>>>>>>>>> better align >>>>>>>>>> with Apache process (with perhaps the exception of Karaf since >>>>>>>>>> if/when it >>>>>>>>>> goes TLP then its PMC will decide how to do releases). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
