accessing Coldfusion Components (CFC's) question

I haven't had any problems accessing my components (CFC's) when I use dot notation on my localhost, nor have I ever had problems using dot notation when I have a path mapping set up on a remote server. However, this (below) does not work when calling out components in an environment where a mapping is disallowed (shared environment, for instance, where you don't have access to CF adminstrator)-- I'm trying to get my process created in a way that doesn't require me to use full paths, for ANT builds, etc that can be ported to different machines).

Any suggestions for how to access components in a directory such as, for example, wwwroot/ApplicationName/Model/Components

where I cannot have a mapping setup? Is there a way to do this with CFOBJECT (in a modified format from below), or do I need to resort to CFINVOKE? If so, what would the path callout look like using CFOBJECT or CFINVOKE?:

<cfobject name="oContactData" component="ApplicationName.Model.Components.CFCmyprofile ">
<cfset qContacts = #oContactData.getMyContacts(SESSION.auth.SkillshowUserID, -1)#>

Looking for a modified line of the above code that works in a relative path manner-

Apollo -- check it out

Apollo Alpha has been released. I'm excited to try it out:
https://www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5Fapollo

Here is a nice look at some of what can be done for those interested:

Example presentation of Apollo (showcasing Ebay sample app)
http://www.demo.com/demonstrators/demo2007/91259.php

this is an older demo from Dec 2006, shows Apollo with Amazon's api's, Google Maps mashup with client-side address Vcards, and some other items (like Flex):
http://ajaxian.com/archives/adobe-apollo-demos

One intriguing thing about Apollo is that you can use existing web tech to build apps that interact with and run on the client This demo shows an application built using Adobe's Flex technology on the front end (View), and using Ebay on the back end to deliver data to the client. But that is just one incarnation. Apps could also be built with html+css and a database, and run equally well on the Apollo cross-OS runtime.

The API for synchronizing data online/offline, and accessing the file system, is what holds a lot of the power for developers (imo). I'm sure you can find other benefits. Apollo's APIs simplify the process for handling this. There are clever ways of doing it now ( dojotoolkit.org , etc), but they use Flash files, and other client side workarounds to get the job done, and are limited in the size, etc that you can save on the client (without changing preferences, etc).

Basically Apollo extends the reach of web dev tools (not having to write code in Java, C++, VB, etc, but instead using html, css, AJAX, Flash/Flex, etc.) to deliver applications that run on a user's machine as well as online. It enables web app developers with an extra set of API's along with a cross-OS runtime that they can use to extend the reach of their apps..... it has been developed from the paradigm of the 'mostly connected to the internet' that the world is moving towards.