Twitter github

Eclipse and Clouds

I often think that Eclipse is the victim of its own success when it comes to problems related to assembling the mass of plug-ins available for people. Nonetheless, this isn’t a bad problem to have. However, when it comes to problems, people tend to come up with solutions. It looks like we have another unique solution to this problem of plug-in assembly by Cloudsmith today.

From the announcement, “…the site, now in public beta, is designed to make it easier and faster for developers to assemble, use and reuse software components. Cloudsmith’s infrastructure also aggregates the work of developer communities to help them create and maintain software configurations, with or without the support of a commercial vendor.”

How does this compete with the recently launched Pulse service? I don’t know, it’s hard for me to test out the Cloudsmith service behind my 56k-like connection currently in Jakarta. All I know is that the Eclipse community is starting to have a lot of options in how it gets its Eclipse and we may see the day that Eclipse downloads outside of the Eclipse Foundation’s walls will be more common place.

  • Rhys Ulerich

    Man, who knew Jakarta needed a T1 so badly… 😛

    Interested in hearing the travels when you get back.

  • Rhys Ulerich

    Man, who knew Jakarta needed a T1 so badly… :PInterested in hearing the travels when you get back.

  • Nick

    Increasingly the problem seems to be that there’s TOO MANY ways to get your custom Eclipse bits.

    Take the example of PDT 1.0: you can… install from all-in-one zip; install Eclipse 3.3 platform then upgrade w/ Europa Discovery + PDT update sites; install Europa JEE bundle then upgrade w/ PDT update site; install Eclipse + EMF + XSD + DTP + WTP + PDT via a collection of zips …

    Then there’s the install method involving ubuntu, redhat & gentoo Eclipse packages + update from PDT update site or feature zip.

    And with the advent of Eclipse 3.4 and Equinox p2, we’re offered yet another way to get our updates/installs.

    None of which includes the external-to-eclipse.org solutions out there that you mentioned.

    Am I the only one that’s overwhelmed? As Ed has often told me, sometimes too much choice can be a bad thing when it makes the story too confusing for the user.

    Is it time to simplify the ‘how do I install ____?’ story?

  • Nick

    Increasingly the problem seems to be that there’s TOO MANY ways to get your custom Eclipse bits. Take the example of PDT 1.0: you can… install from all-in-one zip; install Eclipse 3.3 platform then upgrade w/ Europa Discovery + PDT update sites; install Europa JEE bundle then upgrade w/ PDT update site; install Eclipse + EMF + XSD + DTP + WTP + PDT via a collection of zips …Then there’s the install method involving ubuntu, redhat & gentoo Eclipse packages + update from PDT update site or feature zip. And with the advent of Eclipse 3.4 and Equinox p2, we’re offered yet another way to get our updates/installs.None of which includes the external-to-eclipse.org solutions out there that you mentioned. Am I the only one that’s overwhelmed? As Ed has often told me, sometimes too much choice can be a bad thing when it makes the story too confusing for the user.Is it time to simplify the ‘how do I install ____?’ story?