I've been going nowhere but in circles trying to understand the odd relationships between and varying levels of "standalone-ness" of these tools.
I've been using Aptana Studio on OSX for about 4 years and been happy with it, however my recent update to 3.6 blew up so many things I ended up rolling back to 3.4 just so I could work.
For better or worse, I do like Aptana, but I'm not bound to it and am now very frustrated with the latest version, specifically that all the python stuff went haywire. Searching for help is painful, as threads and advice are many years old.
So, in way of questions:
can anyone explain the relationship between Eclipse, Aptana, PyDev, and LiClipse? And more importantly:
a recommendation that meets the following criteria
What I need/want is:
something free and open source
with a current and active community
easily themeable with dark colors so I'm not staring at the sun 8 hours a day
tight python features (pep, pylint, ability to jump to references with a keypress, etc)
tight html/css/javascript features
Like I said, I do like Aptana, just frustrated in the apparent lack of a current community and how it seems to be falling apart.
Well, I'm not sure this is a good question for stackoverflow... anyways, I'll try to explain how it goes:
Aptana Studio 3 is an IDE which is currently supported by Appcelerator. Their main focus is currently on supporting the Appcelerator mobile platform (actually that's Titanium Studio, but Aptana Studio 3 is the basis for it -- the languages they aim for are html/css/javascript, which is what's needed for Titanium)... Although they do integrate a pretty old version of PyDev too (as PyDev requires a newer java whereas they're still on an older version of Java, so, I guess it's currently hard for them to keep it up to date).
Back in the day, they supported the development of PyDev, but decided to stop that support some time ago -- there's a bit more history at: http://pydev.blogspot.com.br/2013/03/keeping-pydev-alive-through-crowdfunding.html.
After that, LiClipse (http://www.liclipse.com/) was created out of my frustration to support dark themes and have support for more languages (it was a crowdfunded project -- it should've been an open source project, but didn't reach its goals for that, so, in the end it's closed source, and its revenue is a part of what keeps the PyDev development going on).
And at last, Eclipse is the basis for both platforms -- so, external plugins should integrate nicely into any of those.
Now, on the recommendation front:
LiClipse should meet your dark/python/html/css/javascript issues (its focus on the editors front is on being dark-themed/lightweight and easy to add support for new languages), but it's not completely open source (some parts of it have been made open source though: http://www.liclipse.com/text).
Aptana Studio 3 should still work and give support for the dark/python/html/css/javascript too, but given that they have to convert some things from the PyDev Java to its own version, Python support is always a bit outdated (as for the current community/support, I can't really comment, but I guess you should be able to report problems to them to try to solve the issues you have).
And the other choice (which may be a bit more work to configure) would be using a bare Eclipse and installing PyDev and separate plugins for html/css/javascript (it seems there are multiple available, but I can't really comment on any of those).
Related
I am a backend developer working on a cocktail of JVM based languages(mostly Java). I have been using Eclipse IDE for nearly 4years until a week ago I was mandated to use IntelliJ. I had a look at IntelliJ documentation to figure out the advantages it offers for me over Eclipse,Netbeans,STS etc but it was information overload. Currently I have changed the keymap to Eclipse. I believe IntelliJ has lot more potential which is waiting to be unearthed. What specific advantages does it offer w.r.t exposing/testing REST API, connecting to NoSQL DBs,refactoring code etc over Eclipse.
I won't be able to produce a detailed comparison matrix between IntelliJ and Eclipse but, for me, here are the most common things I miss when using eclipse on the workstation of some colleagues:
code navigation only with the keyboard
refactorings and their associated shortcuts (unlike Alt+Shift+L, Ctrl+Alt+V is actually "smart")
efficient "Find usages" (Ctrl+Alt+F7 or Alt+F7)
While debugging, real code edition with autocompletion (watched, code expressions, code fragments)
The new debugging visualization right in the editor (introduced by IntelliJ 14)
So are only the few things I use when helping colleagues. I'm not even talking about smart autocompletion, property files,
I admit that since I switched over to IntelliJ (~5 years ago) I never dove again into Eclipse. I'm sure they've improved a lot since but, from what I see on a daily basis with some coworkers, I'd rather stop programming than using Eclipse =D
Give it a real and serious try. There is a small time needed to got used to it but once you learn the key mapping and most of its productivity features, I'm almost certain you won't regret it. So far, I know nobody who has.
I am working on a standalone Eclipse RCP product. My team replaced another team that wrote the infrastructure of the product.
I and my team leader aren't very happy with the Eclipse RCP framework because we feel that it is just very hard to get it to work correctly.
This is because:
The GUI building tools are annoying. XWT is buggy (bindings don't
always work, can't add scrollbars, and this is only the half of it).
SWT also isn't very exciting. I don't like the API and it doesn't
have too many exciting widgets.
Eclipse IDE itself is buggy (we
have to restart it every few hours). We are using eclipse juno. When
we tried to upgrade to luna we ran into some unsolvable issues:
Eclipse Luna: Handlers' #CanExecute methods not called due to wrong context
We have lots of weird bugs (e.g. eclipse looks at wrong selection
service and much more).
Even though there is support and
documentation, we find that it is kind of poor compared to other
solutions out there.
Due to the above, developement of simple
things seem to take too long. We have another .NET product which is
much easier to write.
However, google didn't seem to badmouth eclipse rcp... So I wanted to ask, what do you guys think about it? Do you find it easy to use? Do you find it flexible?
Just want to hear some opinions.
Thanks!!!
Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?
It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.
There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:
"The performance test were turned off because the Eclipse platform team has a serious resource issue."
For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:
"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.
The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?
This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)
This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)
On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):
"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"
3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?
lucid (10.04 LTS)
Eclipse 3.5.2-2
precise (12.04 LTS)
Eclipse 3.7.2-1
raring (13.04)
Eclipse 3.8.1-1
saucy (13.10)
Eclipse 3.8.1-4
trusty (14.04 LTS)
Eclipse 3.8.1-5.1
utopic (14.10)
Eclipse 3.8.1-5.1
Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:
And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).
I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?
Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.
Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue.
On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.
Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions.
There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.
One year and three Eclpse releases later these serious performance issues are still fixed.
Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5.
If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.
From the official Wiki page:
Several major performance defects have been addressed in Juno SR2
(4.2.2). Community members have confirmed that these fixes
substantially address the performance problems with editor and view
opening, closing, and switching. These fixes are widely available in
Juno Service Release 2 (February 2013). All defects are also resolved
in the Kepler (June 2013) release stream.
new Features
Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.
While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...
We're developing an Eclipse-based RCP. Recently we've updated to Eclipse Juno and currently we focus on quality, which of course brought automated tests into focus, since the application is quite big and the testing effort delays releases.
We're already writing JUnit tests, but I'm more interested in UI tests. With older Eclipses this would not be a problem. There are plenty of good test frameworks around. Unfortunately with Juno everything changed due to the added ability to switch out the default SWT UI by Swing or JavaFX (at least this is what I've understood about the changes causing problems)
So most of the test tools don't work properly anymore. From past experiences it seems that:
SWTBot seems to get not much love lately and is very unstable (can't find elements in certain versions)
Window Tester seems quite good, but has a lot of problems identifying an element during the test run (especially with pop-ups such as content assist or tool tips)
Apparently Froglogics Squish supports Juno, but since a license costs about 2,5k Euro I have to pass
The same seems to be the case for QF-Test (too expensive).
This leaves Jubula (or GUIDancer, which is the commercial Jubula), which we've tried in the past, but which had similar problems as Window Tester and SWTBot (unstable in terms of changes to the Eclipse platform and difficulties to detect some elements)
I need to know, which tool to focus on / trust in. Does anybody have experience with one of the tools or is even currently testing a Juno RCP (or Juno itself for that matter)? Or does anybody know how Eclipse tests their own platform (if they even do it atm)?
Searching for information related to "test", "Juno" and "UI/GUI" only brings up the commercial products.
For me it is important, to find a tool, where I can use the developed test cased even in future releases, which means: A framework project, which has some support of the community to be able to adapt quickly. Also it is important to also find stuff like tool-tips, overlays or content assists/suggestions) - similar to a Selenium compared to basic HTMLUnit.
At this point I don't even care too much about integration, reporting or compliance to standards..
You can find a comprehensive table of GUI-Testing tools in the Eclipse Wiki:
http://wiki.eclipse.org/Automated_Testing#UI_tests
One important decision you have to make is, if you want to use your mouse to record/create tests (Jubula, QFTest, ...), if you want to be able to hand-write test-code (SWTBot, ...), or if you want to be able to do both (WindowTester Pro, ...).
Eclipse Juno is rather new, and I would expect problems with all of the listed tools, however the migration should not take that long since most of these tools mainly focus on testing SWT-widgets and Juno still uses SWT. So far I have not heard from any RCP Application seriously using JavaFX other than for technical demos, but I would be curious to see them!
The problem I think, is rather that testing Eclipse is hard and GUI-testing is especially hard.
You might want to have a look at this study which finds and explains the major problems:
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-010.pdf
If you believe this study, JUnit-testing is usually preferable to GUI-testing. Well, with Juno you have the big advantage that Unit-testing Eclipse now is easier than it ever was because the framework switched from inheritance and singletons to dependency injection, which makes it far more testable.
I'd suggest you too look at Xored's Q7, which is used for GUI testing of some of Eclipse projects including Eclipse DLTK, Eclipse LDT, Eclipse Tigerstripe and the tool is just perfect : it let you develop dozens of UI tests per day per engineer, and do not have stability and incorrect-recording problems. It's designed specially and only to test Eclipse-based apps and obviously the best in the niche.
However it costs money, which can be a blocker for you (like squish), but they have a free Community version, which is enough for most of use-cases. As well as those Xored guys just introduced pay-per-testexecution pricing model -- the tools will be free and you have to pay as you go only per tests executed monthly (less than 5000 is free). More about new model is here eclipse-testing.com
The Eclipse Visual Editor project seems to be dead, no commits, no updates. Any one know what is happening?
Update 2: The project has been archived (i.e. dead) since June 2011 again.
Update: The project has been revived and is now under active development again.
Its pretty much dead due to a lack of developer support. Here are some recent posts from their mailing list talking about a lack of movement on the project.
What's happening? It's called NetBeans, and it's already happened.
I'm going to get voted down for this but they know it's true. I love eclipse and have used it religiously since I started Java. I'm not saying I like Netbeans, it's just all I hear whenever the concept of a Java visual editor is brought up.
The Jigloo plug-in for Eclipse is a pretty great alternative to the Visual Editor. Though still not quite as nice as the Netbeans GUI editor it is fairly robust and fully featured, especially compared to what was available in the Visual Editor plug-in. Definitely should give it a shot.
Actually NetBeans has gotten MUCH MUCH better. I've used Eclipse, Netbeans and IntelliJ for a few years each, and NetBeans is at least as good (performance, usability & features) as the others now.
It's also improving more quickly than the others are.
They have people working full time on alternate language support, so you'll find they have the best Ruby support in the industry, and I believe Python is about to become that good as well.
Of course, Eclipse still has that crazy-cool todo list that remembers which files you worked on for each bug and can take you back to the set of files/edits for any bug you've worked on, that's really amazing to use and I don't think it's available on either of the other platforms.
--- Revision from years in the future ---
I have used Netbeans more and really have to give the award to Eclipse. The difference has been in vertical programming environments--most will target Eclipse and ignore netbeans. You rarely need these, but when you need them there is often no way around them. If Netbeans does have an equivalent, it's often buggy to the point of not being usable, generally the biggest issue is emulator support.
You won't run into these unless you are working in a specific industry--Android development is one, the primary drive was to support Eclipse, NB seems to trail. Another I've worked on is in the TV/Cable industry.
For raw java development, however, I'd still give Netbeans a little edge because it's the environment that was targeted and supported by sun.
Visual Editor is doing a new release, 1.4, on September 16. Installation instructions for the RC are here:
http://wiki.eclipse.org/VE/Update
FWIW, the project did stall for a while. But there is a new, and relatively diverse group of folks working on it again. Most of the recent work is concerned with making the new release compatible with Eclipse Galileo.
It's officially dead as of May 2011. It's archived here, but slow to download and tricky to install. Instead, there's a new editor, WindowBuilder Pro.
Currentlty Google have Open Sourced the Windows Builder Pro. It seems nice
yeap,
http://www.eclipsezone.com/eclipse/forums/t91368.html
Yes, sadly, it is dead. Looking at the aforementioned email threads regarding it's revival I get the feeling that even if it does get picked up it will quickly collapse under the weight of some new requirements ("make it universal, edit everything from SWT to HTML").
WindowBuilder can be a good alternative. I had several problems with VE and I end up with WindowBuilder who worked for me perfectly.
http://www.eclipse.org/windowbuilder/