Indeed. Point taken. thanks Mark. On Thu, Mar 6, 2008 at 3:54 PM, Mark Mandel <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
