On Mon, Mar 1, 2010 at 11:30 AM, Guillaume Nodet <gno...@gmail.com> wrote: > On Mon, Mar 1, 2010 at 10:53, Karl Pauls <karlpa...@gmail.com> wrote: >> On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <david_jen...@yahoo.com> wrote: >>> >>> On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote: >>> >>>> -1 >>>> >>>> I'm really sorry but it looks to me like: >>>> >>>> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java >>>> org/apache/felix/karaf/shell/commands/EchoAction.java >>> >>> Were these files in the first 1.4.0 release attempt? my rat scan didn't find >>> them. >> >> I don't know - didn't find the time to look into that one. >> >>>> >>>> are missing the license header and >>>> >>>> manual/pom.xml >>>> client/dependency-reduced-pom.xml >>>> >>>> are missing a header as well. Furthermore, >>>> org.apache.felix.karaf.deployer.spring and a lot of the other modules >>>> have dependencies on spring-core which is not mentioned in the notice >>>> nor in the overall src notice (its mentioned in the overall binary >>>> notice). > > We really need to have a rat profile that we run before the release.
That would be good. >>> >>> AFAIK the legal requirements and best practice is that LICENSE and NOTICE >>> files are about what is actually in the artifact they are in, not anything >>> that might be needed to use the artifact. So unless a karaf artifact >>> actually includes code copied from spring, the NOTICE files should not >>> mention spring. Note that the maven-remote-resources-plugin includes a >>> dependencies report in the jar that lists the dependencies and their >>> licenses. Does felix have a different policy? If so, why? >> >> We do have a different policy but we although have talks about >> changing it. I guess, the main reason for including stuff in the >> NOTICE was that historically, the maven-remote-resource-plugin didn't >> work very well for us (nullpointers and other problems for a long >> time). The important thing for me is to have a place where we give >> credit where credit is due - if it is not he NOTICE we can make it a >> different file but we probably should vote on that or something. > > We don't need to credit something we don't ship. If the user uses a > jar that depends on spring, he will be responsible for downloading > Spring, so we don't need to credit Spring Source for that afaik. > Anyway I think we've tried to comply to the current policy and this > issue is not a show stopper imho. Yeah, I don't think it's a real show stopper either. I just mention it as we really should get back to talk about our policy in the first place (but I would have been ok with the release if it would not be for the missing headers). >> >>>> Other findings (not show-stoppers) are: >>>> >>>> Signatures and checksums work for me but for some reason there are not >>>> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files >>>> around. Very strange (probably something wrong with nexus/maven - not >>>> sure we can do something about it). >>> >>> AFAIK this is normal. >> >> Well, it was normal to have .asc.md5/sha files but having >> .asc.asc.md5/sha files? Again, not saying this is the fault of this >> release but man, this is getting out of hand no? > > Yeah, I'm not sure where those come from. I guess we could remove > those before > staging the repo if needed. i guess that's something to ask to the maven > guys. I think so too. Its just a pain to download them all and they really make no sense. >> >>>> Other than that, it looks to me like you are only building the jars >>>> and the sources jars but not the bin and project artifacts we usually >>>> do. Not a problem as such (as you still have the sources for each >>>> artifact) but its somewhat different from what we do normally ... >>> >>> Is there a good reason for felix to do something other than the defaults >>> from the apache 7 pom? (not that karaf is) >> >> Well, I like that i can unzip a -project.zip and am able to build the >> src inside of it. Having only the sources jars and the pom released >> might be enough to match formal requirements but I'd prefer to have >> something that builds without me assembling a project dir myself. This >> is something that we did override from the apache 7 pom defaults >> specifically because of this. Again, we can discuss whether it makes >> sense or not but until now our releases created bin and project >> artifacts. > > > I don't understand. We do have source and binary releases for Karaf. > You need to consider the whole Karaf as *one* thing you build. We > don't release all the artifacts separatly, so you don't need a source > and binary distribution for each of those. > The binary and source distributions are available at: > > https://repository.apache.org/content/repositories/orgapachefelix-015/org/apache/felix/karaf/apache-felix-karaf/1.4.0/ > You can unzip the source distribution and build karaf if you want. > The individial source jars associated to each jar are only here for > ease of debugging when using IDE, they are not meant to be used to > build the artifacts. Ah ok. I was mistaken the artifacts to be bundles which we typically consider a separate release. If they are not bundles (or at least will not possible be released independently) I'm fine with not having the -projects files. regards, Karl >> regards, >> >> Karl >> >>> thanks >>> david jencks >>> >>>> >>>> Some artifacts are still using the osgi jars from felix (they should >>>> switch to use the official org.osgi artifacts as soon as possible). >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> >>>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <ccust...@apache.org> >>>> wrote: >>>>> >>>>> The Karaf 1.4.0 artifacts have been staged for release. >>>>> >>>>> These release artifacts contain updated copyright year in all NOTICE >>>>> files >>>>> and includes an updated RELEASE-NOTES file which was not updated in the >>>>> previous release vote. As requested by Richard, I have noted that the >>>>> vote >>>>> will be open for *at least* 72 hours in order to allow time for proper >>>>> review. >>>>> >>>>> Release notes are here: >>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410 >>>>> >>>>> Staging repository: >>>>> https://repository.apache.org/content/repositories/orgapachefelix-015/ >>>>> >>>>> You can use this UNIX script to download the release and verify the >>>>> signatures: >>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>>>> >>>>> Usage: >>>>> sh check_staged_release.sh 015 /tmp/felix-staging >>>>> >>>>> Please vote to approve this release: >>>>> >>>>> [ ] +1 Approve the release >>>>> [ ] -1 Veto the release (please provide specific comments) >>>>> >>>>> This vote will be open for at least 72 hours. >>>>> >>>>> >>>>> -- >>>>> Chris Custine >>>>> FUSESource :: http://fusesource.com >>>>> My Blog :: http://blog.organicelement.com >>>>> Apache ServiceMix :: http://servicemix.apache.org >>>>> Apache Felix :: http://felix.apache.org >>>>> Apache Directory Server :: http://directory.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> karlpa...@gmail.com >>> >>> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Karl Pauls karlpa...@gmail.com
