IDE – Still Officially Supported?

In the Summer ’13 release webinar, Ryan Upton and Samantha Ready mention that the IDE is no longer being supported. During the Q&A time, they both chime in on a question related to the IDE. The question starts at 53:30 and runs to 54:30.

During the answer, Ryan mentions it is deprecated and that the goal is to move everyone onto the Developer Console. As a long term user of Eclipse (coming from a Java background), I just don’t see how this is even remotely possible. A true IDE is needed for the platform and discontinuing support for this IDE doesn’t seem logical. You lose the ability to do mass refactoring, you lose the ability to store offline files (such as deploy packages, data load scripts, etc), you lose the ability of local file history, you lose the ability to quickly search entire projects, and you lose the ability to easily interact with version control systems. That is all just the tip of the iceberg of all the functionality involved with an IDE.

So, my question is, is there any other documentation stating this is going to be deprecated? Is there any explanation on possible workarounds for these other issues if this is true? Is there anything that states what the long term goals of the IDE/Developer Console truly are?


As the original author of the IDE, I can understand why you would be unclear on the future of the IDE. Rather than say it has been deprecated I would say that it has been put in maintenance only mode, but IS supported. That is to say, that with each release of the platform, the next being Winter ’14, the IDE will be updated so that the API endpoint of the SOAP API used by the IDE is current.

The IDE uses a combination of SOAP and Metadata APIs and to gain access to the most recently exposed metadata, this endpoint update, and re-compiling needs to occur. But, that is the extent of support that we are committing to with the current IDE code base.

The long term strategy is as described above. We have moved resource from adding new features to the IDE to developing an API who sole purpose is to support tooling. You can see the progress of the tooling API in the Developer Console, which is the first place that this API is being put to work. Once the tooling API has reached a level of functionality, we will revisit an Eclipse plugin.

The IDE was built by salesforce Developer Evangelism for the reasons that you excellently point out above. It was built before we released a Metadata API even, mostly to gain the usefulness of an IDE, but the main reason was so that the developer had access to the built in source code control, something that is terribly important for real development and governance.

Due to the popularity and adoption by the developer community, the project was “forced” upon the R&D side of the house so that it could be properly supported and maintained. The code behind the IDE has evolved organically and over a lengthy enough period of time that the entire underlying implementation has rightly been called into question. Newer APIs exist that can/will be used in conjunction with the tooling API to deliver a better performing, less chatty IDE. Included in this is something akin to a grammer for proper code assist and refactoring, replacing the current polling mechanism with a streaming API mechanism and a better Visualforce editor.

The service is unique, so while we can borrow a lot of techniques and approaches, some aspects of this just have needed to be invented. Hopefully this demonstrates our commitment to the IDE and other tools like Mavens Mate and BrainEngine

EDIT: On September 17, 2013 the DeveloperForce blogs came out with the following article. Cliff notes:

  • We will be updating the plugin to work with the latest versions of Eclipse and Java shortly after the Winter ’14 release.
  • We have been finishing up the Tooling API to prepare for the more complete refactoring which is now in flight.

After the refactor:

  • Dynamic Metadata API: No more need to upgrade the plugin every release to get the latest metadata API. Latest and greatest available at all times.
  • oAuth: No more need to reset a security token and update projects with new credentials. oAuth authentication will keep your plugin authenticated to an instance until you tell it you don’t want to be authenticated anymore. Especially useful for those of you with admins requiring monthly password resets.
  • Code Completion: The Tooling API provides symbol tables for an org, which will be used to offer code completion. Developer Console offers this today; rebuilding with the Tooling API will allow the plugin to offer it too.
  • Better Save Process: The Tooling API provides a mechanism for saving code artifacts more directly than the metadata API, providing a much less unwieldy experience.
  • Plugin-only: The current approach of offering a bundled exe to install both Eclipse and the IDE plugin. We’ll be all plugin, all the time.

EDIT: On July 1st, 2014, the IDE Core has officially gone open source on GitHub. The community can now help maintain it.

Source : Link , Question Author : Jesse Altman , Answer Author : Jesse Altman

Leave a Comment