Community
Participate
Working Groups
I'm using 3.0 load (May 2004). We just started using CVS plugin. We are able to check-out projects from our CVS server. However, these projects are not set as 'java projects'. It is definitely not obvious how to set these projects as 'java projects'. Therefore, we were not able to use all associated JDT benefits. Eventually, we have cleared this question through mailing list help. However, I still think that enabling/creating CVS checked out projects to become java projects should be made more intuitive. Below are details of what needed to be done for this issue. Maybe you can enhance current GUI interface to be better? ... Bosko Thanks Rich. Both steps were required. Initially, my .classpath was hidden (Windows XP), so cvs plugin was not able to pick it up. Once I resolved that one, things worked as you suggested. Rich Kulp wrote: > > 1) The very first time you check it out, Use Checkout As... and select java project. > > 2) After you do this once, when you check changes back in, make sure the . classpath and .project files are also checked back in. If they are checked into CVS, then the next time you check out the project Eclipse knows it is a java project automatically.
Move to Platform/CVS
This issue keeps coming up. Unfortunately, the proper solution, which would involved converting an existing project to a Java project, does not seem to be in the works. What I propose is to do the following: 1) When the user first does a Checkout (not Checkout as...), They are prompted to check for the existance of the .project file. They can choose Yes, No and remember my decision). This will allow users to avoid the overhead of the check for the file. The wording of the message will have to explain the significance of the file. Something like "Would you like to check for the existance of the project configuration file (.project) for each projects so that projects lacking a configuration file can be configured during the checkout?" 2) If the user chooses yes, the chackout operation will check for the exisitance of the .project file for each project. If a project is missing the .project file, the user will be prompted to use the new project wizard.
No time for this in 3.1
Hi, at least two of my friends couldnt figure out how to check-out our java project from CVS using eclipse and their first impressions was terrrible just because of this. The current context menu structure is definitely not very intutitive and helpful to java programmers (%90 of all eclipse users) So would you consider at least putting something like "check out as Java project" to CVS context menu as a quick fix?
Michael, do you suggest to use the approch in comment #2 ?
I think that comment 2 is a reasonable approach to solve the problem but other ideas are welcome. Unfortunately, I don't have time to look into this at the present moment so any help is appreciated.
A more basic problem is the fact it's easy to unknowingly bypass the Check Out As dialog so that users don't even realize such an option exists. Check Out As should be a default (offered) step in my opinion. The problem is that when you are asked what modules to checkout from the CVS, most people would enter in the module name and then press ENTER. But it's the Finish button and not the Next button that is in focus at that point. So Eclipse goes ahead and does the checkout and ends it there, and users will think that was the last step and they wouldn't have even seen the option to Check Out As or the subsequent Project Wizard. The Finish button should never be in focus by default until it's reached the last possible configuration page. A simple UI change like this will save hours of frustration for new users and lessen the stigma that Eclipse is difficult to configure.
Is this in the works for 3.3? It was assigned a long time ago but is still a common mistake that comes up on the newsgroups almost weekly.
It's not on the plan but we'll have a look if we can find the time.
Created attachment 62228 [details] Solution proposal
Seems to work if I select a single project but there are a few issues if I select 2 remote folders that lack a .project file 1) The prompt doesn't mention which folder is being checked out. It needs to since we can't prime the New Project wizard with the name. 2) The projects get created but the contents do not appear. This may be because I entered a project name that differed from the remote folder name but that should be supported.
Michale, please look at the following code in my patch (CheckoutProjectOperation#configureProject()). This code is copied from CheckoutAsWizard#getNewProject(). The problem is, that only first execution works correctly - I believe it is some kind of hazard, because adding Thread.sleep(2000) before removing listener made all patch works correctly. I cannot figure out why it does not work... final NewProjectListener listener = new NewProjectListener(); getShell().getDisplay().syncExec(new Runnable(){ public void run() { ResourcesPlugin.getWorkspace().addResourceChangeListener(listener, IResourceChangeEvent.POST_CHANGE); (new NewProjectAction(PlatformUI.getWorkbench().getActiveWorkbenchWindow())).run(); ResourcesPlugin.getWorkspace().removeResourceChangeListener(listener); } }); targetProjects[0] = listener.getNewProject();
I could be due to an asynchronous resource delta. I'm not sure we will be able to solve that nicely. Why don;t you focus on the single select case for now (i.e. if the user only selected one folder and there is only one target project. That would at least help a bit. After we get that code worked out, we can think about the multi-select case.
Created attachment 62646 [details] Solution proposal II Michael, here is the code that enables configuration only when one project is selected. But when checking out fast project by project, synchronization problem appears again. Maybe its a good idea to ask for API that allows getting IProject directly from wizard?
Created attachment 62647 [details] Solution proposal II (correct version)
Krzysztof, thanks for looking into this. Based on your findings, I think we need to push this off to 3.4 so we can add the required API to make it work properly.
This one has been waiting for a volunteer. Lowering the priority to the value appropriate for 'helpwanted' issues.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
