Community
Participate
Working Groups
The Create Remote Project action should display the New Project wizard and pre-fill the name, location, file system, and not check "Use default location". In the case where the name is not valid for the OS Eclipse is running on, we should go through the name removing all non valid characters. ex. In case of C:\ make it C. This may require opening bugs against the platform if the wizard page doesn't have the ability to pre-fill what we require. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 RSE install : Dev Driver - java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
See the comment and requirements document on bug 207189 comment 11
(In reply to bug 207189 comment 12) > Requirement 3: "Create Remote Project". It sounds like what Martin is > suggesting (due to bug 181460) is to create a local project and link in the > remote folder. Am I understanding this correctly? If so, we might want to not > consider this a "remote project" but a local project with remote resources. I'm > not sure what sort of terminology to use in the "create" action. I guess what I'd really like to see is a truly remote project, where settings are also stored remotely. I consider the "solution" of creating a local project with linked remote resource(s) a temporary workaround only. I'd therefore keep the "Create remote project" terminology in order to avoid confusion. Or would that even confuse people more?
I only took a quick look at this when I opened it, but think we may have to open bugs on the Platform for creating new API's so we can specify the EFS implementation in the New Project Wizard.(In reply to comment #2) > (In reply to bug 207189 comment 12) > > Requirement 3: "Create Remote Project". It sounds like what Martin is > > suggesting (due to bug 181460) is to create a local project and link in the > > remote folder. Am I understanding this correctly? If so, we might want to not > > consider this a "remote project" but a local project with remote resources. I'm > > not sure what sort of terminology to use in the "create" action. > > I guess what I'd really like to see is a truly remote project, where settings > are also stored remotely. I consider the "solution" of creating a local project > with linked remote resource(s) a temporary workaround only. I'd therefore keep > the "Create remote project" terminology in order to avoid confusion. Or would > that even confuse people more? > I agree. I think the terminology of "Create Remote Project" is fine even if we are creating the project locally. Creating a local project is just a workaround that it not really well known. For 3.0 if we can't get to creating this action we need to add a cheat sheet or some form of help for the user to know how to Create Remote(Local) Projects properly. There are special cases where we need to create local projects. Java Project's for example. If we create a fully remote project running the application is not possible as all the compiled code is on the remote.
Here's another idea to work around the "create remote project" issue... what if the "Link into Workspace" wizard proposed with bug 207189 worked like this: * Select resource, Link into workspace * Dialog is opened with list of exsting project to choose parent folder * A "New" button allows to create a new project which is then the parent I think this would both solve the issue of having to have customizable new project wizards (since the wizard would always create an empty local project), and it would fix the "Create local project but with remote resources" issue. Only problem I see is that with complex new project wizards like those from the Modeling world, which create a lot of stuff as tmeplate, all the template stuff would reside locally rather than on the remote host.
(In reply to comment #4) > Here's another idea to work around the "create remote project" issue... what if > the "Link into Workspace" wizard proposed with bug 207189 worked like this: > * Select resource, Link into workspace > * Dialog is opened with list of exsting project to choose parent folder > * A "New" button allows to create a new project which is then the parent > > I think this would both solve the issue of having to have customizable new > project wizards (since the wizard would always create an empty local project), > and it would fix the "Create local project but with remote resources" issue. > > Only problem I see is that with complex new project wizards like those from the > Modeling world, which create a lot of stuff as tmeplate, all the template stuff > would reside locally rather than on the remote host. > Interesting idea, but what about in the future when we want might fully remote projects or don't want all the template stuff in a modeling project to reside locally, as I wouldn't want it to reside locally. Another idea is to have a special wizard where only projects that have defined a certain extension point show up. This way each project can handle the way a remote project should work. For Java creating it locally, but having the src folder linked to the folder the user selected. This way it's compiled files are in the workspace. PHP could have the contents of the selected folder all remote directly under the local created project. Downside is getting other Eclipse projects to create a plugin for this functionality. Similar to Mylyn Bridges. Then when the issue's with fully remote projects are fixed these plugins could be updated if it makes sense for those projects to be fully remote. The user can still manually create the project locally and then do link to workspace if the type of project they want isn't available in the Create Remote Project wizard.
