A new version of the Force.com IDE plugin is available for download on the developer.force.com website: http://wiki.developerforce.com/page/Force.com_IDE_Installation

We have repaired a bug around a new metadata type – InstalledPackages. Some of you were unable to save anything if you had done some mods to the package.xml file, and some of you were having trouble with normal deployments due to some unique aspects of this new metadata type. (Please see the end of the post for some additional details.) These troubles should be fixed. If you are experiencing troubles, please grab the latest version of the plugin.

Latest?

I am sure there is a punch-line kicking around your head here, something to do with “latest version” and the force.com IDE plugin. I will acknowledge that it’s sub-optimal that our plugin is only supported on Eclipse v3.6, which I am told is not the latest version of Eclipse. (*checks wikipedia*) I will also acknowledge that it is bad that we do not support Java 7, since many of you have moved there, by choice or by force.

We will be updating the plugin to work with the latest versions of Eclipse and Java shortly after the Winter ’14 release.

I’m going to repeat that, because it’s probably going to make you happy the second time, too.

We will be updating the plugin to work with the latest versions of Eclipse and Java shortly after the Winter ’14 release.

The new plugin will work with Eclipse 4.2 & 4.3.  We will continue to support Java 6, so there’s no requirement to upgrade to Java 7.

Sleeping Dogs

There’s that old adage about letting sleeping dogs lay…what they neglect to tell you is that if you let a dog sleep too long, he gets VERY hungry, and then you REALLY don’t want to wake him, so you let him sleep some more, and he gets hungrier yet and…yes, you get the picture. Eventually, you have to wake the dog up, and it’s not pretty. Barking and growling and mess.

There came a point at which the effort to fix what ailed the current plugin (from a new-Eclipse-version perspective) was equal to or larger than the effort to rebuild chunks of it. Thus the decision was made to rebuild much of the plugin using the Tooling API rather than patch the old version. That is why we have allowed this to slumber – we have been finishing up the Tooling API to prepare for the more complete refactoring which is now in flight.

I, for one, have not lost sight of the fact that upgrading the plugin to modernity is probably the thing that will make the most developers’ lives easier. With that in mind, this was chosen as the first enhancement that you will see in the coming months around the Eclipse plug-in.

But Wait – There’s More!

There are many things we plan to change / add to the plugin over the coming months.  Here’s a sneak peek at what we plan to deliver (safe harbor thought bubble appears above my avatar’s head):

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 Force.com IDE plugin. We’ll be all plugin, all the time.

Now, Your Turn…

These are probably not the only things you’d like to see us add to the Eclipse plugin.  They’re not the only things WE would like to see us add to the plugin! We will continue to improve the plugin in parallel with the Developer Console over the coming years.  However, I know that someone out there is going to want some features or fixes faster than we plan to (or are able to) deliver them.

To that end, we intend to release the source code for the Force.com Eclipse IDE Plugin to you.

Details of the open source process will be a discussion for another time. For now, suffice to say that there will be a Salesforce-supported main branch surrounded by any number of community-supported branches. Some features and improvements will be pulled in to the main supported branch, but even for things never adopted into main, nothing will stop you from installing – or building! – a community-supported feature branch.

All of the items I listed in the previous section will probably be completed prior to the open-source conversion. Current plan is to see the open-source conversion take place in the first half of next year. (There are operational hurdles as well as technical work to do, so again please see safe harbor thought bubble.)

Notes on the Current Patch Release

As mentioned at the top, there is a new patch available now if you’ve been having issues with the most recent release. If you’re in that boat, here are a couple of facts that may prove handy:

  • After upgrading the Force.com IDE to the latest patch (28.0.1), you might need to recreate your Force.com projects in the IDE. This is true if you have already created an existing project with the original Summer ’13 version (28.0.0).
  • We are not providing official support of the InstalledPackage metadata type in this version of the IDE. The new InstalledPackage metadata type has a new requirement that it has to be deployed by itself and not in conjunction with any other metadata types. See http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_installedpackage.htm

Happy Coding!

tagged , , Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • http://www.bobbuzzard.org/ Bob Buzzard

    Excellent news Josh.

  • Diéffrei Quadros

    Josh,
    please add code sintax formatter!

  • Ajaduria

    Fuck this plugin, you must use MavensMate

  • Yuji Naka

    I’ve been using Sublime Text 3 + MavensMate. This editor is a hundred times best than the poor and obsolete Eclipse plugin. If you are a serious programmer, throw Eclipse in the trash.

    • http://blog.superpat.com/ Pat Patterson

      Different developers prefer different tools – vi, Sublime Text, Eclipse, Developer Console – each to their own. The important thing is that we’re creating the APIs and opening the source to the plugin so that anyone can hook their tool of choice into Force.com.

      • Washington

        Ok, but Salesforce could give us, at least ONE good tool. This Eclipse plugin is horrible. Salesforce sells a dream, and gives a hell to programmers…

      • Veteren Developer

        No Pat. The important thing is that there needs to be a market for better tools that we could choose from. This market doesn’t exist for Apex/Visual Force. I don’t have a choice but to use inferior development tools provided by SF.

        • Josh Kaplan

          Pat is correct.

          We have created the Tooling API to enable the building of the MavensMate plugin and the BrainEngine IDE, both of which we would not have had time to build with all the other priorities on our plate. This creates the market for more tools than the “inferior” ones my team is building. I have spoken to people working on plugins for other existing IDEs, and I hope to see these come to fruition soon.

          At the same time, we are working towards an open-source plugin, where you will be able to improve the “horrible” plugin to your specifications. I, for one, look forward to seeing the creative additions that you and the community bring to the plugin once it is community property.

          • Kevin O’Hara

            Is it fair to say the Tooling API is still a work-in-progress? The last time I checked, only a few metadata types were supported. I need it to replace ANT 100% to really leverage it. I’ve got plans for some CLI-based dev tools but was waiting on the Tooling API to mature.

  • Guest

    Ok, but Salesforce could give us, at least ONE good tool. This Eclipse plugin is horrible. Salesforce sells a dream, and gives a hell to programmers.

  • Veteren Developer

    The Salesforce plugin sucks. I’m sure the developers who built it are glad its not the development tool they have to use.

  • Ajaduria

    Wow… my last post was deleted. Sorry for my words, but I hate this Eclipse plugin. I recommend MavensMate by my personal experience.

  • Don Robins

    Great news of the upcoming fixes and upgrades to the Eclipse based toolset, as the need has been growing for some time. I suggest that developers don’t lose sight of the fact that the more pertinent news is the evolution of the Tooling API, upon which a better toolset has been dependent. Better tooling for this platform can only improve and evolve with the open API access which is where SFDC has been focusing its resources. This has been clearly shouted out since DF10, and while the wait has been difficult it appears on the horizon. You might also take note of the evolution of the metadata API, constantly reducing the count of unsupported metadata types with each release. Incremental improvement is a fact of life and necessary for success when building an airplane while it’s in the air, carrying millions of passengers, each with their own load of baggage; in this case over 1 Billion lines of code. Kudos to the dev teams; looking forward to the releases.

    • http://www.eltoro.it/ Andres Perez

      Those are great news… Thanks SFDC!

  • Cory Cowgill

    I’ve been using the Force.com Eclipse plugin for several years. Before Force.com I used RAD Eclipse at a large enterprise for JEE / Websphere development. I continue to use Eclipse for Android and Heroku development with their respective Eclipse plug-ins.

    There are short comings to be sure in the Eclipse IDE, and Force.com plugin. But that can be said about any tool (Visual Studio, etc). With respect to Force.com, many things are limitations in the Metadata API, which SFDC has continued to improve and build out over the years.

    Its good to see variety in the ecosystem. MavensMate, BrainEngine, DeveloperConsole, Force.com Migration Toolkit etc. Competition will promote better tools. With the open source API’s if you don’t like a tool you can go build one like Mavens, or use a competitors tool.

    I can’t see this but anything but a positive move by SFDC. As someone who is in the Force.com IDE constantly I think this is great.

  • http://snuxoll.com Stefan Nuxoll

    So glad to hear this, what I’d really love is a BNF for Apex much like you have for SOQL as well. I’d love to work on an IntelliJ IDEA plugin for Force.com but the lack of any existing code (or at least a grammar!) to base it on makes it a rather difficult task.

    • Andrew Fawcett

      Agree on the Apex BNF request, the Tooling API is great and is going to be a huge help to move tooling forward, but not having to make a callout to get the Symbol Table is going to make sure future IDE’s (Salesforce or otherwise) respond as quickly as other IDE’s currently performing local code scanning. Especially important on larger code bases.

  • Jeremy Kraybill

    It’s great to see some movement on the IDE front. I hope more of it comes. If any Salesforce people are listening, I just want to re-iterate my impassioned plea as a long-time SFDC developer that more high-level execs have heard than need to – do NOT let the release of a Tooling API encourage the de-investment in SFDC developer tools by SFDC.

    A number of official SFDC people, including Pat and Josh in the comments here, have pointed to the fact that there are now a few third-party options (MavensMate, BrainEngine) as encouraging signs for a third-party IDE ecosystem. THIS IS NOT THE CASE.

    The reason those alternative options exist is because Salesforce has given developers an objectively sub-par set of developer tools. Also nobody is, has, or (IMO) ever will make real money from Salesforce developer tools. So that’s not some IDE ecosystem, it’s invention by neglect-based necessity. It’s Salesforce’s imperative to deliver an elegant developer experience, and the fact that Salesforce has chosen not to do that is why these third-party, mostly volunteer, projects have arisen.

    The existing tools came about because one or two guys on a project in their spare time could clearly create something better for Salesforce developers than the Salesforce product team could give us. That is not acceptable, and it’s not sustainable.

    I look forward to Salesforce re-committing to the Eclipse platform as a true multi-platform desktop IDE environment. The developer console is fine for entry-level devs and one-org devs who just need to quickly edit a few files, but it will never approach the features and extensibility (and VCS integration, and diff tools, etc) of a true IDE like Eclipse.

    With all that off my chest, bravo to the new plugin that at least brings Eclipse support from a 2010 release to present day! It was discouraging to see the Force.com explorer support discontinued (http://salesforce.stackexchange.com/questions/10008/has-force-com-explorer-been-abandoned), and the comments by the original Force.com IDE author here (http://salesforce.stackexchange.com/questions/15654/force-com-ide-still-officially-supported) – I was really starting to feel like it was unlikely to see much further investment in “hard-core” developer tools. This is a step in the right direction, but it’s a baby step that needs to be continued.

    • John Hillstrom

      Hey Josh – just to be 100% crystal clear, when you say “Plugin-only: The current approach of offering a bundled exe to install both Eclipse and the Force.com IDE plugin. We’ll be all plugin, all the time” you mean that the “Force.com IDE” installation is going to go away and you will instead support only the distinct installation of Eclipse + the Plug-In (btw, I think this is a good approach).

      Does that mean we should convert to Ecllipse + Plug-in, today if we’re running the “Force.com IDE”?

  • Ilene Jones

    So, with this update the InstalledPackage issue was to be resolved, however I’m still seeing that issue in the Force.com IDE after updating. It doesn’t help that this is my first deploy, so I have no idea where to even LOOK to fix this issue – I have done a grep on my machine and do not even have any filenames that use the extension. Everything I’ve read has said to roll back to release 27, but according to this, I shouldn’t have to?

  • Andrew Fawcett

    Another great post Josh, open and honest, the way it should be! I think a major barrier to entry to the platform for Java or .Net developers is the IDE experience, its often as much an emotional (user experience) choice as it is a feature and function one (such as debug). As you say the realities of developing solutions that are in flight are hard to juggle at times, what helps in these cases is to empower as much of your target audience as you can, especially the solution builders! So this is why for me the Tooling API is so critical to this story. Looking forward to the next update!

  • Kriyanshi

    I am new in salesforce and not able to understand the apex and visualforce code can sum1 suggest me how we start learning on salesforce bcz i have no 1 who guide me properly step by step

  • Eliot

    The Force.com IDE is the main reason that every time I work on a Salesforce.com project, a little part of me dies.

    Ctrl clicking a method call and getting nothing, hitting save and waiting 30 seconds while the entire UI locks up – every little bit of it is like wading through mud. It couldn’t possibly be worse. Except, perhaps, if you use the Developer Console.

    Both tools are a pretty clear sign of the degree to which Salesforce.com cares about its developer community.

    • Josh Kaplan

      Do you have the Build Automatically option set? Individual saves should not take very long, since they are local. Deployments can take a varying amount of time based on a multitude of factors. Rest assured we are working on every single one of those factors (except for your network bandwidth, that is). In the meantime, if you don’t deploy when you don’t need to, you should have much faster performance. It sounds to me like you might be doing so too frequently. Let me know.

      We are delivering a brand new IDE plugin in the coming months…the Developer Console got quite a few improvements in the Spring release, with more coming in Summer…we are working hard on delivering both great tools AND an API so that others can deliver even better tools. Rome was not built in a day, and developers are a demanding lot. It’s tough to hear that you don’t think we care, since my entire job and the bulk of my week goes in to caring about the developer community.

      As mentioned above, if you are concerned that the Eclipse plugin is killing you, you’ll have the opportunity to self-medicate when the plugin is open-source. I look forward to your contributions to the project, in whatever form they come, as they will serve to make the experience better for all.

  • Keith Clarke