Admin user interface is in the works, I'm actually just starting it now. A lot of stuff will be borrowed some the juddi-gui mod as well as other existing stuff, so it should go pretty quickly. Again, we'll still need the code because it's primarily admin based stuff. The discussion is really, do end users really need access to it as a web service? Maybe, maybe not.
TCK tests shouldn't be affected by it. On Thu, May 30, 2013 at 9:49 AM, Tom Cunningham <[email protected]> wrote: > > 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? > >
