You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Kurt T Stam <ku...@gmail.com> on 2011/06/14 15:20:38 UTC
[VOTE] Release jUDDI-3.1.0
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
+1 here
On 06/14/2011 09: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
[STOP-VOTE] Release jUDDI-3.1.0
Posted by Kurt T Stam <ku...@gmail.com>.
Let's stop the vote, and address the issues brought up by David.
--Kurt
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 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. It might be better for someone more familiar with all the files to look at the license issue.
>
> 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.
>
> 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
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
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.
The rpc file is a generated file.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
I'm not seeing that error, but uddi-portlets is failing for me.
On 06/15/2011 06:45 PM, David Jencks wrote:
> On Jun 15, 2011, at 10:53 AM, Kurt T Stam wrote:
>
>> Thanks David, slowly getting the hang of it...
>>
>> Can you check in the changes for
>>
>> - using geronimo jta spec instead of (sun?) javaee specs
>> - using geronimo javamail and changing the NotifierTest.testSMTPNotifier to expect to pass.
> 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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
On Jun 15, 2011, at 10:53 AM, Kurt T Stam wrote:
> Thanks David, slowly getting the hang of it...
>
> Can you check in the changes for
>
> - using geronimo jta spec instead of (sun?) javaee specs
> - using geronimo javamail and changing the NotifierTest.testSMTPNotifier to expect to pass.
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
>
Re: [VOTE] Release jUDDI-3.1.0
Posted by Tom Cunningham <tc...@redhat.com>.
Took a pass through the license files - went through everything but the
JARs.
If you're getting a large number of missing license headers, you're
likely pulling in the generated GWT classes in your count.
--Tom
On 06/15/2011 01:53 PM, Kurt T Stam wrote:
> Thanks David, slowly getting the hang of it...
>
> Can you check in the changes for
>
> - using geronimo jta spec instead of (sun?) javaee specs
> - using geronimo javamail and changing the
> NotifierTest.testSMTPNotifier to expect to pass.
>
> 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
>
Re: [VOTE] Release jUDDI-3.1.0
Posted by Kurt T Stam <ku...@gmail.com>.
Thanks David, slowly getting the hang of it...
Can you check in the changes for
- using geronimo jta spec instead of (sun?) javaee specs
- using geronimo javamail and changing the NotifierTest.testSMTPNotifier to expect to pass.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: [VOTE] Release jUDDI-3.1.0
Posted by Kurt T Stam <ku...@gmail.com>.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
-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 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. It might be better for someone more familiar with all the files to look at the license issue.
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.
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
Re: [VOTE] Release jUDDI-3.1.0
Posted by Kurt T Stam <ku...@gmail.com>.
Hi David,
Good to see you're still paying attention :).
There seems to be a 10.5.3.0_1 version out there now. Not sure why the
build machine as well as my build never complained (and my
.m2/.../derby-project.pom looks perfectly fine!, but when I deleted it I
see the same issue. Anyway good catch, let's move to 10.5.3.0_1.
BTW maven 2.2 or newer should work. Personally I'm using maven 3.0.3.
Cheers,
--Kurt
On 6/14/11 6:12 PM, David Jencks wrote:
> I haven't been able to build the tag using maven 3.0.3 or 2.2.1. With 3.0.3 I get an error like this:
>
> Downloading: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby/10.5.3.0/derby-10.5.3.0.pom
> Downloaded: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby/10.5.3.0/derby-10.5.3.0.pom (3 KB at 46.5 KB/sec)
> Downloading: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby-project/${derby.version}/derby-project-${derby.version}.pom
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] jUDDI_v3 Parent ................................... SUCCESS [0.807s]
> [INFO] UDDI_v3 WS Stubs and Schema Bindings Generated from WSDL SUCCESS [4.106s]
> [INFO] UDDI Technical Compatibility Kit (TCK) Base ....... SUCCESS [0.877s]
> [INFO] jUDDI Client side Code ............................ SUCCESS [5.744s]
> [INFO] jUDDI Core ........................................ FAILURE [0.324s]
> [INFO] jUDDI Core ........................................ SKIPPED
> [INFO] jUDDI base-war Deployment ......................... SKIPPED
> [INFO] jUDDI CXF Deployment .............................. SKIPPED
> [INFO] jUDDI Service Registration Examples ............... SKIPPED
> [INFO] jUDDI Tomcat Packaging ............................ SKIPPED
> [INFO] UDDI TCK Tests .................................... SKIPPED
> [INFO] jUDDI User Guide -(en-US) ......................... SKIPPED
> [INFO] jUDDI Dev Guide -(en-US) .......................... SKIPPED
> [INFO] jUDDI Document Packaging .......................... SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 14.467s
> [INFO] Finished at: Tue Jun 14 14:49:38 PDT 2011
> [INFO] Final Memory: 19M/1132M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project juddi-core: Could not resolve dependencies for project org.apache.juddi:juddi-core:bundle:3.1.0: Failed to collect dependencies for [org.apache.juddi:uddi-ws:jar:3.1.0 (compile), org.apache.juddi:juddi-client:jar:3.1.0 (compile), org.apache.juddi:uddi-tck-base:jar:3.1.0 (test), javax.persistence:persistence-api:jar:1.0 (compile), commons-codec:commons-codec:jar:1.3 (compile), commons-configuration:commons-configuration:jar:1.6 (compile), javax:javaee-api:jar:6.0 (provided), org.apache.derby:derby:jar:10.5.3.0 (test), mysql:mysql-connector-java:jar:5.1.6 (test), postgresql:postgresql:jar:8.2-504.jdbc3 (test), org.mockejb:mockejb:jar:0.6-beta2 (test), cglib:cglib-nodep:jar:2.2 (test), org.apache.openjpa:openjpa:jar:1.2.1 (compile), junit:junit:jar:4.5 (test), commons-logging:commons-logging-api:jar:1.1 (compile)]: Failed to read artifact descriptor for org.apache.derby:derby:jar:10.5.3.0: Could not find artifact org.apache.derby:derby-project:pom:${derby.version} in nexus (http://localhost:8081/nexus/content/groups/public) -> [Help 1]
>
>
> The problem appears to be in the derby 10.5.3.0 pom which doesn't look valid:
>
> <parent>
> <groupId>org.apache.derby</groupId>
> <artifactId>derby-project</artifactId>
> <version>${derby.version}</version>
> </parent>
>
> Does someone have a workaround for this problem? Is it necessary to use this derby version?
>
> 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
Re: [VOTE] Release jUDDI-3.1.0
Posted by David Jencks <da...@yahoo.com>.
I haven't been able to build the tag using maven 3.0.3 or 2.2.1. With 3.0.3 I get an error like this:
Downloading: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby/10.5.3.0/derby-10.5.3.0.pom
Downloaded: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby/10.5.3.0/derby-10.5.3.0.pom (3 KB at 46.5 KB/sec)
Downloading: http://localhost:8081/nexus/content/groups/public/org/apache/derby/derby-project/${derby.version}/derby-project-${derby.version}.pom
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] jUDDI_v3 Parent ................................... SUCCESS [0.807s]
[INFO] UDDI_v3 WS Stubs and Schema Bindings Generated from WSDL SUCCESS [4.106s]
[INFO] UDDI Technical Compatibility Kit (TCK) Base ....... SUCCESS [0.877s]
[INFO] jUDDI Client side Code ............................ SUCCESS [5.744s]
[INFO] jUDDI Core ........................................ FAILURE [0.324s]
[INFO] jUDDI Core ........................................ SKIPPED
[INFO] jUDDI base-war Deployment ......................... SKIPPED
[INFO] jUDDI CXF Deployment .............................. SKIPPED
[INFO] jUDDI Service Registration Examples ............... SKIPPED
[INFO] jUDDI Tomcat Packaging ............................ SKIPPED
[INFO] UDDI TCK Tests .................................... SKIPPED
[INFO] jUDDI User Guide -(en-US) ......................... SKIPPED
[INFO] jUDDI Dev Guide -(en-US) .......................... SKIPPED
[INFO] jUDDI Document Packaging .......................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 14.467s
[INFO] Finished at: Tue Jun 14 14:49:38 PDT 2011
[INFO] Final Memory: 19M/1132M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project juddi-core: Could not resolve dependencies for project org.apache.juddi:juddi-core:bundle:3.1.0: Failed to collect dependencies for [org.apache.juddi:uddi-ws:jar:3.1.0 (compile), org.apache.juddi:juddi-client:jar:3.1.0 (compile), org.apache.juddi:uddi-tck-base:jar:3.1.0 (test), javax.persistence:persistence-api:jar:1.0 (compile), commons-codec:commons-codec:jar:1.3 (compile), commons-configuration:commons-configuration:jar:1.6 (compile), javax:javaee-api:jar:6.0 (provided), org.apache.derby:derby:jar:10.5.3.0 (test), mysql:mysql-connector-java:jar:5.1.6 (test), postgresql:postgresql:jar:8.2-504.jdbc3 (test), org.mockejb:mockejb:jar:0.6-beta2 (test), cglib:cglib-nodep:jar:2.2 (test), org.apache.openjpa:openjpa:jar:1.2.1 (compile), junit:junit:jar:4.5 (test), commons-logging:commons-logging-api:jar:1.1 (compile)]: Failed to read artifact descriptor for org.apache.derby:derby:jar:10.5.3.0: Could not find artifact org.apache.derby:derby-project:pom:${derby.version} in nexus (http://localhost:8081/nexus/content/groups/public) -> [Help 1]
The problem appears to be in the derby 10.5.3.0 pom which doesn't look valid:
<parent>
<groupId>org.apache.derby</groupId>
<artifactId>derby-project</artifactId>
<version>${derby.version}</version>
</parent>
Does someone have a workaround for this problem? Is it necessary to use this derby version?
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