Egads! You're right - so why the heck did my Rampart build fail then?? Thanks for the catch; I'm going to revert this out of the 1.5 branch pending further discussion.
--Glen Andreas Veithen wrote: > Glen, > > Note that you merged the change from trunk to the 1.5 branch in r727458... > > Andreas > > On Tue, Jan 6, 2009 at 15:48, Glen Daniels <[email protected]> wrote: >> Hi Amila, >> >> The Rampart build was broken with the Axis2 1.5 branch, and Andreas >> clued me in that the problem was that change 727413 (adding the -lcmn >> option) hadn't been made on the branch. After taking a look at that >> change, I'm going to belatedly -1 it for Axis2. >> >> Here's my reasoning. First and foremost, the change was implemented not >> by changing the JavaUtils.xmlNameToJavaIdentifier() method (for instance >> by adding another override with a flag), but by simply not calling it >> unless the lcmn option was specified. This is seriously broken - it >> means that if we have a WSDL method name "Foo-Bar", we'll now by default >> codegen this into a Java method "Foo-Bar()"... which of course WON'T >> COMPILE. Second, almost as important, by changing the /default/ >> behavior instead of adding an option to invoke different behavior, we've >> broken all of our users' codegen builds if they happen to use XML >> identifiers which are uppercase or contain Java-incompatible characters. >> The fact that we needed to change the Rampart build to avoid a new >> breakage should have been a dead giveaway - there are times when >> incompatible change is inevitable and ok, but this was not one of them. >> >> Please revert this change immediately, and let's reconsider what you >> were trying to do with it on the list. >> >> Also, this points out the fact that nowhere in our tests do we have >> anything that tries various combinations of XML-to-Java to confirm that >> WSDL2Java does the right thing with XML names like "Foo-Bar", etc. I'll >> open a JIRA on that. >> >> Thanks, >> --Glen >>
