I have multiple versions of a single project in one project group. When I open the project in netbeans I want the projects view to show the projects named by the directory they're in.
So if I checkout projectX as projectX-1.2 that will be the name of the project parent directory AND the name of the project display name.
But what happens is the project display name is whatever is hardcoded in project.xml.
If I rename the project (right-click, select rename from the dropdown), netbeans will change the display name, but it will also change the deployment names - so if projectX creates projectX.war, renaming it to projectX-1.2 changes the war name to projectX1.2.war.
I can manually rename the project display by hand-editing project.xml
projectX-1.2
But what I'd like to do is set it to
${whatever-parent-directory-name-is}
So it doesn't have to be done manually won't contaminate anyone else's working copy.
Is there a way to set this when creating a new project?
I'm using netbeans 8.0
The best solution for your problem is to use version control tool to manage the different versions of your project. Use version control system like GIT (with github.com as reposotory for instance) or SVN.
Those tool are available in NetBeans and other IDEs like Eclipse.
In your case, you need to create different branches for the same project, you can work in each branch separately and then merge them whenever you want. It's also a way to keep the code of your project available online, in case you lose the code locally, it also allows you to work with a team of developers smoothly and remotely. So, I strongly encourage you to go for a version control solution for your development work.
Related
I frequently have multiple SVN working copies checked out. For example, I may have trunk-merge for merging branches into trunk, trunk-review to review other people's changes, and trunk-feature1 to trunk-featureN for work started. These all have the same repository URL.
If I import one of these projects into Eclipse (Kepler, Build id: 20130614-0229, Mac OS), that works fine. But I cannot import another one because these would have the same project name and Eclipse cannot handle that. To switch between my working copies, I now have to close the project, delete it from Eclipse, and import another one. Then Eclipse takes its 5 minutes to scan, index, and compile everything. In some older Eclipse versions I could use a symlink as described in
Eclipse Workspace/Project Setup Using Symlinks but that does not seem to work anymore on Eclipse Kepler (it resolves the symlink when importing the project).
I know that I could use feature branches on the trunk-featureN working copies, but often the features are not big enough for a branch, and eventually merging becomes a nightmare.
I do not want to use SVN switch on the workspace because in many cases the working copies will be modified.
How can I easily switch between (modified) working copies of the same project in Eclipse?
If you can't or don't want to change the project name based on the working copy (admittedly, that's a bit of a pain), then the best option is to use separate Workspaces. If you're not familiar with Eclipse's concept of workspaces, the gist is that a Workspace is a logical container of projects and metadata (eg, stuff you configure in the Preferences dialog). Projects that are logically part of a workspace do not have to be physically located in the workspace folder, although that's the default location when creating a new project unless you tell it otherwise. You can even import the same project into different workspaces, if you want.
In you case, I recommend using File > Switch Workspace... > Other... to create a new workspace in which to import a different working copy of your project. You can even export/import Preferences from one workspace to another.
Recently, my work computer was suffering hardware failures so I had the pleasure of migrating data over to a new computer. A project itself is much smaller than the generated output and a significant portion of time was spent moving those generated output.
Currently:
C:\workspace\Project\src\...
C:\workspace\Project\bin\...
Ideally:
C:\workspace\Project\src\...
C:\workspace_output\Project\bin\...
NOTE: For me the source is linked so they don't actually exist within the project.
I was able to change one particular project by following the directions here. However, I have numerous projects and it would be a fairly time-consuming to apply that change to each project (create an "output folder" then point the project to that folder).
Is there a better way to define this behavior within Eclipse? I couldn't find a ${PROJECT_NAME} system variable that I could use (e.g. something like this). I'm fine if the answer is NO as it appears that I have to manually set this for each project. Maybe the next best thing is to write a script to automatically create folders and modify the .project and .classpath.
An alternative like:
Start Eclipse on new machine, point it to the old workspace
Clean projects
Then copy projects onto new machine
Use Eclipse on new machine.
where I can cut out the work of "cleaning" the projects because they are already separate.
In general you'd want to use some kind of version control system or source code management, such as cvs, svn, git, Perforce, Visual SourceSafe, etc. Barring that, you can also use File > Export (or right-click on projects) to export a project or group of projects from Eclipse and it will, by default, exclude any derived content (such as compiled code). Then you can import those projects into another Eclipse workspace.
We want to share an eclipse Qt project via an SVN repository.
Of course we need to share the .pro file of Qt to be able to build the project.
The problem is, that without the project files you can not handle the project in eclipse but we cannot use the same as they contain local references.
Also it would be nice to use the Eclipse SVN plugin to manage this.
I already tried to check out the project and create a Qt project on Checkout but this overwrites the checked-out project file.
Any suggestion would be appreciated.
These are some lines from the .cproject file that are autogenerated, so I can not change the absolute paths:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry base-path="/usr/include/qt4" include="" kind="inc" path="" system="true"/>
<pathentry base-path="/usr/include/qt4" include="QtWebKit" kind="inc" path="" system="true"/>
...
There are 2 rules for Subversion (independent of Eclipse, should be the same all the time):
If the tool will regenerate a file, and you don't have to change it:
==> don't check it in your version management (may it Subversion, Git, CVS, ...).
If the file contains parts that are manually changed by a user
==> it should be checked into version management.
If you have the second case (not clear from your question), you should try to change the paths to be relative, so that others could use your project at the same location.
If you cannot change that, stick to the location in the file system. Every developer has to use an identical setup.
If you have to support different operating systems, and the files generated by the tooling are not compliant (shame on the tool makers), you should hold templates for all operating systems in your version management, and should initially (manually) make a copy, depending on the operating system you are working in.
If you have to change that file for some purpose, you have to change the templates as well and should remember that all developers have to make a new copy after that.
Sorry, I don't know Qt and have never developed in a C-environment on different platforms, so my tips are pretty vague.
Finally I found following solution:
No .cproject .project file in SVN!
Import the code files from SVN (also the .pro file for Qt)
Eclipse will ask you to create a project, so create a Qt Project with the same name (or some else, but you will then have to delete the files)
When the project was created, revert it (right MB on the Project in Project Explorer -> Team -> Revert) to the state of the repo checkout
Done, now you can work with the project
I am using a workspace for a new Xcode 4 project. Should the *.xcworkspace file be included in the main repository (along with the source files of the project for example)?
Thanks
Ross
btw. I am using GIT
Probably yes. The workspace is basically a set of projects, so if other developers would want to work with the same set, then you should put the workspace into version control.
If the workspace is strictly for your own use, or if there is only one project in the workspace, then maybe you don't need to put it into version control. But that means you'd need to recreate it whenever you move to a new machine or decide to blow everything away and start from scratch.
Xcode 4 is pretty good about putting user-specific data into folders/files whose names contain the word "user" or your user name, and putting build products and temporary files somewhere outside of the source tree, so in general, I'd put everything that isn't obviously user-specific into the repository.
Actually, Xcode uses some specific .gitignore settings. You might want to create a sample project, letting Xcode use Git (it's in the project save-as dialog that's the last step of creating a new project), then check out the .gitignore in its root.
I have a workspace with a dynamic web project in it. When I try to copy and paste the project into the same workspace, eclipse asks for the name of the new project, then it copies the files.
The problem I have is that when I deploy this project to the server it gets deployed with the original name and not the new name.
It looks like eclipse is not updating all the old name references when it makes the copy.
How do I make a good clean copy of an existing project?
After some more searching I found this in the eclipse bug site.
Steps To Reproduce:
create a Dynamic Web Project and call it "Project1"
copy and paste this project, in order to create another one which is a clone
of the first; in the "Paste" dialog, specifiy "Project2" as the name of the
target project (instead of "Copy of Project1")
OBSERVED BEHAVIOUR:
The context root of the target project is the same as the source project. This
could be a problem, but it can be easily updated in the project settings and/or
in the server editor (module tab).
However, even the module name is the same, while it's usually equal to the
project name. So, in Project2/.settings/org.eclipse.wst.common.component I find
the following:
This causes problems when deploying modules to the server. Moreover, the module
name can't be easily changed through the GUI from anywhere.
EXPECTED BEHAVIOUR:
The copy&paste operation should update the web module name to "Project2", just
like it happens when you rename a project.
WORKAROUND:
Make sure the module corresponding to the target project has not been added to
the server. Then, manually edit
Project2/.settings/org.eclipse.wst.common.component and change the deploy-name
attribute value of the wb-module element. Close and restart Eclipse (!!!) and
the new name will be taken. If you don't restart Eclipse, even if you edit
org.eclipse.wst.common.component from within Eclipse, WTP does not take the
change (it seems it's caching it somewhere in memory...).