I've realized that the Eclipse IDE puts all packages in a project (at least in a Java one) at the same level, e.g.:
However, browsing the file system, you can find that packages are treated in the expected multi-leveled way. Does this have any logical explanation?
This is just a presentation feature. You can click on the little down arrow you see on the left of your screen shot and select Package Presentation -> Hierarchical to have it like your filesystem.
You can see this answer for more information.
I asked the same question a couple of times and found the link in above answer helpful in order to change the presentation because it's an option hard to find.
About the Why part, I think it's because of Eclipse being DE-facto standard IDE for Android development and having the packages organized this way is more useful and it forces you to think about a way your classes are organized according to Android project guidelines. It also looks quite like help files on http://developer.android.com/guide to me personally. Also another argument for this might be that in old versions of Eclipse (pre Android time) default view was different.
Related
Is there any built-in way (or plug-in) allowing for searching through the whole variable tree without manually expanding nodes?
I can't understand why isn't it done by default, just as I can't understand, why isn't search bar built into Variables view (browser style) and this unhandy, inconvenient dialog is opened instead. It makes my work, which is mainly debugging complex applications, a nightmare.
The Eclipse version is Luna, if it matters.
The watch expression feature is not what I want because it just doesn't work in this case, tried to fix it but none of the common ways to do that help me.
Such a feature has been requested earlier here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=170396
You may want to reopen this bug to state your interest in this enhancement. And if you have experience in developing Eclipse IDE plug-ins, I am sure the maintainers would be happy to review a patch.
I usually use Alt+Shift+Right/Alt+Shift+Left and Ctrl+Shift+I to select and inspect variables and expressions, but this certainly depends on personal preferences.
I have to choose a sizable (but not too sizable!) project for my next & last term in university. I thought maybe a nice IDE for scala is what the world might need right now :).
Would you like to see an IDE specifically made for scala? Or are you more comfortable using (the already available) plugins for popular (mainly java) IDEs & editors?
What do you think about the whole idea?
P.s. I'd make it open source & would add features one by one, so if it doesn't end in one semester, it won't be a problem from the university perspective.
Actually, not anymore. IntelliJ, Netbeans and Eclipse all have Scala-specific efforts that have more man-hours in it than you could possible start to begin putting in at a last term. And there's two very interesting efforts that were results of projects like that, both of which were made to contribute to any IDE effort: ENSIME and Scala Refactoring.
And, beyond these efforts, most programming editors, such as jEdit or TextMate, also have some Scala support to one degree or another.
So, really, contributing to one of these projects might be a good idea, but making a Scala IDE is not.
For his Masters thesis, Mirko Stocker contributed the refactoring functionality to the Eclipse Scala plugin, see:
http://misto.ch/scala-refactoring-talk-at-scala-days-2010/
Instead of creating an IDE from scratch, why not contribute a major piece of functionality to the Eclipse plugin, all contributions are welcome. For ideas, see tickets.
Or instead of reinventing the wheel.. you can contribute..
http://wiki.netbeans.org/Scala
But I am not sure if it will be somehow enough for your university work. At the same time, as you see, those plug-ins still require a lot of work.
While writing your own IDE you will just trying to solve problems that were already solved and tested. Besides, even if - what kind of IDE is that, which allows you to do
Scala (even if its great) only. So just for simple xml edit of ant file or whatever you will need another tool.
I think Brian Clapper already summed it up nicely.
I'd suggest something like CheckStyle but for Scala might go down well and be reasonable to tackle as a project.
Not a Scala developer but an Eclipse plug-in would probably be a worthy senior project.
Concur. Operating systems, text editors, and IDEs...does the world really need more of them? No. But everyone wants to write one.
If you want to do something useful, as opposed to simply academic, develop an extension for an existing IDE. Eclipse, NetBeans, Komodo, etc. are all nicely extensible through plugins.
I'm evaluating the possibility of developing an Eclipse plugin to modify the source code of some Java files.
The Eclipse plugin should:
add one menu option or context menu option to launch the modification process.
add a key binding
only alter the UI in that way when an editor has been open on a Java file.
the modification process would not open a dialog, or maybe, a very simple one.
the modification process would traverse the AST of the Java file and would modify it.
Considering that we have no experience with Eclipse plugins and we need spend time in reading docs, how much time do you estimate in developing that plugin?
Thanks in advance.
It's really not that difficult at all... I had students in my design patterns class doing it for an assignment (adding/removing javabean getters and setters)
See http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_manip.htm
[EDIT: added the following article reference]
And a great article on it at http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html (from 2006 -- there may be a few API changes since)
Yes, writing plugins takes a little getting used to, but so does any API.
And you can modify the AST -- see the page I reference above.
(I should note that the above link is from the eclipse help, which can also be accessed via Help->Help Contents inside Eclipse -- there's a lot of good info in there, but it's just a starting point)
You'll probably spend quite some time cursing the complexity of the eclipse plugin system. There are some example plugin development projects that can be very helpful if they cover the area you're working in.
I'd say you're looking at 2-4 days of work, spent mainly getting familiar with the platform - someone with a lot of experience writing eclipse plugins would probably take no more than an hour.
However, your step 5 could be tricky. I don't know how easy it is to access and change the Java AST; my experience is based on developing an editor plugin for an exotic file format rather than Java code.
Well, the four first points are easy to achieve, even by monkey coders that look at the eclipse PDE documentation shipped with Eclipse. These can be achieve in 1 day of work, maybe 2.
The hardest point is really the fifth one and the kind of modification you expect to do. Acting directly on the editor content is simple, accessing the editor internal AST and modifying it is really a bigger challenge and I doubt that it could be achieve in less than a week by unexperimented people (it can take longer, depending of what kind of modification you want to apply).
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a coworker who is looking to switch from InteilliJ Idea to Eclipse, and is concerned about not knowing the Eclipse set of commands.
I was wondering - would anyone have a link to keyboard mappings that can set Eclipse commands to at least sort of match Idea?
Have you made this switch? Any "gotchas", tips, or info we should be aware of?
Thanks!
I went through the experience myself - and result was a series of articles on my blog:
http://virgo47.wordpress.com/2011/01/30/eclipse-vs-intellij-idea/
http://virgo47.wordpress.com/2011/02/22/from-intellij-idea-to-eclipse-2/
http://virgo47.wordpress.com/2011/03/24/from-intellij-idea-to-eclipse-3/
http://virgo47.wordpress.com/2011/02/28/why-to-synchronize-with-svn-in-eclipse/
http://virgo47.wordpress.com/2011/04/10/from-intellij-idea-to-eclipse-4/
http://virgo47.wordpress.com/2011/06/28/from-intellij-idea-to-eclipse-5/
They are all biased towards Idea (obviously) but full of relevant Idea-Eclipse comparisons, keyboard shortcuts, little stories and observations. In generall, they are both very good IDEs, but if IDEA is 100%, Eclipse is 90%, maybe even 95% - with biggest these differences:
different mindset is needed, Projects, Modules, Workspace may mean different things or are not used at all in one or the other IDE, you have/need Perspectives in Eclipse, not in IDEA, etc...
quality of default Maven/SVN support is better in IDEA (it is also built-in), much smoother and less problems + 3way diff in IDEA is just great, generally Eclipse guys are so scared of merging - and now I understand why
IDEA is far more polished, less graphics glitches and much better default colours for highlighting, etc.
free version of IDEA does NOT have so many things as you can have with Eclipse with all possible free plugins - Eclipse plugin ecosystem is just so big!
IDEA is just way smarter in margin cases when it comes to completion, refactorings, and these other little things where IDEA was the top of the class the whole time since 2000
I was lucky I didn't have to convert in the end because we use Maven projects that work just fine in both IDEs. However I still use Eclipse for other projects (xtext).
Get the plugin from here. It seems easier to install than the one in Bartosz' answer, plus no 404s...
For the lazy: direct link to plugin
Drop the plugin jar in eclipse/plugins folder and restart eclipse. Now in preferences dialog under General > Keys you can find "Intellij Idea" key scheme.
If he definitely want to do this:
http://www.jroller.com/ervines/resource/eclipse-intellij-key-bindings.java
In answer to Bartosz, flash builder is a good reason, until jetbrains comes out with a visual mxml editor.
the direct link posted above is outdated, releases are here: http://code.google.com/p/ideakeyscheme/updates/list
Update: Found this one too: http://www.bharathganesh.com/idea-prefs.php , although it's pretty light on the description.
I could list a bunch of tips, gotchas, etc. because I've made the switch several times. I've tried to make the switch to Eclipse several times but couldn't do it and went back to IntelliJ.
First tip:
Intellj "project" -> Eclipse "workspace"
Intellij "module" -> Eclipse "project"
Second tip:
Eclipse has the concept of "Perspectives" which means it reshuffles around your UI when you're doing different things, like for debugging there's the debug perspective. I don't quite get this, I personally prefer the concept of windows, or the tool windows that dock to the bottom or sides.