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
