On Jun 16, 2011, at 3:01 PM, Tom Cunningham wrote: > > I believe the txt files are data for a test case. It don't think it > make\ sense to tag a license header into them.
Unless there's a good technical reason these files can't have a license header, since they are distributed from apache as part of the source archive, it is much better if they have a license header. For instance if they are processed by juddi code and we can add a few lines to ignore // comment lines, I'd say it was worth it. If they are processed by a third party tool that we can't modify then that's a reason to discuss not including the license header. > > The rpc file is a generated file. That's a good reason not to include the license header :-) thanks! david jencks > > > > On 06/16/2011 05:29 PM, David Jencks wrote: >> The build now works for me. >> >> I don't know what the .txt files are used for or how but I think it would be >> better to get a license header into them if its plausible. >> >> What is the .rpc file? Is it generated? >> >> thanks! >> david jencks >> >> >> >> On Jun 16, 2011, at 1:24 PM, Tom Cunningham wrote: >> >>> Fixed the asm issue, and I've added headers to most of the files below. >>> The ones I did not add anything were : >>> >>> - the .txt files >>> - the .rpc file >>> - the .ser file, which is a serialized class file whose format that I guess >>> rat doesn't know about >>> >>> I think we're okay on omitting it from those files. >>> >>> The only one I'm unsure of is the .odp file - it is three powerpoint slides >>> - we could either add a license or just remove the file, I'll let Kurt make >>> the call. >>> >>> >>> On 06/15/2011 06:45 PM, David Jencks wrote: >>>> done in rev 1136228. >>>> Running maven rat:check on a fresh checkout I still see: >>>> >>>> !????? juddi-console/juddi-portal/package.properties >>>> !????? juddi-console/juddi-portal/pluto/unitpngfix.js >>>> !????? >>>> juddi-console/uddi-portlets/.gwt-tmp/shell/org.apache.juddi.portlets.Application.JUnit/422AEE328955081603763BA1867826A0.gwt.rpc >>>> !????? juddi-console/uddi-portlets/src/main/webapp/index.html >>>> !????? juddi-console/uddi-portlets/tomcat/conf/web.xml >>>> !????? juddi-console/uddi-portlets/tomcat/webapps/ROOT/WEB-INF/web.xml >>>> !????? >>>> juddi-console/uddi-portlets/tomcat/work/gwt/localhost/_/tldCache.ser >>>> !????? juddi-console/uddi-portlets/uddi-portlets.launch >>>> !????? qa/juddi-xlt/config/data/default/companies.txt >>>> !????? qa/juddi-xlt/config/data/default/countries.txt >>>> !????? qa/juddi-xlt/config/data/default/emails.txt >>>> !????? qa/juddi-xlt/config/data/default/firstnames.txt >>>> !????? qa/juddi-xlt/config/data/default/lastnames.txt >>>> !????? qa/juddi-xlt/config/data/default/nouns.txt >>>> !????? qa/juddi-xlt/config/data/default/searchphrases.txt >>>> !????? qa/juddi-xlt/config/data/default/sentences.txt >>>> !????? qa/juddi-xlt/config/data/default/streets.txt >>>> !????? qa/juddi-xlt/config/data/default/towns.txt >>>> !????? qa/juddi-xlt/config/data/default/words.txt >>>> !????? qa/QATestingProcess.odp >>>> !????? RELEASE_NOTES.html >>>> >>>> I'm also getting a new build error today that I didn't get yesterday that >>>> looks like an asm version mismatch: >>>> >>>> <testcase time="0.028" >>>> classname="org.apache.juddi.rmi.JNDIRegistrationTest" >>>> name="registerToJNDI_AnonymousPort"> >>>> <error >>>> message="org.objectweb.asm.ClassVisitor.visit(ILjava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V" >>>> type="java.lang.NoSuchMethodError">java.lang.NoSuchMethodError: >>>> org.objectweb.asm.ClassVisitor.visit(ILjava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V >>>> at net.sf.cglib.core.ClassEmitter.begin_class(ClassEmitter.java:63) >>>> at >>>> net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:173) >>>> at >>>> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25) >>>> at >>>> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:215) >>>> at >>>> net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145) >>>> at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:117) >>>> at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108) >>>> at net.sf.cglib.proxy.Enhancer.<clinit>(Enhancer.java:64) >>>> at >>>> org.mockejb.interceptor.InterceptableProxy.create(InterceptableProxy.java:38) >>>> at >>>> org.mockejb.jndi.MockContextFactory.getInitialContext(MockContextFactory.java:47) >>>> at >>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) >>>> at >>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) >>>> at javax.naming.InitialContext.init(InitialContext.java:223) >>>> at >>>> javax.naming.InitialContext.<init>(InitialContext.java:175) >>>> at >>>> org.apache.juddi.rmi.JNDIRegistration.<init>(JNDIRegistration.java:60) >>>> at >>>> org.apache.juddi.rmi.JNDIRegistration.getInstance(JNDIRegistration.java:53) >>>> ... >>>> >>>> I have no idea what might have changed to cause this. >>>> >>>> thanks >>>> david jencks >>>> >>>> >>>> >>>> >>>>> We're using JUDDI-502 for this. >>>>> >>>>> Cheers, >>>>> >>>>> --Kurt >>>>> >>>>> >>>>> >>>>> On 6/15/11 12:57 PM, David Jencks wrote: >>>>>> I think that unless you set up some exclusions you have to be careful to >>>>>> run >>>>>> >>>>>> mvn clean >>>>>> mvn rat:check >>>>>> >>>>>> or you get a lot of false arguments about stuff generated in the >>>>>> build.... that might be why you get a larger number of problems than I >>>>>> did. >>>>>> >>>>>> thanks >>>>>> david jencks >>>>>> >>>>>> On Jun 15, 2011, at 6:23 AM, Kurt T Stam wrote: >>>>>> >>>>>>> On 6/14/11 7:30 PM, David Jencks wrote: >>>>>>>> -1 >>>>>>>> >>>>>>>> Aside from the build problems that someone might be able to convince >>>>>>>> me to overlook, I ran >>>>>>>> >>>>>>>> mvn rat:check >>>>>>>> >>>>>>>> on the unpacked source zip which showed a lot of files (119) that did >>>>>>>> not have appropriate licensing info. It's possible that some of these >>>>>>>> can't for some kind of format reason but the first few I checked >>>>>>>> certainly could. If some of these can't have license headers I think >>>>>>>> there's a way to include a rat exclusion list where we could document >>>>>>>> them. >>>>>>> I'm getting: Too many unapproved licenses: 893 >>>>>>> 1. I think it does not like the copyright notices in the header. >>>>>>> * Copyright 2001-2011 The Apache Software Foundation, >>>>>>> >>>>>>> 2. I manually checked some and some files sure have the license >>>>>>> missing completely, so that sure needs fixing. >>>>>>>> I noticed a comment in juddi-portal/README that maven 2.0.6 should be >>>>>>>> used. If this is true for the entire project I think some updating is >>>>>>>> needed. >>>>>>>> >>>>>>>> I have some workarounds for the build issues I ran into that involve: >>>>>>>> >>>>>>>> - using derby 10.6.2.1 >>>>>>>> - using geronimo jta spec instead of (sun?) javaee specs >>>>>>>> - using geronimo javamail and changing the >>>>>>>> NotifierTest.testSMTPNotifier to expect to pass. >>>>>>>> >>>>>>>> I'd also prefer to see a lot of pom cleanup using dependency >>>>>>>> management to eliminate repetition of version info. >>>>>>>> >>>>>>>> If everyone's happy with this idea I'm happy to update the poms in >>>>>>>> this way. >>>>>>> Fine by me. >>>>>>>> It might be better for someone more familiar with all the files to >>>>>>>> look at the license issue. >>>>>>> ok I will go through a round of clean up on this. >>>>>>>> BTW I prefer to see vote emails that give the explicit location of the >>>>>>>> source bundle and make clear that it is what is being voted on, not >>>>>>>> the tag or binaries. >>>>>>> Fair enough >>>>>>>> thanks >>>>>>>> david jencks >>>>>>>> >>>>>>>> On Jun 14, 2011, at 6:20 AM, Kurt T Stam wrote: >>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> At some point the planned 'quick 3.0.5 release', turned into a much >>>>>>>>> more substantial release. One of >>>>>>>>> the major features was to support JAX-WS 2.2, and we beefed up the >>>>>>>>> client code substantially. Since we >>>>>>>>> added so much new code this release is now labeled 3.1.0. >>>>>>>>> >>>>>>>>> tag: http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.0/ >>>>>>>>> >>>>>>>>> nexus: >>>>>>>>> https://repository.apache.org/content/repositories/orgapachejuddi-068/ >>>>>>>>> >>>>>>>>> Please not that the uddi-ws-3.1.0 comes in 2 flavors: by default it >>>>>>>>> is compiled against the JAX-WS 2.2 spec, but we also >>>>>>>>> release a uddi-ws-3.1.0-jaxws21.jar with a 'jaxws21' classifier to >>>>>>>>> support JAX-WS 2.1 deployment environments. >>>>>>>>> >>>>>>>>> Also I have updated the website to reflect the 3.1.0 release: >>>>>>>>> http://svn.apache.org/repos/asf/juddi/site/ >>>>>>>>> >>>>>>>>> Please give it a spin and cast your vote in the next 72 hours! >>>>>>>>> >>>>>>>>> My vote: +1 >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> --Kurt >
