I inherited a big project, of which only a few packages are relevant to my work. I accidentally edited the wrong package today, and to avoid this in the future, would like to exclude them from netbean's project viewer (but not change them on disk).
Looks like there was an ignored folders property in older versions of netbeans (https://blogs.oracle.com/netbeansphp/entry/ignored_folders_sure) but I can't find this anywhere in netbeans8.1. Does it still exist?
Netbeans does not actually let you hide any packages that you have opened as a part of your project. One thing you can do is to select a package you do not want and choose to close it instead. After closing, you can "delete" it from your perspective. A dialogue will pop up and what you DO NOT want to do is also delete project contents on the disk, so be sure to unselect that option. :)
Related
Is there a way to change the icons for symbols suchs the C for classes and the M methods. They're a little hard to distinguish on my laptop. Ideally I'd like to change it throughout the IDE but fine if it's just for the project pane or auto complete.
The icons can't be changed via the UI as far as I know. It is however possible to change them manually. All icons used by IntelliJ are located in $IDEA_HOME/lib/icons.jar, where $IDEA_HOME represents the IntelliJ installation directory.
It might be possible to modify content of this JAR (by unzipping it, changing the icons and creating JAR from it again) and replace the original icons.jar with it. But change such as this will probably be overwritten during IntelliJ upgrade.
One solution would be to package the icons into a plugin. There is a Idea 11 Icon Pack plugin which does exactly the same thing you want. It is a JAR with the same structure as the icons.jar. Except two things:
It has plugin descriptor (META-INF/plugin.xml) in order for the JAR to be registered as plugin
It has implementation class com/bulenkov/idea/Idea11IconPack in order to register the icons I guess
I would use this as an inspiration. You can modify the descriptor so that there are no clashes in plugins, and change all of the old icons for your modified ones. One thing I'm not sure about is the implementation class. You could keep it and it might work. Or you could decompile it to see what it does and create your own version.
You can then install the JAR with the plugin descriptor by clicking Install plugin from disk button in the plugin settings.
Here is also a documentation for plugin development which might be useful.
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I use Eclipse for android development and trying to use IntelliJ. I have successfully run the application once. But now, I couldn't seem to rebuild the example Hello World application. What am I missing here? The R.java is not rebuilding anymore. Here is a screenshot of the errors.
And here is my setting
This happened to me because I've marked source folders incorrectly.
Under project settings once you click on particular module, Just check whether you have Mark any additional folders as source folders.
Check the screenshot, By default it should be something like below, All mark as buttons should be unchecked
By mistake I've checked Mark as: "Source" button and I got this error. Just uncheck it.
R and BuildConfig are autogenerated by the android build system. Maybe you somehow copied an autogenerated version of your eclipse project into the idea project and then idea generated second ones. By default, idea will use a folder called gen for these files which is marked as a source folder. Make sure there are no other source folder containings these files.
You can quickly find classes by pressing Ctrl+N and starting to type the name of the class. If you find duplicate results, delete any of them and let idea regenerate the correct ones.
Unfortunately you may not like my answer, but my project is due yesterday and I don't have time to check every setting to fix the issue.
The way I resolved it is to re-create a new project, only copying the src, res, lib etc across. This was painfully difficult and presents other issues (manifest files and run/debug configs) , but proved relatively short as opposed to creating a new project ANYWAY and sifting through build options that may or may not be valid.
I encountered the problem while trying to add the KSOAP2 libs to the IDEA project, and although KSOAP has nothing to do with the problem, I may have imported them in the incorrect manner the first time and created extra self referential dependancies. This makes the most sense, but trying to figure out how to undo it would be next to impossible.
you can try to delete the r and buildconfig files from the com/x/x folder under android -> java
that fixed it for me.
I have opened my project today and I noticed some weird icons beside my classes as in this image :
I don't know what that means !
when I run my application it works great, and I get no exception.
how can I resolve this issue
If you're using a Source Code repository like SVN or CVS (you might have checked out this project out of some code repository) your recent changes must have made your local workspace go out of sync.
By using different colour codes and icons, Netbeans is simply trying to inform you which of these files are in conflict with the repository and need to be merged.
Some of the other icons could simply be informative like that "play" sign on your .java files indicates that the file contains a main() method and can be executed.
You should not be scared at all, the IDE marks the different file types with different icons. Most of the IDEs have similar functionality.
I'm having two nb-projects.
One nb-project(a) has the other nb-project(b) as a library dependancy.
Now both nb projects compile/build fine, but the hints for (a) are out of sync.
This interferes when i want to run/debug saying 'one or more projects were compiled with errors'
I've tried
opening/closing both projects and recompiling
scan for external changes'
clean-build, removing the 'compile on save' flags for both projects etc.
en/disabling 'Build Jar after compiling' for the jtools project.
Removing the :
./netbeans/6.8/var/index
directory only made things worse for the nb-project(a)..
Now exclamation marks for all imports of packages from nb-project(b)
But still compile/build worked fine.
Even unit-tests within the same netbeans project in(b) didn't even recognize the root-package ?!
After some strugling its a bit better, but hints are still not correct in (a).
Now in (a) it says one method doesn't exist in project(b), but i've looked it up in the build-jar of (b).. it's there !?
Any ideas how to get the hints back on track?
Thanks
I've seen something like this when I upgrade a library but neglect to remove an earlier incompatible version from a path visible to NetBeans. Older JARs carelessly left in an extension directory are particularly troublesome, especially if they alias new entries you've added elsewhere. Also, review the Tools > Libraries dialog entries for duplicates and errors. Finally, check each project to be sure it's using the required libraries.
There are three ways to create dependencies in NB. You can add a project, add a library, or add a jar/folder. Only the "Add Project" button tells NB that the dependency is mutable. The other choices (Library and Jar/Folder) expect the jar will never change.
Try deleting the dependency on project(b), then add it back using the Add Project button.
I only use the Add Library for stable, third-party libraries (apache commons for example). I only use the Add Jar/Folder for third parties libraries I know I won't use anywhere else. Such as vendor libraries for communicating with a particular device.