I don't see many reasons against removing the juddi-api but maybe it makes more sense to wait to remove it till a replacement is available in the administrative user interface? The backwards compatibility argument seems a lot stronger if you have a replacement in hand.
Is removing it going to affect any of the tests? I can't remember if any of them are using it in setup.
On 5/29/13 7:50 PM, Alex O'Ree wrote:
A while, I had a conversation with Kurt on IRC about possibly deprecating and/or removing the jUDDI API web service from the 3.2 release. I'm personally for this decision and would suggest removing it (from the juddi-client and uddi-ws package) as there's isn't much value added to it from and end user's perspective. They are all administrative functions. I would suggest as follows: 1) remove the juddi API web service references from the client and uddi-ws package 2) repackage the juddi API web service client side stuff as a seperate jar file, just in case anyone needs backwards compatibility. 3) continue to deploy the web service within juddi-war 4) continue to build an administrative user interface. See JUDDI-455, JUDDI-579, JUDDI-607. This will greatly aid system administrators. These functions can simply reuse the code from jUDDI API web service 5) finally, document the changes This is open for discussion, but I just wanted to get the ball rolling on this one. Any thoughts or opinions on this?
