| Re: [orion-dev] Orion Project Termination |
_______________________________________________Hello all,
It's with a bit of a sad heart that I'd like to propose the termination of the Orion Project.
Eclipse Orion and the notion that an IDE should be in the Cloud was an idea that was ahead of its time. For a start, developers love their desktops and their editors. An IDE in the Cloud needs to be as customizable and flexible as on the desktop. Ignoring the old IDE (or newer editor wars), the experience of using the IDE in the Cloud needs to be so compelling that developers would overlook the fact that it wasn't "XXX" and simply use it because, it was so productive. Productivity comes from extensibility and plugins and these need to be there, but productivity also comes from an optimized development and debugging experience. Setting up an IDE and debugger can be painful, and some developers simply don't do it. That's where instant-on capability is needed.
There is also the question of where the IDE (editor, debugger) is running. When you run an IDE on your desktop, your machine has everything you need to implement, test and debug as part of your inner loop. You’ll need the same int the Cloud. Next comes the thorny problem of where your micro-system is in the application stack. If you are at the bottom of the stack, you can generally test and develop easily. If you are at the top (ie. the UI), often you can play proxy games to insert your component in front. If you are in the middle of the stack, you either need to insert your micro-service into a running application or run the entire application on your desktop. The latter is generally not feasible for big projects. The location of your development environment with respect to the application is always an issue.
Whether you are running in the Cloud or on the desktop, you face the same location issue when debugging. If the IDE is running inside the target application in the Cloud, then everything is at your fingertips, but the application may be shared by others who will be affected by your debugger. Further, micros-services are ephemeral. If you are running a debugger in a sidecar beside a micro-service, it's ephemeral too. An instant-on IDE solves this problem but does not take into account any state or tooling that is outside of the instant-on environment that you may have on your desktop (or in the Cloud, but not in the application).
What about remote debugging? That is often painful. It's fine for setting a breakpoint and inspecting values but making a code change often requires a rebuild. Rebuild is part of your inner loop, you need all of your development tools handy. You can rebuild locally and push out changes but that's not the same as being there. This points out the obvious fact that development and debugging are not exactly the same thing, although they overlap. You must debug to develop, but you also need to debug after you have shipped in live applications.
Technologies and IDE’s (editors) exist that address all the points I have discussed above and more. Most IDE’s are full featured with tons of plugins. Instant-on is a very old concept and has been implemented in many different ways (container development, config files etc.). IDE’s can be injected into running applications and strategies exist for hiding them from others in the running application. It is possible to teleport your desktop into the cloud and have it behave like a micro-service. There are multiple debugging strategies involving sidecar.
Unfortunately, Orion fell behind in the race to give programmers what they needed to be productive in the Cloud and did not address many of the issues and concepts I described above. It’s time for the project to be officially retired.
Thanks,
Steve Northover
Orion Project Lead
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orion-dev