[Paul agreed to move this thread to the list.] Mossman, Paul (CAR:9D30) wrote:
[...] > > I'm pretty sure we'll need an Eclipse Classpath Variable that'll reach > the sipXecs build output. Let me know if you see how that can be > avoided. SIPXECS_BUILD is my thought. (SIPX_BUILD could eventually be > removed in favour of SIPXECS_BUILD/sipXconfig.) I promised Carolyn I'll clean up sipXconfig's Eclipse path variables. I'll do it today. BTW: It would be better id we looked for libraries in the places where they are "installed" not in the places where they are "built". It does require running "make install" or "ant install" but this is in line with how C modules look for ".h" file and "libraries". Alternative is to add direct dependencies in your workspace. But it would require having sipXcommons project open while you are working on any of the sipXconfig projects. Not sure if people would want it. > > Also for this issue (http://track.sipfoundry.org/browse/XX-6976) I'm > considering adding a getPhoneProvisionUser() method to PhoneContext, > since the Impl class already has a CoreContext member. There'll also > need to be a new Phone.getPhoneProvisionUser() method, so the plugin > Phone subclasses can access the info. > I think it makes sense. But - as always - it's really hard to say without actually looking at the code. Ping me with a patch when you have it coded. > The alternative is to start injecting CoreContext into Phone, and do all > the work there. Let me know if you have a preference, or other > suggestions. > > Thanks. > > -Paul > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
