OSGi menuntut kita berpikir out-of-the-box terhadap sistem deployment Java, untuk mendapatkan benefit maksimal dari OSGi, pendekatan kita "membagi modul" perlu disesuaikan.
untuk deployment, gw sejauh ini masih pakai FileInstall. edward, do you have any reference in using P2 in server environment? the documentation is too high level and gives the impression that P2 is GUI based. oh ya, komplen gw thd OSGi cuma 1, bundle2nya miskin dokumentasi (bahkan bisa dibilang ga ada). bahkan untuk kubu eclipse, keknya mereka berasumsi kita bakal baca source code bundlenya untuk ngerti tuh bundle kerjanya apa :D ---- salam hangat, Thomas Wiradikusuma Twitter: http://www.twitter.com/wiradikusuma Blog: http://www.jroller.com/wiradikusuma On May 24, 2009, at 6:59 PM, Edward Yakop wrote: > 2009/5/24 sjtirtha <sjtir...@gmail.com>: >> maksud gua bukan heavy dalam artian kilobytes. >> Mungkin kata yg lebih tepat, OSGi cukup komplex. >> Kalo gua analogiin EJB => Spring, dulu EJB punya banyak superclass >> dan >> interface yg perlu diderived utk implementasi java bean. >> Nah kalo SPring kan approachnya POJO yg gampang dimengerti. > > OSGi Services > You could use peaberry or spring-dm or ipojo or osgi DS to manage your > service dependencies and lifecycle. > Otherwise, learn on how to create an OSGi activator, bundle activator > API and ServiceTracker. > > Familiar with spring: > Use spring-dm (http://www.springsource.org/osgi). > > Specific OSGi services: > Http, ConfigAdmin, UPnP etcs. Look at OSGi spec. IMO, One of the > nicest specification to read. > > Create OSGi bundle: > Look at OSGi spec and use bnd, apache felix maven bundle plugin. > IMO. In terms of complexity, It certainly much simpler if compared > to EJB. > > Deployment: > Look at ops4j pax runner tools, Eclipse P2, OSGi OBR > > Testing: > Look at ops4j pax-exam or spring dm osgi test
