Marc, Just for the flip side argument -
I DO work locally, but my servers are ALL virtual machines I run, so there is no actual 'localhost' server. Just something to keep in mind ;o) Mark On Wed, Mar 5, 2008 at 11:57 PM, Marc Esher <[EMAIL PROTECTED]> wrote: > > Good question, Ronan. I need to get really specific instructions for > this into the plugin help as a top-level TOC item. Until I get that > done though.... > > <start preach> > Yes, the plugin was developed to be easiest for those working locally. > I worked for nearly 3 years with a shared dev server, and my good > friend and former colleague Mike Rankin pushed us to move to local > development. We resisted like crazy, but having made the switch, I've > gotten damn near religious about it. dev server development = bad, in > my humble opinion. So, in short, that's why it was developed to be > nearly brainless for those working locally. > > FWIW, I've always liked this article as a good (but long) explanation > for the reasons for developing locally: > http://www.ericsink.com/scm/scm_working_folders.html > <end preach> > > > But I do understand that there are times when you can't develop > locally. So, you have several options. From easiest to more > complicated: > > 1) put mxunit wherever your shared dev code lives. For example, if > your shared dev code is directly on the dev server, at D:\apps or > something, put it at D:\apps\mxunit. If your shared dev code is on a > san or nas, say at \\my-nas\alpha\, put mxunit at > \\my-nas\alpha\mxunit > > 2) confirm you can hit > http://dev.server.com/mxunit/framework/RemoteFacade.cfc?wsdl in the > browser > > 3) In MXUnit preferences, point the remote facade url to > http://dev.comain.com/mxunit/framework/RemoteFacade.cfc > > Almost done. the next part isn't all that tricky but it probably > warrants at least some short explanation. The whole purpose of the > webroot is for the plugin to figure out the proper "dot notation" for > the component path. So in your case, your CF Server sees the object as > "project.tests.classes.productsTest". So the plugin needs to pass that > "path" to your CF Server. The variable here is how you have the > project set up in eclipse, because that's going to determine what you > put as the webroot. > > For example, let's say you have \\my-nas\alpha mapped on your computer > as the "S:" drive. Thus, that component in question is pathed as > S:\project\tests\classes\productsTest.cfc. All we want to do is knock > the webroot off of the component path and then turn that into dot > notation. So In this case, "S:\" is your webroot, because after the > s:\ is knocked off of that full path, you get > project\tests\classes\productsTest.cfc, and then the plugin just > formats that as project.tests.classes.productsTest > > So hopefully you can figure out the appropriate webroot for your > situation. I just set it up exactly this way at work to test it out: > code on \\my-nas\alpha, S: drive mapped to that directory on my > machine, added mxunit to the \\my-nas\alpha\mxunit, and ran the > facadeurl at http://mydevserver/mxunit/framework/RemoteFacade.cfc. In > the plugin, I set that url as that facadeurl and s:\ as the webroot > and everything worked fine. > > now, should you still not have any luck with the "webroot" method, > then the easiest next step is to open up the project properties for > your project and then add the component root for your project. For > example, if in eclipse you have the project as s:\project, then in the > mxunit properties for the project add "project" as the component root. > Then, every cfc underneath that project will be prefixed with that > component root. So if the project is at s:\SomeWeirdPlace\project, and > the component root is "project", then a CFC at > s:\SomeWeirdPlace\project\tests\classes\MyTest.cfc will be turned into > "project.tests.classes.MyTest". > > Please give this stuff a shot and let me know if it doesn't work out. > > Best, > > marc > > > > > On Tue, Mar 4, 2008 at 3:30 PM, Ronan Lucio <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > bill[y] escreveu: > > > > > A long time in the making, los hombres at MXUnit.org (http:// > > > mxunit.org/) are proud to announce the first release candidate of > > > their open source Unit Test Framework and Eclipse Plugin for > > > ColdFusion Developers. > > > > > > > > > > > What about when developer server insn't the localhost? > > I have the same problem with cfunit. > > > > The Eclipse Plugin seems to have only two options: URL path for the > > framework > > and the local path to tests. > > > > I think it'd be nice if I can set the base URL to run the tests. > > i.e. If I set the base URL as "http://dev.domain.com/tests";, when I > > run the test "\workspace\project\tests\classes\products.cfc" > > it would run on "http://dev.domain.com/tests/classes/products.cfc"; > > > > Is it possible? > > > > Thanks > > Ronan > > > > > > > > > > > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
