Comments on: Eclipse and the modular convergence http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/ Eclipse RCP and OSGi training - online or onsite Tue, 07 Sep 2010 11:09:24 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Patrick http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/comment-page-1/#comment-2519 Patrick Mon, 02 Nov 2009 16:46:30 +0000 http://www.modumind.com/?p=1150#comment-2519 Hi Michel, Thanks for the feedback. I don't think we're actually that far apart in our views. I'm definitely against centralized control and killing off technologies that may be useful. As for a monoculture, the only one I see is that we agree on OSGi as a solution for modular software development. I do think, however, that we should be working harder to cooperate with projects across organizational boundaries. In particular, there is a lot of good that could come from the Apache and Eclipse foundations working together on OSGi related runtimes and tools. --- Patrick Hi Michel,

Thanks for the feedback. I don’t think we’re actually that far apart in our views. I’m definitely against centralized control and killing off technologies that may be useful. As for a monoculture, the only one I see is that we agree on OSGi as a solution for modular software development.

I do think, however, that we should be working harder to cooperate with projects across organizational boundaries. In particular, there is a lot of good that could come from the Apache and Eclipse foundations working together on OSGi related runtimes and tools.

— Patrick

]]> By: michel http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/comment-page-1/#comment-2468 michel Fri, 30 Oct 2009 23:29:21 +0000 http://www.modumind.com/?p=1150#comment-2468 Puzzled by your comments about Maven, and in general. There's no central steering committee (nor should there be) to kill off technologies that may "confusion" for someone. That wouldn't exactly be a path to technical innovation. Anyway, code talks, and the community decides whether to listen. Also, when you understand what the projects you mention actually do, you realize they're all doing something different. I'd like to see projects work together. That's what I want as a user. Let's leave the attempts to create proprietary monocultures to the big commercial vendors! Puzzled by your comments about Maven, and in general.

There’s no central steering committee (nor should there be) to kill off technologies that may “confusion” for someone. That wouldn’t exactly be a path to technical innovation. Anyway, code talks, and the community decides whether to listen.

Also, when you understand what the projects you mention actually do, you realize they’re all doing something different. I’d like to see projects work together. That’s what I want as a user. Let’s leave the attempts to create proprietary monocultures to the big commercial vendors!

]]> By: Patrick http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/comment-page-1/#comment-2393 Patrick Mon, 26 Oct 2009 19:52:35 +0000 http://www.modumind.com/?p=1150#comment-2393 Hi Pascal, Thanks for adding your thoughts. First, I agree that Eclipse drove the adoption of OSGi and everyone involved should be applauded for the work they've done to make it happen. Also, I understand your reasons for sticking with in-house build solutions and I hope that the Maven people can make Tycho a viable alternative. I guess what I'm asking people to do here is take a long-term view of the situation. In my opinion, Maven will become the de-facto standard for OSGi-related builds. Everyone will expect, if they don't already, that the default build story for Eclipse projects (especially runtimes) is based on Maven. My point is that if we should do everything we can to make Maven builds easier, and I know we're doing some things already. Off the top of my head, we may want to make our project shapes more compatible with Maven. We may also want to think about creating Maven plug-ins to do various Eclipse-specific things. The code would still be under our control (for when shit happens :)), but it would run under Maven. Ultimately, I think that having a Maven-based build would really increase the adoption of Eclipse projects. A lot of people who kick the tires of Eclipse RCP in particular are put off by the difficulty of the build process. PDE Build is working technically, but it's not really working from a marketing point of view. Regards, --- Patrick Hi Pascal,

Thanks for adding your thoughts. First, I agree that Eclipse drove the adoption of OSGi and everyone involved should be applauded for the work they’ve done to make it happen.

Also, I understand your reasons for sticking with in-house build solutions and I hope that the Maven people can make Tycho a viable alternative. I guess what I’m asking people to do here is take a long-term view of the situation. In my opinion, Maven will become the de-facto standard for OSGi-related builds. Everyone will expect, if they don’t already, that the default build story for Eclipse projects (especially runtimes) is based on Maven.

My point is that if we should do everything we can to make Maven builds easier, and I know we’re doing some things already. Off the top of my head, we may want to make our project shapes more compatible with Maven. We may also want to think about creating Maven plug-ins to do various Eclipse-specific things. The code would still be under our control (for when shit happens :)), but it would run under Maven.

Ultimately, I think that having a Maven-based build would really increase the adoption of Eclipse projects. A lot of people who kick the tires of Eclipse RCP in particular are put off by the difficulty of the build process. PDE Build is working technically, but it’s not really working from a marketing point of view.

Regards,

— Patrick

]]> By: Pascal Rapicault http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/comment-page-1/#comment-2392 Pascal Rapicault Mon, 26 Oct 2009 18:08:05 +0000 http://www.modumind.com/?p=1150#comment-2392 >This decision (to make OSGi the foundation of the Eclipse) has made it possible for Eclipse to participate in the convergence now taking place You are reading the history backward :) Eclipse has been the tipping point of OSGi and is what took it mainstream. It made significant changes to the spec (ids to bundles, fragments, etc...) making it relevant outside of the niche where it was. >This decision (to make OSGi the foundation of the Eclipse) has made it possible for Eclipse to participate in the convergence now taking place
You are reading the history backward :) Eclipse has been the tipping point of OSGi and is what took it mainstream. It made significant changes to the spec (ids to bundles, fragments, etc…) making it relevant outside of the niche where it was.

]]> By: Pascal Rapicault http://www.modumind.com/2009/10/26/eclipse-and-the-modular-convergence/comment-page-1/#comment-2391 Pascal Rapicault Mon, 26 Oct 2009 18:02:01 +0000 http://www.modumind.com/?p=1150#comment-2391 In the last two releases, the improvements made in the separation of concerns between PDE build (to compile stuffs) and p2 (to assemble the product) got us closer to using another build technology, and this was intended. In fact, we discussed the idea of tossing PDE Build to the benefits of Maven, unfortunately there are several issues at stake: - Resources. PDE build is working, there are higher priority items in the SDK to be addressed. - Backward compatibility. For the users, changing without anyone noticing or breaking could be hard, let alone of extenders (Athena, b3) - Loss of control. The ability to ship PDE build in the SDK and its ownership gives the team a lot of flexibility and thus an ability to quickly turn around when shit happens. - Functionality. Are we trading one set of problems for another one? None of those are insurmountable, we could likely ship with Maven and PDE Build and become committers on Maven or parts of it. The really hard one is which company or individual does this problem hitch enough so it takes on the responsibility of providing a solution to it. But btw, what is the problem to be solved? There is already Maven Tycho which is here to build plug-ins? In the last two releases, the improvements made in the separation of concerns between PDE build (to compile stuffs) and p2 (to assemble the product) got us closer to using another build technology, and this was intended.
In fact, we discussed the idea of tossing PDE Build to the benefits of Maven, unfortunately there are several issues at stake:
– Resources. PDE build is working, there are higher priority items in the SDK to be addressed.
– Backward compatibility. For the users, changing without anyone noticing or breaking could be hard, let alone of extenders (Athena, b3)
– Loss of control. The ability to ship PDE build in the SDK and its ownership gives the team a lot of flexibility and thus an ability to quickly turn around when shit happens.
– Functionality. Are we trading one set of problems for another one?

None of those are insurmountable, we could likely ship with Maven and PDE Build and become committers on Maven or parts of it. The really hard one is which company or individual does this problem hitch enough so it takes on the responsibility of providing a solution to it. But btw, what is the problem to be solved? There is already Maven Tycho which is here to build plug-ins?

]]>