Hi There,
I'd just thought I'd drop a note and say... Eclipse ------- PROS * Better Perl Support Epic (e-p-i-c.sourceforge.net) simply rocks as a Perl development environment. It integrates nicely with Perl tidy, has great syntax highlighting, progressive builds (so you can see where you've gone wrong straight away) and a GUI debugger [1]. If you're using objects, whilst finding an object via one's Perl @INC doesn't always work at the moment, once you have instantiated the object, auto-complete generally works. This is a feature that I find truly useful as it fits extremely well with Perl's motto of "Be Lazy if You Can". At first, I found the plugin's inability to integrate with Makefile.PL (made by h2xs and the like), I finally decided to get off my high horse and learn a little bit of ant. I've known ant for years but I still think its syntax is just as esoteric as Make's syntax -- at least there aren't six trillion flavours of it at the moment. So, what does ant give me: at the click of the button I can: - make a distribution tar ball - run my unit tests - install it (I have to tidy this task up a little as sometimes installing means getting extra privileges) Using Subclipse or the Mercurial plugin I have access to two very powerful versioning systems although Subclipse (SVN) is the more mature plugin. Naturally, I could use CVS but if you've got SVN why use CVS if you don't need to? * Better PHP Support Repeat all of the above, but replace with PHP Eclipse (phpeclipse.sourceforge.net) except: - write native tar ball / untar tasks rather than Makefile - find a way to integrate testing and deployment that works for you I tend to cheat with PHP and simply have a Makefile that uses "rsync", "chmod" and "chown" as root. It's cheating; it's evil and I'm a Perl programmer by heart :P * Extending Eclipse and Making Rich Client Platforms is VERY well documented Whilst you'll need to have quite a good understanding of Java and the Java programming environment, it's not impossible. Furthermore, you shouldn't feel upset when someone tells you to RTFM because the manuals are actually understandable and cover from the basics to the really advanced. Ever been told RTFM when the FM doesn't make sense unless you understand the FM already? * Eclipse isn't going to go away... Firstly, it's open source and backed by a separate foundation, the Eclipse Foundation. Secondly, it's a platform that many other companies have a vested interest in seeing not dying (and hence paying people to make sure development continues). Thirdly, it's my understanding that it's the platform of choice for many, many of IBM's current and new software projects and IBM have a bigger software portfolio and business than Microsoft... [and seem to understand that letting people leverage their platforms as they did the PC/XT years ago can give one a competitive advantage as back to front as that may seem] I used to like Borland's IDEs but they've essentially gone away and/or I can't use them on my preferred platform. Unless Sun and the community stop supporting Java on Solaris, I'm relatively safe...which leads me to: CONS * Java SE && EE Development For POJO (Plain Old Java Object) development, the JDT is absolutely fine. However, Eclipse's inbuilt Java compiler isn't as easy a beast to get configured correctly as Netbeans (5.0 - 5.5 series) IDE. Don't get me wrong: it works, however, trying to figure out where it's decided its base class path is today can be a chore. In fact, this might sound counter-intuitive but Eclipse's build system is very GUI like and yeah... Compare this with Netbeans: let's say I want to make a project that uses the Java JPA persistence framework backed by Hibernate and the MYSQL/J connector as the JDBC backend. I need the Hibernate classes to go onto my classpath and the MYSQL/J connector. I'll also need a "persistence.xml"; I like log4j so I need a "log4j.properties" for them. Now, no matter how much I fiddle with confounded Eclipse, I'll find that: - log4j will fall over because it can't configure itself - JPA will fall over because it can't find the Persistence unit (defined in that XML file) - Hibernate will fall over because it's fallen off the class path In Netbeans: IT JUST WORKS. - Plonk your log4j.properties in the src default package - Plonk your persistence.xml in META-INF (you can even use a nice GUI tool to make it) - Point Netbeans to the right libraries And IT JUST WORKS. Netbeans seems to have Java EE support built in and doesn't require any outside plugins or modules to support Java EE (but only if you download the Java EE edition). It has a very easy, point'n'click but you can fiddle style to development. It's quite imperative and very fast once you get used to it... Eclipse's WTP and J2EE Project are promising and follow a different style and feel of development. However -- and this is personal opinion -- I like Netbean's in this area more. * The Plugin Shmugin Nightmare Drawing my parallel with PC/XTs again, Eclipse is like the PC of the platform world. Widely available and lots of plugins. And occasionally, something will just go pie shaped [you put in that wonder-dog EGA card] and Eclipse just goes BOOM! I hate to say it, but the fastest way I've found to fix Eclipse is to do the Windows equivalent: - reboot/start it - reinstall it In fact, I think I'm so used to reinstalling it that I'm actually limited now by the speed of my hard drives. NOW, don't get me wrong: I don't reinstall it that often. However, Solaris is an ultra-stable operating system and it's the one big thing that is likely to go and fall over on me. It doesn't help that I have a Plugin list the length of my arm and some of them are marked as "beta" however, for a lark, I installed every single Plugin that I could be bothered [read: after an hour or so I couldn't be bothered downloading another plugin] on my Netbeans and it just happily chugged along. The only time I've ever had to reinstall my Netbeans is: - when I kinda erased my whole /opt partition (oops) - when I did a "I can't be bothered downloading the upgrades, I'll just be lazy and get the whole package again" Because Solaris isn't the most well supported -- well it's unsupported actually -- platform occasionally you'll get into circular dependencies of things depending on things that don't exist. And, what's MORE annoying: there's no RCP distribution for Solaris on x86. However, what do you think Eclipse 3.2.0 is running on? The Eclipse RCP...the mind boggles. * It's Slow I hate to say it, but Eclipse and OpenOffice are vying with each other for "How to be the Slowest but Most Useful Apps Possible". I actually think OpenOffice wins out slightly UNLESS you're on a Mac and you're using that other thing which uses a lot of Java to provide the Mac look and feel. Because Eclipse runs quite a lot of background processing -- incremental builds and such -- it has a nasty tendency to seem sluggish at times. My Eclipse has a Gnome in it that says: He wants to start typing now so I'm going to start off this massively non-parallel task that will only give his thread a go every light year... On the other hand, Netbeans is SLOWER :( * It Chews Up Memory Like you wouldn't believe. Don't even think about trying to seriously use it with less than 1 gig of RAM. You can but you won't have fun; and it's likely to a) crash b) go funny and c) not be able to give the GUI thread enough time and you think it's done (a). * Aarrrgh, it's huge... Yeppers, it's huge. Whilst the RCP is only about 10-20Mb, the Eclipse Platform is, well, rather large. ... All this said, I'd recommend using it for an IDE even if it's just to prove to yourself that you don't need one. I tried to prove that to myself and find that I really should have been picking the right tool for the right battle... Hope this is of interest! DSL PS: Most of the Linux plugins and modules at easyclipse.org (or easy-eclipse.org in case that first one goes somewhere strange) do work on Solaris; they all use the SWT and standard Java for the most part... The full IDE won't, though, as you need the SWT library files for Solaris on x86 (and Linux isn't Solaris on x86 :P) _______________________________________________ opensolaris-discuss mailing list [email protected]
