This thread is very useful for finding out which files in Netbeans should go into source countrol, but it doesn't cover all files.
In particular I'm wondering whether the following files should go into source control. Here are my assumptions/guesses:
nb-configuration.xml - easiest - the file itself in the comment says it should go into source control.
nbactions.xml - from what I see this file stores information typical to running the application. I.e. JVM arguments etc. So I suppose it is a question of taste - if you want other developers to have a "suggested" Run configuration - include it. Otherwise - don't. Correct?
catalog.xml - not sure what this does (I GUESS it's used by the editor to find out xml schemas and such to enable syntax coloring, but it's just a guess). Anyway - I see that this file has system-specific information (path) - so it shouldn't go into source control.
Can anyone confirm the above?
Thanks,
Piotr
I never put my IDE configuration files in the repository, for several reasons:
other colleagues may want to use theirs;
other colleagues may want to use other IDEs (such as Eclipse) and seeing those files (or even have to exclude them from the checkout) could be annoying for them;
some of these files are generally not related to a single project, others automatically generated, so no need to store them in the source code of every project.
In order to exclude them, our first solution was the .svnignore, but it was still logically wrong to modify some shared content for the specific needs of a single user, so we decided to be more strict:
in my ~/.subversion/config I have:
[miscellany]
global-ignores = nbactions.xml nbproject
Hope this helps,
Marcello
In my Maven based projects I put nbactions.xml into source control. Just make sure to change absolute paths to relative ones.
I put nbactions.xml into source control BUT there is a caveat: it's internal format can change so if your developers, for any reason, use different versions of NetBeans you could have to remove it because sharing it becomes nasty.
Recently I upgraded from NetBeans 7.3.1 to 7.4 and the "Run" action was giving a strange error message. I solved the problem by deleting and regenerating nbactions.xml: the old one had a custom Maven goal for the "Run" and "Debug" actions; it was org.codehaus.mevenide:netbeans-deploy-plugin:1.2.4:deploy it was not visible in the IDE v7.3.1 (perhaps it has been generated by an even older version for internal usage) and was generating a class not found for org.openide.util.Lookup in v7.4. I'm documenting the problem here because I found the solution by myself after an unsuccessful search on the Net. I hope this can help someone else.
Related
so I've seen this
How to prevent Eclipse from cleaning the bin folder for every build?
but I have a different problem. (i.e. if it was just resources, I could use that ability to copy them into place each time).
I'm generating files (ala sqlite databases) and they are getting cleaned up. I could move them around (and probably will eventually), but for now I want them within this structure for developing purposes.
is there no way to prevent eclipse from deleting these files (it doesn't seem to happen all the time, perhaps just on build error?), as I really need them to persist.
This is a solution for a different problem, but I think it would help here ;)
When generating resource files, (including DB files) do not put them into the /bin folder, especially if they are not going to change with every build, put them in a subfolder of your /src folder.
I have done so for webservice stubs, version numbers and other resources and regard it as the best practice.
If, however, you should decide to stick to your practice, take a look at the eclipse-generated build.xml file and modify it, making ant remove only the files you don't want.
I think the answer is in preferences
Java->Compiler-Building->Scrub output folders when cleaning project (i.e. not set, will hopefully find out soon).
I'm very surprised not to be able to open my Xcode project on another mac, I have never that kind of problem with Visual Studio or Eclipse. I have tried this Info.plist file "no such file" error but it's not enough.
I have other errors like MyAppViewController files not found in some folder whereas I checked that the files are actually there.
So how do I modify XCode 4 project so that it can be opened on any mac ?
Update: contrary to what is claimed here Duplicating / importing Xcode projects from one Mac to another copying isn't enough
Update 2: should I be obliged to buy that kind of tools to do so ? http://itunes.apple.com/fr/app/project-duplicator-for-xcode/id467950482?mt=12
Copying the files over is enough, as long as you copy all files over and no files are referenced from your project file using absolute paths.
Note that you don't have to choose to have absolute paths. I'm unsure of the exact details, but I've ended up with absolute paths in projects without doing so explicitly.
For example, here's a project with a missing file:
When I select the missing file, I can see that it's using an absolute path:
At this point, you have two options:
You can click the button in the bottom right of that red box I've drawn to find the file. Make sure you pick the right file; if you pick one with a different name, Xcode will happily replace DetailViewController.m with SomeUnrelatedFile.m and you'll have lost the hint about the original file. After finding it, make sure to pick Location: Relative To Group (usually, that'll be the right choice anyway) to avoid this happening again.
Possibly safer, go back to the original computer. For any file that you know is missing on the destination computer, pick Location: Relative To Group. Then copy everything over again.
I'm not sure if this is what you're after but it might help; I use git on to keep my two laptops in sync with a single project. I don't have any file missing errors and it comes with all those other repository benefits.
You shouldn't need any tools to do this, Xcode projects can be moved, shared between other members of your team and opened on any supported machine.
There must be another problem you have, so you need to post the error.
And when you get it resolved.... using a free remote source control service such as bitbucket, would be good for you to know and get into the practice of using.
I created a project "Sample Code"... here I just paste sample code... much of it is snippets that won't compile.
Is there some project-specific setting I can make so that Eclipse doesn't try to compile it?
I would prefer not to have the source code littered with red error markers.
Put your code in a non-java project, ie a general project.
Downside: you will have to create package directory structure (unless you can copy and paste from somewhere else).
Upside: it won't try to compile.
MY SOLUTION
ok, this is not an exact solution to my problem... but it is another way to do it and I kinda like it now...
I simply forget about using Eclipse to store the sample java files!
I found a good program CodeBox for Mac to store code snippets and I'm sure there exist such things for Windows, Linux too...
there interesting thing is that when I choose from this program to open the java snippet file (.java) in an external editor (Eclipse), it will open in Eclipse without any Syntax checking... wohoo! no squiggly lines
Because of this, it is not full blown code highlighting... classes and variables same color... but that's ok.. still quite readable. Much more than if it was in Eclipse with syntax highlighting running on it...
So basically, if you want to get rid of these red squiggles... one way to do it is don't keep sample .java (or other language) files in a project in Eclipse... simply keep them in the filesystem or code storage app and open them with Eclipse when you want to view them.
Depending on how you prefer to structure your project:
you could put your java files into a separate folder that is not configured as a source folder. There is an entry in the eclipse help on how to configure your build path.
or you can set exclusion-patterns in the build configuration, so that specific packages or files that follow a pattern you define don't get compiled.
Yet another way to handle your snippets could be to use a Scrapbook page.
Eclipse won't highlight anything in a scrapbook page but you can select code parts inside the page and execute them isolated. That's nice if you're experimenting and don't want to set up a whole class with imports and methods just to see if a specific snippet works as expected.
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.
I am SOOOOO discouraged. This seems so simple, but being a complete novice in Drupal and Eclipse PDT I have absolutely no idea where to look. My DAYS of searching seems to indicate that I am the only person on the planet with this problem.
Eclipse IDE for PHP Developers (1.2.1.20090918-0703)
WampServer Version 2.0
Apache 2.2.11
PHP 5.2.9-2
MySQL 5.1.33
Drupal 6.15
xDebug php_xdebug-2.0.5-5.2.dll
I setup my project in Eclipse to point to my Drupal directory (C:\wamp\www\drupal-6.15). I start the debugger (xdebug) and I stop at the first line of code. I can step through the code line by line -- so I think I am in the debugger, and when I terminate the app, I see the xdebug termination message in the tab heading.
But I cannot set a breakpoint in any of the PHP code files -- specifically a new .module file.
When I right click in the breakpoint column on the left in index.php (main) I see "toggle breakpoint" and the little blue circle next to the line of code...so I think I know how to set a breakpoint. But when I try to set a breakpoint in my .module, I see a menu that asks me to "add a bookmark" and no option to set a breakpoint.
Why can I not set a breakpoint in this file? Is my project path not set up correctly? Do I need to amend my include path? I can't get Eclipse to recognize even core modules not just site/all modules. I've seen posts about "importing" files into the project, and making sure the correct php.ini file is used for configuring xdebug. I'm lost.
There are so many posts about using Eclipst PDT and xDebug and they all end with "have fun debugging" or "just set some breakpoints and off you go" -- but what if you CAN'T set a breakpoint? Any ideas about where Eclipse is lost? Where in Eclipse can you get a list of files it has included in its build?
I think I just need to know understand why Eclipse cannot find these modules within the project (i.e. drupal application) path to allow me to set breakpoints. Then I think I can carry on. So discouraging...
Thanks to anyone listening.
Thanks for the tip. I think I had seen your similar response in another post somewhere.
Actually, the solution for me was to make sure to include all of the standard Drupal file extensions in the Eclipse file associations preferences: Preferences->General->Content Types->Text->PHP Content Type. The defaults are various *.php, *.phpX, *.phtml extensions, but not the extensions used in Drupal modules -- *.info, *.inc, *.module, *.install, etc.
Simple and obvious once you figure it out. I'm surprised with all the Eclipse-xDebug-Drupal setup instructions out there that this had not shown up. Lots of details about matching project paths with server paths, but nothing about this.
I hope my struggle helps someone. I did learn a lot about Eclipse PDT along the way :-). Good luck.
Breakpoints are tricky in PDT projects:
for php files, you need to be careful
One thing that gets me a lot is that there a lot of "invalid" places where you set breakpoints. You can put the dot there in the IDE, but the debugger won't stop at it:
blank/non-code lines
on switch statements
in some types of callbacks (for example, preg_replace)
But for breakpoints in .module files, this should be related to a setup issue.
I made the following changes to my setup:
Upgraded from php 5.2.1 to php 5.2.3
Installed the Zend debugger client in Eclipse/PDT (theoretically not necessary from what I understand, but I decided to give it a try)
Made sure that the Drupal files were fully imported into my project, not just referenced as include libraries.
I did that last step after I created a tiny test case and discovered that I could get the debugger to stop on a breakpoint in an externally included file only if that file was imported into the project, not if it was referenced as part of an include library directory.
To my mind this seems like a bug - the debugger could certainly see that the files in the include library directories were source files and it let me set breakpoints in them, so it seems that it should stop on them.
(For comparison from a separate (java) IDE, IntelliJ will let you define breakpoints in jar files as long as you tell it where the source is. Once you've defined it, it will stop on it.)
I think it was principally that last step that did the trick, so I'd suggest that anyone else with a similar problem make sure that isn't an issue in their setup first, and then try the other steps.
check whether you opened your java file in java editor mode.
ie ctrl+shift+R, in this popup check the button beside OPEN option and select java editor.
The problem of not being able to set a breakpoint can occur if you have recently created a file. You must close and re-open the file for it to be recognised as a source file that can be debugged, and to enable the code highlighting.