Are you fan of [[wikipedia:Intelligent_design|intelligent design]] or [[evolution]]? Most people around me would select [[evolution]] as a means of populating our world (althrough [[Geertjan]] in a [[Module_system|recent screencast]] refused to answer). However when you ask the same people whether they use [[evolution]] or [[intelligent design]] methods to manage their company, their answers change. They act as [[intelligent design]]ers! Is not that another example of a [[doublethink]]?

Are you fan of [[wikipedia:Intelligent_design|intelligent design]] or [[evolution]]? Most people around me would select [[evolution]] as a means of populating our world (althrough [[Geertjan]] in a [[Module_system|recent screencast]] refused to answer). However when you ask the same people whether they use [[evolution]] or [[intelligent design]] methods to manage their companies, their answers change. They act as [[intelligent design]]ers! Is not that another example of a [[doublethink]]?

== [[Evolution]] and [[JDeveloper]] ==

== [[Evolution]] and [[JDeveloper]] ==

As a consequence the [[API]] architects should worship [[evolution]]. Not only/necessarily when asked about the genesis of the world, but (more importantly) during their regular workdays!

As a consequence the [[API]] architects should worship [[evolution]]. Not only/necessarily when asked about the genesis of the world, but (more importantly) during their regular workdays!

As a consequence the [[API]] architects should worship [[evolution]]. Not only/necessarily when asked about the genesis of the world, but (more importantly) during their regular workdays!

As a consequence the [[API]] architects should worship [[evolution]]. Not only/necessarily when asked about the genesis of the world, but (more importantly) during their regular workdays!

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could reuse some [[API]] coming from the other product. Some of these requests were not surprising (e.g. I knew that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could reuse some [[API]] coming from the other product. Some of these requests were not surprising (e.g. I knew that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] we could stimulate brainstorming in the minds of our collegues. Only by not having a plan we could come up with so great ideas!

== [[API]] Architects ==

== [[API]] Architects ==

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could reuse some [[API]] coming from the other product. Some of these requests were not surprising (e.g. I know that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could reuse some [[API]] coming from the other product. Some of these requests were not surprising (e.g. I knew that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

== [[API]] Architects ==

== [[API]] Architects ==

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could share some [[API]]. Some of these requests were not surprising (e.g. I know that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could reuse some [[API]] coming from the other product. Some of these requests were not surprising (e.g. I know that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

== [[API]] Architects ==

== [[API]] Architects ==

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such [[module system|common ground]] would give us a chance to ''share''. I was not 100% sure what parts should be shared, but I knew that allowing sharing is important.

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such [[module system|common ground]] would give us a chance to ''share''. I was not 100% sure what parts should be shared, but I knew that allowing sharing is important.

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

It was not enough to share components in runtime (e.g. something we did in recently released version of [[JDeveloper]]). We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could share some [[API]]. Some of these requests were not surprising (e.g. I know that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

And guess what? In the recent few weeks I've been asked by various members from the teams whether they could share some [[API]]. Some of these requests were not surprising (e.g. I know that sharing these sub-systems could be beneficial), however some where completely new! Only by creating an [[environment]] suitable for [[evolution]] would could stimulate brainstorms among minds of our collegues. Only by not having a plan we could come up with so great ideas!

== [[Evolution]] and [[JDeveloper]] ==

== [[Evolution]] and [[JDeveloper]] ==

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such [[module system|common ground]] would give us a chance to ''share''. I was not 100% what are the parts that should be shared, but I knew that allowing it is important.

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such [[module system|common ground]] would give us a chance to ''share''. I was not 100% sure what parts should be shared, but I knew that allowing sharing is important.

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

== [[Evolution]] and [[JDeveloper]] ==

== [[Evolution]] and [[JDeveloper]] ==

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such ''common ground'' would give us a chance to ''share''. I was not 100% what are the parts that should be shared, but I knew that allowing it is important.

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such [[module system|common ground]] would give us a chance to ''share''. I was not 100% what are the parts that should be shared, but I knew that allowing it is important.

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

== [[Evolution]] and [[JDeveloper]] ==

== [[Evolution]] and [[JDeveloper]] ==

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such ''common ground'' would give us a chance to ''share''. I was not 100% what are the parts that should be shared, but I knew that allowing it is important.

When I got the task to bring [[JDeveloper]] and [[NetBeans]] closer to each other, I knew we have to start from the basics, from creating a common ground. Thus we invested a lot of time to share the [[Netbinox|module system]] underneath the two products. The short term benefit was the speedup of [[JDeveloper]] launch time. However the long term visition was more important for me: such ''common ground'' would give us a chance to ''share''. I was not 100% what are the parts that should be shared, but I knew that allowing it is important.

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!

However, it was not enough to share components in runtime. We needed to modify the build systems of [[NetBeans]] and [[JDeveloper]] to allow compilation against the [[OSGi]] bundles and modules comming from the other system. This took us a while, but we have such system now - everyone in the two teams can easily start to use libraries provided by the other system. We are ready for [[evolution]]!