Eclipse Indigo Release Train Now Available: 46 Million Lines of Code Across 62 Projects
For the eight successive year, the latest iteration of the Eclipse release train, Indigo, is now available for developers everywhere. And once again, the Eclipse community have shown that it is possible to coordinate software to be released on time. The scale of Indigo is huge - it contains 62 projects, 46 million lines of code contributed by 408 committers.
“We are very proud to celebrate another on-time annual release train from the Eclipse community,” states Mike Milinkovich, executive director of the Eclipse Foundation. “This release has a long list of new features, especially for Java developers. Features such as Git support, Maven and Hudson integration, a great GUI builder in WindowBuilder, and our new Jubula testing tool will, I am sure, motivate developers to try Indigo.”
Yesterday I listed some of the excellent tooling additions that are available in Indigo. Once again, the latest Eclipse release provides something for everyone. Download it now and find out for yourself.
For Java Developers
- EGit 1.0 provides first-class support support for Java developers using Git for source code management
- WindowBuilder, a world-class Eclipse-based GUI builder, is now available as an Eclipse open source project
- Automated functional GUI testing for Java and HTML applications is included via Jubula
- m2eclipse brings tight integration with Maven and the Eclipse workspace, enabling developers to work with Maven projects directly from Eclipse
- Mylyn 3.6 supports Hudson build monitoring directly from the Eclipse workspace
- Eclipse Marketplace Client now supports drag and drop installation of Eclipse-based solutions directly into Eclipse making it significantly easier to install new solutions.
New Innovation in Eclipse Modeling
- Xtext 2.0 has added significant new features for domain-specific languages (DSLs): 1) the ability to create DSLs with embedded Java-like expressions; 2) Xtend, a new template language that allows tightly integrated code generation into the Eclipse tooling environment; and 3) a new refactoring framework for DSLs.
- Acceleo 3.1 integrates code generation into Ant and Maven build chains, and includes improved generator editing facilities.
- CDO Model Repository 4.0 integrates with several NoSQL databases such as Objectivity/DB, MongoDB, and DB4O. Cache optimizations and many other enhancements allow for models of several gigabytes.
- EMF 2.7 makes it easy to replicate changes across distributed systems in an optimal way: a client can send back to the server a minimal description of what's been changed rather than sending back the whole, arbitrarily-large, new instance.
- Eclipse Extended Editing Framework (EEF) 1.0 generates advanced and good-looking EMF editors in one click.
- EMF Compare 1.2 brings dedicated UML support and is more fully integrated with the SCM.
- EMF Facet, a new project, allows extension of an existing Ecore metamodel without modification.
EclipseRT Advancements
- EclipseLink 2.3 supports multi-tenant JPA Entities, making it possible to incorporate JPA persistency into SaaS-style applications.
- Equinox 3.7 now implements the OSGi 4.3 specification, including use of generic signatures, generic capabilities, and requirements for bundles.
- Eclipse Communication Framework (ECF) implements OSGi 4.2 Remote Service and Remote Service Admin standards.






Comments
Eugene Kuleshov replied on Wed, 2011/06/22 - 9:51am
Hannah Myeres replied on Wed, 2011/06/22 - 1:04pm
Kristian Rink replied on Thu, 2011/06/23 - 3:56am
in response to:
Eugene Kuleshov
I am, and always will be, torn between using NetBeans and Eclipse. Eclipse, on one side, is an incredibly great ecosystem and environment, offering features and technologies NetBeans so far unfortunately can't even dream of (Xtext/Xpand/Xtend, EMFText, RAP/RCP, to just name these most obvious to me at the moment), and it generally seems way more vivid in terms of incubating and growing new and great technologies for both runtime and development environments. This is good.
On the other side, being a developer to mainly use maven2 and war artifacts (by now both "legacy" Java EE 5 / Spring artifacts and "newer" Java EE 6 ones), I always figured out that, whereas NetBeans "just works" straightforward and effectively, Eclipse so far is next to unusable indeed. In NetBeans, things here are pretty straightforward - simply open your maven war project, associate it with a server via Project properties, run it on the server, and you'll likely to be fine. In Eclipse, you end up lost somewhere in between messing with M2E, WTP and Server adapters, eventually manage to download all the different plugins you need using various sources (took me a while yesterday to learn where to get m2e-wtp-integration from, seeing that several different "marketplaces" obviously start trashing the idea of a single globally "installation/update" mechanism), set up and run a server - and see that your project doesn't run. Why? Not sure. Seems some of the maven jar dependencies aren't correctly exported / copied / whatever to the application folder (where?) which is being deployed to the in-IDE Glassfish. Project explorer also is still somewhat funny using maven2 projects in Eclipse, and I once in a while happened to again see the WebContent folder pop up in my maven2 web artifact (which has _absolutely_ no reason to be there as there is src/main/webapp as the place to keep those things). Eventually got back to NetBeans for productive work, gonna look into this again as soon as I got some spare time.
Note: This is not supposed to be a rant. Given Eclipse and NetBeans, so far I like and use both for different purposes and reasons. And, as far as maven tooling is concerned, NetBeans also offers a bunch of funny issues to deal with, these days. Then again, developing maven2 built projects using Eclipse _always_ was way less pleasant than with NetBeans as (despite the pom.xml editor in Eclipse is just gorgeous) integration simply falls short in many minor situations in which things seem to behave different in a subtle way: Project facets / natures with maven2 projects? WebContent? Vast loads of Eclipse specific configuration files in the project root? Eclipse complaining about obscure lifecycle support plugins not being available (despite the project builds well using the external maven installation which is configured to be used by the IDE)?
I surely hope future Eclipse / m2eclipse releases will do better here, at the very least for web / server sided development. :(
James Sugrue replied on Thu, 2011/06/23 - 9:10am
in response to:
Hannah Myeres
Hannah Myeres replied on Thu, 2011/06/23 - 12:57pm
in response to:
James Sugrue
Mark Unknown replied on Thu, 2011/06/23 - 4:51pm
in response to:
Hannah Myeres
Hannah Myeres replied on Fri, 2011/06/24 - 12:43am
in response to:
Mark Unknown
James Sugrue replied on Fri, 2011/06/24 - 6:03am
Mark Unknown replied on Fri, 2011/06/24 - 7:59am
in response to:
Hannah Myeres
I have used Eclipse for years. While it is far from perfect, it is not the nightmare you describe - not for me and obviously not for many others otherwise they would have all jumped to Netbeans or paid for another one. I have run into issues. How I typically solve it, for more than one reason, is have more than one "install". If something screws up, i delete the "install" and expand again.
It can also be resolved by something like Yoxos. http://eclipsesource.com/blogs/2011/06/23/yoxos-a-whole-new-way-to-epp/
Most times, though, people's needs are "simple" and one install will do for them. In fact, it does for me sometimes.
For me the productivity gains i get using Eclipse overweight any minor install issues that I might have. I use another mainstream IDE pretty much daily. Installing takes longer, updates do too and it is more of pain to use daily than Eclipse and much less productive over the life of a project - even with third party plugins. And uninstalling... sigh. Maybe that makes Eclipse seem really good to me. :) It is all about perspective.
Carla Brian replied on Sun, 2012/05/13 - 5:57am