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.
Related
I am trying to run an Xpage locally (in Chrome if it makes any difference) from a local NSF and am receiving the error:
Build path contains duplicate entry: 'org.eclipse.jdt.launching.JRE_CONTAINER'
I have copied all the ExtLib Features and Plugins to the correct directories as required.
Anonymous is set to Author.
I cannot find any information on how to resolve this. There was an open ticket on OpenNTF 6 years ago but no resolution.
[Update]
As Jesse Gallagher pointed out on Twitter, you can access the .classpath file without going through the ODP setup via the Navigator perspective. I would still recommend setting up source control since it gives you:
local change history in DDE (even if you don't use the ODP in git/hg)
the ability to track any changing file during development, aka- a rogue change to your .classpath file (I recommend installing Cameron Gregor's Swiper plugin)
is fairly easy to set up
as a developer, version control is the best way to cover your butt
[/Update]
I believe you quite literally have a duplicate entry in your NSF's build class path. This has to do with the Eclipse version Domino Designer is based on is being confused by its defined class path. I recommend the following:
if you don't have it set up already, set up source control for your NSF
open the (hidden) file .classpath, which can be found in the root of your On Disk Project (ODP) folder with a trusty text editor (Notepad++, etc.)
search for org.eclipse.jdt.launching.JRE_CONTAINER
if you find more than one, you will need to deconflict your class path (aka- remove one; it may be best to make a backup of the file)
if you don't have "Build Automatically" checked (in your Project menu), you may need to open Package Explorer and right-click your ODP, then perform a "Sync with NSF"
You should be able to de-conflict your build path via the Project > Build Path screen, but this is an easy way to search the whole thing in one shot.
Here's an example the .classpath file from a working app.
An example of a situation where others (using gradle, in this case) ran into a duplicate issue with org.eclipse.jdt.launching.JRE_CONTAINER.
Setting up source control with an NSF, right-click NSF, Team Development, Set Up Source Control:
Note: If you need a little more info on how to set up source control or want to know more about where to park the ODP (aka- if you haven't done this before), I recommend checking out David Leedy's Notes in 9 episode 131: Using SourceTree for Better XPages Source Control. Even if you don't use SourceTree, it's worth it to understand that the ODP should not be placed in your Notes Data directory, etc.
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.
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
What do I have to do to copy a complete workspace from one computer to another and be simply able to continue working on it on the other computer?
In general, a filesystem copy should be sufficient. If you run into problems with your projects, try removing the project from the workspace (without deleting the files) and then re-add the project, which will rebuild the metadata.
Make sure you shut down eclipse before you copy the workspace, and that the target computer has the same (or higher) eclipse version, including the same plugins.
Check that your workspace actually contains all the projects - when creating a project, it's possible to have its files situated outside the workspace.
If your projects use any external libraries installed on the system, install these on the other system in the same place (or adjust the paths).
Then, there should be no problem.
You shouldn't have any issues with a straight filesystem copy as long as your eclipse versions match up.
If they don't, the project metadata may not load correctly
You need to copy the whole folder which you select as your workspace at startup (or you once selected). All settings are included in there (even the opened files).
I use rsync for this. Works great.
I've used Clint Harris' tutorial to set up code sharing between projects, and everything works just as expected on my computer. But on my co-worker's machine, it seems the compiler doesn't find the header file from the static library project when he builds.
My co-worker got my project by cloning a git repository. We've gone through all relevant build flags and XCode settings n times, but the project simply refuses to compile on his machine.
This is what I asked my co-worker to do, mostly copied and pasted from the tutorial:
Make sure there is NO blank space in the complete path to the projects' directory.
Inside the projects directory, create another folder called "build_output".
In XCode, under “XCode > Preferences" choose the "Building” tab and set “Place Build Projects in” to “Customized location” and specify the path to the common build directory you created.
Set “Place Intermediate Build Files in” to “With build products.”
Choose the “Source Trees” tab and create a new Source Tree variable by clicking on the “+” button and filling in the columns. In both "Setting Name" and "Display Name", put
[the name of the shared project which created the static library]. In path, you put the full path to the framework folder.
Following these steps, the project that uses the static library should compile the same on his machine as on mine. But it doesn't. Basically, the error he gets is:
error: TheFrameworkHeader.h: No such file or directory
and then a string of other errors caused by the missing header.
Any strategies for trouble-shooting this? Or anyone who had a similar experience and could share some hard-earned knowledge? Is anything missing from the instructions I've summarized? Do I need to set the roles of headers in the Copy Headers build phase when compiling a static library?
Despite some helpful advice, I never figured this one out, but here's a little info for anyone in a similar situation. I created the library and dependent project by splitting an original project into two. At first, the library and application were just two targets within the same project. Later, I moved the app to a separate project. Everything seemed to work, and I pushed both projects to remote git repositories. When these were cloned on other computers, however, the library headers were not found.
Later, I discover that the same error occurred when I cloned the projects on the original computer. After a lot of struggle, I pinned it down to one scary detail: the name of the dependent project's folder! (That is, the project with the application, not the library.) Not the name of the .xcodeproject package, not the application identifier, but the name of the containing folder. As soon as I change that, everything works. If I change it back to the original name (on any computer), again the headers are not found.
If anyone has any insight on this, please post an answer!
EDIT: Since I posted this, the same problem occured with another project, and again, merely renaming the folder that contains the .xcodeproject folder fixed the problem.
I don't think it is Git, I think it's xcode. I got a very similar problem here, where xcode / xcodebuild resolves an include path falsely (making it a simple .) With the exactly the same library project and xcconfig files (clean checkout from svn repo) but another containing folder - it works. So, thanx for the solution and don't blame Git anymore ;-)
I often forget to check this: are you sure that the missing file (i.e., TheFrameWorkHeader.h" is in the git repository? It may well be that your build settings are correct, but the file somehow did not get added to git correctly.
If you're having trouble building on a particular machine, then the problem likely is a machine or user setting. Such as an environment variable (perhaps INCLUDE_PATH or one of its relatives -- XCode uses GCC). You may have a "." in one of these variables.
The best way to fix this would be to add the needed folder path to the -I switch in the build script.
Double check that the "Search Paths->User Header Search Paths" build setting (for all configurations) points to the directory containing the shared Xcode project (you can use the new Source Tree variable you created).