On 06/16/2011 07:48 PM, David Jencks wrote:
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.
They are used by third party testing tools.
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
