juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [VOTE] Release jUDDI-3.1.0
Date Thu, 16 Jun 2011 23:48:46 GMT

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.&lt;clinit&gt;(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.&lt;init&gt;(InitialContext.java:175)
>>>>         at org.apache.juddi.rmi.JNDIRegistration.&lt;init&gt;(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
> 


Mime
View raw message