juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Cunningham <tcunn...@redhat.com>
Subject Re: [VOTE] Release jUDDI-3.1.0
Date Fri, 17 Jun 2011 00:48:16 GMT
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.&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