always when I open some project(which already exists) in eclipse I get this question
should referenced projects also be opened where applicable
what does it mean, thanks in advance
You can define dependencies between projects in your workspace. Go to a project's properties and then to "Project references".
Using this feature only makes sense if projects are connected to each other. For example if you have different Django sites and you have one project for each installed app. When opening the site project, you could have Eclipse automatically open the apps projects, too. (For want of a better example...)
Related
I have tried to find these out, but could not.
Can eclipse open all dependent projects? I have a maven project with dependencies. Can eclipse open dependent projects also? (or at least try to, as some of the dependencies are external and would have no sources/project)
As a workaround to the above possible limitation in eclipse, i have created working sets and added projects to them. But could not see an option to open all projects in a working set one one shot. Is there such an option?
(Using eclipse Kepler)
Selecting this option should do it for you.
mark all project, right click and select open project
There are similar threads going on already but none talks about this specific question. Please don't flag this as possible duplicate.
I have got multiple projects imported in my eclipse workspace.
Lets say I have:
p1
p2
p3
p4
The option "Build Automatically" is also enabled. Now the problem I'm facing is that if I'm working on p1 and save any java file it builds all projects (that take a lot of time). I need other projects to keep open as I'm referring to those projects.
Now what I want is to build only the project in which I'm working; not all. Is there any possible configuration available? Also I don't want to disable "Build Automatically" feature and Build manually.
Thanks./
In response to the comment received from #Pace. I can actually check the progress and it is building other projects too. Check screenshot.
You could generate jar's from the other projects, and just depend on them. That should stop it from building the other projects. You'd just have to regenerate the jar's when you change something.
I've been told that an Eclipse workspace is the equivalent of a Visual Studio solution. But I've also been told that people commonly use a single workspace for all their work. Are these apparently conflicting statements correct? If yes, how do we then create and maintain the equivalent of multiple VS solutions in Eclipse?
Secondly, in the case of VS, I check in my solution (.sln) files, too, into source control. Correspondingly, should I or should I not check in the Eclipse workspace's .metadata folder?
I don't think, the Eclipse workspace is equivalent to the VS solution. An Eclipse workspace stores a lot of meta-information about projects, their physical location (possibly in or outside of the workspace folder), etc., and even workbench settings. It is not a good idea to upload this information into source control, as it is possible that other developer uses other physical locations for the projects, etc.
There is a similar concept in Eclipse to the solutions (similar, not equivalent): Project sets. It is only a GUI option to group your projects into sets. These sets cannot be executed together, and is only visible in the Project navigator.
Another way is to create multiple workspace folders, and you can use them as an alternative to solutions. The drawback of this approach is, that if you customize the IDE (e.g. by using Preferences, or by defining source control locations), these customizations have to be made in every workspace. This issue can be handled using the Workspace Mechanic tool (I haven't tried it, but it can migrate these settings).
The main reason why it is better FOR ME to have a separate workspace for a single project is performance and lucidity. With many projects within one workspace, you'd have to close the other ones because of shared classpaths for editor assistance. Editor uses classpaths of all projects for content assist, class hierarchy lookup etc.
Eclipse anticipates that the open projects are related. And when using project managers like Maven, one maven project is usually divided into many little eclipse projects. It's simply a best practice to have a separate workspace for a project. Second reason is, that usually you'd need to import another related project to see how things are done and it would be terrible mess then having it all in one workspace.
You definitely shouldn't commit the .metadata folder into source control. You commit only the projects inside. Because you and others then will check out the project only into their own workspace. But it is a question whether you should commit the .project file, because it's personalized and eclipse version specific and things like project nature (java, spring, maven nature etc.) can anybody set up by himself. .classpath files in the project should be committed to the source control, because they specify classpaths, it would be very time consuming setting it up again.
You can either group your projects in different workspace or in a particular workspace. Non can be harmful once you manage your settings properly.
In eclipse you can create a new directory for a sub-project under the root project and add to the build path like so:
I enjoy using NetBeans, especially for development with Maven, however, I've found recently that I've been working with three different branches of the same code base in different parts of the development cycle.
One of the things that Eclipse can do is separate the projects into different workspaces, so I can simply start Eclipse with the workspace containing my Maven projects in the production patch branch or the trunk depending upon what I need to be working on.
I'd love to accomplish this in NetBeans, but haven't found a way to do so. Any ideas?
I am using Mac OS with version 6.7.1.
There is the option of project group.
In File > Project group.
In here you can create a project group based on a folder location, so any projects underneath this folder will be considered within this project group.
When switching between project groups only projects within are displayed, and it maintains the current status of opened files, etc.
Switching between project groups doesn't require closing the IDE.
Given those options I believe this would be equivalent to the workspace switching in Eclipse.
I've found two things:
First there is a "similar" feature. It involves using the userdir switch on the command line. The downside being you would need to restart your IDE rather than switching while open. I think I can live with that for the time being. I found the technique here for Windows:
Create a shortcut on your desktop to the Netbeans executable: C:\Program Files\NetBeans x.x\bin\netbeans.exe
Right-click on the shortcut and click "Properties".
In the "Target" textbox, add the extra parameter to the very end: --userdir C:\path\to\new_workspace
Click "OK" to exit the Properties window and double click the shortcut. Netbeans will launch and create/load the workspace at that location
Secondly, someone has submitted a feature to allow for workspace switching (or in this case userdir switching) from the IDE itself. Perhaps this will be rolled into 7.0.
Well Netbeans has a group so you can create a group of projects which you want to say put in a eclipse workspace otherwise.
So when you switch a group it's like switching workpsace in eclipse
I know, that this question is old, but I found it on google, while I was searching for a tool like the following:
http://plugins.netbeans.org/plugin/20677/project-group-toolbar
With that plugin, you can load different projects in your projects overview.
So you can have two or more projects open and change to another "set" of projects.
Neither projects or project groups do not work in a similar way as an Eclipse workspace (yet) as far as I know. When switching workspaces in Eclipse, all the files opened will be closed and the ones in the new project will be opened. In this way, all projects work as one entity. The netbeans project/project groups do not work in that way. I hope there will be such a feature soon cause that really helps if you have many windows open and you switch between projects
I'm looking for solution and finally use Project Group solution, this feature has been improved and easy to use.
Userdir is a good solution at first (i tried to use it first), but "workspace switching" feature doesn't exists, so I have to use different shortcut for different workspace. Finally I used Project Group
NetBeans' equivalent is the "Project". In your project explorer you can right click on the current project and close it. Then go to File > Open Project and select a different branch. You will have to create a new project from each branch of your code.
Most of the work being done at my company is Qt-based C++, and it's all checked into a Subversion repository. Until now, all work on the codebase has been done purely with nano, or perhaps Kate. Being new here, I would like to take advantage of setting up Eclipse -properly- to edit my local copy of the tree. I have the CDT "version" of Eclipse, and the Qt integration, and the Subclipse module. At this point, though, I don't know what to do. Do I "import" the projects into an Eclipse-controlled workspace? Do I edit them in place? Nothing I've tried to do gets Eclipse to recognize that the "project" is a Qt application, so that I can get the integration working.
I would create a new QT project in eclipse, then switch perspectives to subclipse and simply do a SVN checkout into the new eclipse project. You should be good to go.
OK, I've been playing around with this idea, and it has some merit. I can switch to the "SVN Project Exploring" perspective (which I hadn't noticed before), and do a checkout from the head of the sub-project I want. I get a nice SVN-linked copy of the tree in my Eclipse workspace for editing. Eclipse even "understands" the classes, and can do completion on methods and such. However, I still can't get Eclipse to understand that the project is a "QT Gui" project, such that I could view the properties, and control the linking of the various Qt libraries and the like. By extension, it also doesn't understand how to build my project, like it would be able to do if I had created an empty Qt Gui project from scratch. How do I get this part working?
I have exactly the same situation at work (with CVS instead of subversion and the rest of the team using KDevelop but that's no big deal). Just start a new Qt Gui project using the Qt - Eclipse integration features and then remove all the auto generated files. Now using the "Team" features of eclipse and choose to share your project, enter the path to the repository and you 're good to go.
Checkout the project. It will ask you some options like if you want to start with a blank project, or want to use the tree to make a new project. Choose the latter and you should be ok :). It seems to work for me with Ganymed and subversive(not sure about subclipse and i don't remember.) :)
The only way I could get this to work was to check out the project with eclipse and then copy over the .project and .cdtproject files from another Qt-project. Then do a refresh on the project. This is a horrible hack but it gets you started.
You might need to define another builder for 'make'.
Second nikolavp - Checkout, and mark the option to use the new project wizard, then select Qt project. I've done this (with ganymede) and it successfully finds everything and builds correctly.
My solution:
go to the svn-view and add the repository location for your project
check out the project some temporary location with svn or any client you like
choose 'File->Import...' and say 'Qt->Qt project'
browse to the location of the *.pro file, select and hit the OK-Button
you are in the game with an appropriate Qt-project and Subversion Access for that project
I would say the same as the last one,
but instead of the two first steps I would set up the Qt-Eclipse integration:
Qt-Eclipse integration before looking for the *.pro file.