Nemrég jelent meg a JBoss Developer Studio, vagyis a JBoss első teljesen integrált fejlesztési környezete. A következő interjúban a bejelentés hátteréről a JBoss üzletág vezetője és műszaki igazgatója, Sacha Labourey beszél.
Sacha, miről szól ez a bejelentés?
Ez egy jelentős lépést jelent a JBoss eszközökkel kapcsolatos stratégiájában. Néhány hónappal ezelőtt bejelentettük az együttműködésünket az Exadellel, melyen keresztül nyílt forráskódúvá tettük a JBoss fejlesztés számára legjobb integrált fejlesztői környezetet, az Exadel Studio Pro-t, valamint jellemzőinek készletét saját ajánlatunkkal (JBoss IDE, Hibernate IDE stb.) ötvöztük. Ez a munka most befejeződött, és ennek eredményeképpen jelentettük be a JBoss Development Studio (JBDS) első megjelenését.
A JBoss Developer Studio magában foglal mindent, amire a JBoss fejlesztés és alkalmazása során szükség van: gyors EJB3, Seam és Web 2.0 fejlesztés stb. Ez egy tényleg csodálatos termék.
Mialatt mindezek a nyílt forráskódú kiterjesztések szabadon letölthetők, egy könnyen felhasználható csomagban is megjelentek, amit előfizetésként értékesítünk. Az előfizetés áráért nem csak a JBDS-hez lehet hozzáférni, hanem az Enterprise Application Platformhoz (EAP) és a Red Hat Enterprise Linuxhoz is. Tehát alapjában véve ezért az árért mindent megkapunk, amire vállalati szintű alkalmazások fejlesztéséhez van szükségünk; az operációs rendszertől kezdve a teljes EE tanúsított alkalmazásszerveren át a teljes eszköz-készletig. Bár laptopot nem adunk hozzá. 🙂
Stratégiai szempontból a JBoss-nak miért van szüksége egy integrált fejlesztési környezetre? Ez hogyan illik bele a JBoss termékcsaládba?
Amikor a JBoss projekt elindult, csak kevés felhasználónak volt igénye a teljes eszköz-készlet iránt. Ahogy a kritikus pontot átléptük a fejlődésben (crossing the chasm), egyre többen kérdeztek róla, és az Exadel együttműködésen keresztül azt döntöttük el, hogy azt nyújtjuk, amire az ügyfeleinknek szükségük van. Azonban biztosak lehetünk abban, hogy a JBoss továbbra is nyújt majd könnyen felhasználható fejlesztőket középpontba állító jellemzőket, melyeknek a JBoss korai sikerét köszönheti. Itt az értéket nem egyszerűen eladjuk, hanem hozzátesszük.
Mit tartalmaz a megoldás? És alapjában véve a JBDS miben különbözik más Java integrált fejlesztői környezetektől?
A JBDS nem csak általános EE fejlesztéshez nyújt jellemzőket, hanem tökéletesen összhangban van az EAP 4.2 verziójával és fejlettebb fejlesztői jellemzőket is nyújt. Emellett olyan jellemzőket is szorosan integrál, mint a Seam, az Ajax4JSF, a RichFaces (egy nagyszerű JSF vizuális szerkesztővel). Továbbá támogatja a rohamos fejlesztési tempót és a gyors fejlesztési ciklusokat, valamint jBPM támogatást, TestNG-t és Spring IDE-t is nyújt. Ha JBoss fejlesztő vagy, akkor nem vitás, JBDS-t akarsz használni.
Milyen operációs rendszeren képzeled el a JBDS-t?
Jelenleg Windows-on és Linuxon lehet futtatni. Valójában Mac OS X-en is fut, de még nem készültünk el a telepítőjével, ez még folyamatban van, de nemsokára kész lesz.
Az Eclipse Foundationt beválasztották a Java Community Process (JCP) SE végrehajtó bizottságába. Az EclipseLinken és a Swordfish-en keresztül is volt mozgolódás a futásidejű rendszerek területén. Erről blogbejegyzést is írtál. Ez miért zavar téged?
Röviden szólva, nem hiszem, hogy ez lenne az Eclipse Foundation szerepe, és szerintem ezen változás mögött néhány gyártó áll azzal a céllal, hogy saját érdekükben eltérítsék az Eclipse Foundationt. Az Eclipse-et sosem szerver-oldali futásidejű környezetnek szánták; a korai Eclipse tagokkal szemben ez egy lojalitással kapcsolatos kérdésként merül fel.
Mi a helyzet a NetBeans-szel? Vannak tervek, melyekről be tudsz számolni?
Néhány évvel ezelőtt, amikor elkezdtük a JBoss integrált fejlesztői környezet fejlesztését, az akkor világosan vezető pozícióban lévő Eclipse-t választottuk. Azóta a NetBeans nagyon sokat fejlődött, és egy kitűnő integrált fejlesztői környezetté nőtte ki magát. Azonban ez nem változtat Eclipse iránti elkötelezettségünkön. Csakúgy, mint más gyártók, mi sem engedhetjük meg magunknak, hogy ez eszközökkel kapcsolatos stratégiát több integrált fejlesztői környezet platformon építsük ki (Eclipse, NetBeans és Intellij). Választanunk kellett, és ez a választás az Eclipse-re esett.
Eredetileg úgy volt, hogy a JBDS 2007 nyarán jelenik meg. Miért késett ennyit?
Egy kódbázis nyílt forráskódúvá tétele nem egy egyszerű feladat. Sok változtatást kellett végezni, és ezt a lehetőséget általában arra is felhasználjuk, hogy a legnyilvánvalóbb refaktorálási feladatokat is végrehajtsuk. Emellett a JBDS fejlesztési, minőségbiztosítási stb. környezeteket is le akartuk képezni a tipikus JBoss környezetre, így jobban tudunk méretezni és készen leszünk azzal, amit a jövőben a JBDS részeként nyújtani akarunk.
Mindent egybevetve, a JBDS fejlesztői csapata szerintem nagyszerű munkát végzett.
Miért fizetne egy fejlesztő a JBDS-ért, hiszen a JBoss.org-on minden ingyenesen letölthető? Mit kapunk pontosan az előfizetés áráért?
Igaz, hogy a kód és a kiterjesztések is nyílt forráskódúként szabadon elérhetők. Azonban a JBDS részeként megkapjuk az összes régi Exadel kiterjesztést, valamint a korábbi JBoss IDE kiterjesztéseket egy egyesített és minőségbiztosított környezetben. Ezzel sok munkát megspórolhatunk magunknak. Emellett a JBDS előfizetés hozzáférést biztosít az EAP 4.2-höz és a RHEL binárisokhoz is. Az előfizetési díjért alapvetően egy teljes fejlesztői környezetet kapunk: az operációs rendszertől kezdve az eszközökig.
Van még valami, amit hozzá szeretnél tenni az eddigiekhez?
Igen, azt hogy ez a megjelenés egy nagyon fontos mérföldkő a JBoss számára a platform stratégia részeként, aminek a körvonalait 2007 elején alakítottuk ki. Ahogy azt akkor jeleztük, a projektek listájától a platformok világosan meghatározott listájának irányába mozdulunk el. A platformok közül az első, az Enterprise Application Platform (EAP) 2007 nyarán jelent meg, a következő SOA platform (mely magában foglalja majd az ESB-t, a JBoss Drools motort, a jBPM-et stb.) pedig néhány hét múlva jelenik meg.
A JBoss egy nagyszerű egyesítő réteget nyújt a különböző platformoknak az eszközök szintjén, ahhoz hasonlóan, ahogy a JBoss ON egyesíti az ajánlatunkat a menedzsment ajánlat szintjén, a Seam pedig a programozás szintjén. Ez egy három pillérből álló egységesítési stratégia: eszközök, menedzsment és API.
Továbbra is kísérjétek figyelemmel a JBoss munkáját, 2008 egy nagyon izgalmas év lesz!
Köszönöm az interjút.