VS2010 and VS2012 Unit Test Framework Capabilities

Hello all,
After long time, I have decided to continue share my experiences about software.  Now, I am working on a software project which is related with the Microsoft Technologies such as Silverlight, WCF, Entity Framework, SQL Server etc...
Last month we decided to migrate our development environment from VS2010 to VS2012. This was not very hard but after migration we have reliazed that new test explorer is not meet our needs anymore.
We have to provide our test results in .trx format and test coverage in .coveragexml format. We can easily provide these reports while we were using VS2010. But now VS2012 does not support exporting these files anymore. So we found some workaround solutions to provide these reports but still we have some problems.
I would like to explain what we were doing in VS2010 and what we are doing now on a sample project .

First, I have created 2 sample solution with same structure, one of them is in VS2010 and the other one is in VS2012. Solution structures as shown below.

In VS2010  there was a view called "Test View" for viewing, grouping and running tests. Below images shows flexibility of the "Test View".

In VS2012 there is "Test Explorer" view. Test explorer view is really weak, you can only group tests by project.

   

















Let's run the tests and see what can we do with test results. First, run with VS2010, after running tests "Test Results" view automatically appears.
 This view provides us to export test results in .trx format, copy selected tests and re run selected test etc...

After that, run tests with VS2012. There is extra view is shown, test results is shown in same view. There is no feature to export .trx format and there is no feature to copy selected tests.

 There is a way to export test results in .trx format from out of the solution. I will write another blog how to export test results in .trx format. 

SprinOne2008 - Adrian Colyerin OSGi sunumu notlarım

Bence Adrian Colyer SpringOne2008’in en iyi sunumlarına imza attı. İkinci gün yaptığı keynote sunumu da oldukça başarılıydı. Adrian’ın OSGi a giriş sunumunda aldığım kısa notları paylaşmaya çalışayım.
Sunumun temel hedefi OSGi servis platformunun temel özelliklerini anlamak ve enterprice uygulama geliştirmede kullanımı durumunda sağlayacağı faydaları ve getireceği güçlükleri açıkça belirtmek.
OSGi nedir? The dynamic module system for Java.
Sistem bundle adı verilen pek çok modülden oluşmakta. Modüller runtime da diğer modülleri etkilemeden install, start, stop, uninstall ve update edilebiliyorlar. Sistemin dinamik olmasını sağlayanda bu zaten. OSGi aynı zamanda servis oriented. Bundle lar servis olarak publish edilebiliyorlar. Service registry diğer bundle ların servisleri bulup kullanmasını sağlıyor.
Çok güzel görünen bu dinamizm aslında çok yeni bir teknoloji değil. 1999 da gömülü java sistemleri ve network cihazları için tasarlanmıştı. 2003 de mobil cihazlara genişletildi, 2004 de open source adaptasyonu sağlandı ve 2006 server-side java uygulamalarında kullanılmaya başlandı.
En çok bilinen implementasyonları Eclipse Equinox, Apache Felix, Makewawe Knopflerfish ve Prosyst mBedded Server Professional Edition.
OSGi teknolojisinin halihzırda kullanıldığı yerler:
• Otomativ (BMW, Siemens, Volvo, ...)
• Mobile (Nokia, Motorola, ...)
• SmartHome (Phlips, Bosch, Siemens, ...)
• Enterprice (IBM, BEA, Oracle, SpringSource, Paremus, ...)

OSGi tarihçesi ve kullanım alanlarından bahsedildikten sonra sunum daha teknik konularla devam etti.
Gerekli konseptler:
• Service Platform: Lightweight containerdır. Standalone veya gömülü
olabilir. Ve OSGi service platform core specification ı R4.1 dir.
• Bundle: OSGi da deploy edilen ve modülariteyi sağlayan temel birimdir.
Sadece bir jar dosyasıdır ama META-INF/MANIFEST.MF dosyasına sahip
olmalıdır. Bu dosyada Bundle-SymbolicName, Bundle-Version, Bundle-
Name, Bundle-ManifestVersion, Bundle-Vendor başlıklarıyla tanımlar
yapılabilir.
• Import-Package: Bundle da paket seviyesindeki bağımlılıkları ayarlamak
için kullanılır. Kullanımı:
Import-Package:com.xyz.foo;
Import-Package:com.xyz.foo;version=”1.0.3”
Import-Package:com.xyz.foo;version=”[1.0.3,1.1.0)”
• Versions and Version Ranges: Version syntax:
major.minor.micro.qualifier şeklindedir. [ ] dahil, ( ) hariç için
kullanılır. Örneğin, com.xyz.foo;version=”[1.0.3,1.1.0)” tanımında
1.0.3 versiyonu dahil ama 1.1.0 versiyonu hariçtir.
• Export Package: Diğer bundle ların import eebilmesi için tipi
tanımlar. Kullanımı:
Export-Package: com.xyz.foo
Export-Package: com.xyz.foo;version="1.0.5"
Export-Package: com.xyz.foo;version="1.0.5" com.xyz.bar;version="2.0.0"
Export-Package: com.xyz.foo; com.xyz.bar;version="1.4.1"
Export-Package: com.xyz.foo;version="1.0.3";uses:="org.bar"
• Service Registry: Bir servisin diğer bundle lar tarafından
kullanılabilmesi için publish edilmiş olması gerekir. Publish edilmiş
bir servisi kullanacak bundle bu servisi önce bulur (find) sonra
bind eder.
o Publish: ServiceRegistration reg = bundleContext.registerService
(Bar.class.getName(),null);
...
reg.unregister();
o Find: ServiceReference ref =
bundleContext.getServiceReference(Bar.class.getName());
o Bind: Bar bar = (Bar) bundleContext.getService(ref);
...
bundleContext.ungetService(ref);
// bar should no longer be used here

OSGi ın faydaları:
• Güçlü Modülerlik: Bundle test edilebilir bir black box tır. Bundle bir veya
daha fazla package a export edilebilir. Export edilen bundle ın dışından
bundle a erişim sadece export edildiği package lardandır. Bunun sonucu
olarak modüller arası istenmeden yapılan bağımlılıklar son bulur, bağımsız
geliştirmeye olanak sağlanır ve daha hızlı bir geliştirme döngüsü sağlanır.
• Operational Control: Bütün modüller ve modüllerin durumu görülebilir,
wiring hakkında bilgi alınabilir, bundle lar install, uninstall, activate,
deactivste, update ve stop edilebilir. Tüm bunlar yapılırken çalışan sistemi
durdurmaya veya yeniden başlatmaya gerek yoktur.
• Versioning: Aynı pakette bir bundle ın farklı versiyonları
kullanılabilmekte. Bununla ilgili kısa bir demo da sunum sırasında yapıldı.

Enterprice Uygulamalar için OSGi:

Server Platform olarak OSGi:


Embedded OSGi:



Nested OSGi:



Yukarıdaki grafikleri, OSGi ın enterprice bir uygulama nereye oturduğunu daha iyi kavrayabilmek için ekledim.

Design Kısıtları: Platform dinamik olduğu için kullanılan bir servis herhangi
bir zamanda kaybolabilir, servis bağımlılığının yönetimi gerekli. Test,
uyumluluk ve thread yönetimi de ayrı kısıtlar. OSGi altında enterprise
kütüphanelerin birlikte çalışması class ve resource-loading problemlerine sebep
olmakta.
Enterprise kütüphanelerin OSGi ile çalışabilmelerini sağlamak için SpringSource güzel işler yapmış. Öncelikle Spring 2.5 ve diğer spring projeleri OSGi a hazır durumda. Modüller bundle yapılabiliyor ve OSGi altındaki class loading problemleri çözülmüş durumda. SpringSource Enterprise Bundle Repository ile yüzlerce yaygın kütüphaneyi OSGi bundle olarak sunmuşlar.
SpringSource un son dönemlerde yaptığı işlere ve SpringOne2008 deki sunumlara bakılırsa geleceğin enterprise java dünyası OSGi üzerine dönecek.
Sunum aşağıdakilere dikkat çekerek tamamlandı.
• OSGi is a dynamic module system for Java
• Key concepts: bundles, import/export package, services
• Key benefits: modularity, operational control, versioning
• Key disadvantages: error-prone APIs, integration testing, working with
existing libraries not designed for OSGi
• See Spring Dynamic Modules & the SpringSource Application Platform!

SprinOne2008 Keynote

11,12 Haziran 2008 tarihlerinde Antwerp/Belçika da gerçekleşen SpringOne2008 konferansına katılma imkanım oldu. Sunumlarda aldığım notları kısaca sizlerle paylaşmaya çalışayım.

Seminerin açılışını Spring, SpringSource ve Siz adlı sunumnuyla Rod Johnson yaptı.
İlk olarak spring bilen eleman arayışının artışını aşağıdaki grafikle gösterirken, SpringSource’un verdiği sertifikaların ne kadar faydalı olacağını belirtti.




Daha sonra benim beklediğim şekilde genel hızlı bir bakış yerine sunumuna daha teknik konularda detaylara inerek devam etti. Sunumların hemen hepsinde dikkatimi çeken konfigürasyonların annotation lar yardımıyla yapılması üzerinde epey durdu. Sanırım çok moda olan xml konfigürasyon (en azından benim favorimdi) yerini yavaş yavaş annotation tabanlı konfigürasyona kaptırıyor.

Spring’in dependency injection için gerçekten oldukça iyi bir annotation desteği var. Biraz örneklemek gerekirse:

@Autowired
public void createTemplates(DataSource ds,ConnectionFactory cf) {
this.jdbcTemplate = new JdbcTemplate(ds);
this.jmsTemplate = new JmsTemplate(cf);
}

Annotation autowiring için daha kullanışlı bir yapı sağlıyor. @Autowired default by type wiring yapar. Tip autowiring bazen işimizi görmez, bu durumda @Qualifier annotation ını kullanarak by name wiring yapabiliriz. Annotation ile constructor, metod ve field seviyelerinde injection yapılabilmekte. Örneklerde metod seviyesinde injection var.

public class JdbcOrderRepositoryImpl implements OrderRepository {
@Autowired
public void init(
@Qualifier("myDS")
DataSource orderDataSource,
@Qualifier("otherDS")
DataSource inventoryDataSource,
MyHelper autowiredByType) {
// ...
}


Spring de aynı zamanda stereotype annotation lar da var. Bunlar @Sevice, @Repository, @Aspect ve @Controller, bunların haricinde kendi annotationlarımızı da tanımlayabiliyoruz. Xml’ de



Tanımını yapmak yerine sınıfın başına aşağıdaki gibi @Service yazmamız yeterli.

@Service
public class DefaultAccountService { ...

Annotationlar üzerinde epey durduktan sonra spring in diğer güzellikleriyle sunum devam etti. Sırada spring security vardı. Spring security basit ve güçlü olarak tanımlandı ve tabii ki acegi security ile karşılaştırıldı. Verilen acegi security konfigürasyon dosyası ile spring security konfigürasyon dosyası arasındaki boyut ve anlaşılabilirlik farkı güvenliğin ne kadar kolaylaştığına açık bir delildi.

Spring in temelinde yatan güzelliklerinden biride test edilebilir kod yazmaya yazılımcıları özendirmesi. Integration testing başlığı da sunumdaki yerini aldı haliyle. Spring 2.5 ile annotation tabanlı test framework yeniden gözden geçirilmiş, Junit 4.4 ve TestNG desteği sağlanmış ve JUnit 3.8 in annotation cehenneminden kurtulunmuş. Ayrıca Springin @Autowired ve @Transactional gibi core annotationlarının test sınıflarında kullanılabilmesi sağlanmış. Aşağıdaki örnek test sınıfı kodu bulunmaktadır.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
// defaults to MyTests-context.xml in same package
public class MyTests {
@Autowired
private MyService myService;
@Test
public void myTest() {...}
@Test
@Transactional
public void myOtherTest() { ... }
}

Sıra geldi Spring’in web katmanında aldığı role. Spring 2.0 daki ve 2.5 daki iki ayrı kontroller örneği web katmanındaki annotation desteğini ortaya koyuyor.

Spring 2.0 controller örneği:

public class HotelsController extends
MultiActionController {public ModelAndView index(HttpServletRequest req,
HttpServletResponse res) {…}
public ModelAndView search(HttpServletRequest req,HttpServletResponse res) {…}
public ModelAndView show(HttpServletRequest req,HttpServletResponse res) {…}
}


Spring 2.5 controller örneği:

@Controller
public class HotelsController {
@RequestMapping
public void index() {…}
@RequestMapping
public void search(SearchCriteria criteria, BindingResult result) {…}
@RequestMapping
public void show(@RequestParam("id") Long id)
{…}
}

Spring Web Flow 2.0 da ise tanımlama dili sadeleştirilmiş bununla birlikte daha güçlü hale gelmiş. EL kullanımı genişletilmiş ve flow definition inheritance eklenmiş, ayrıca asenkron event lere ve parçalı update lere destek sağlanmış. Basit bir web flow örneği aşağıdaki gibidir.




JSF üzerine geliştirilen Spring Faces’a da kısaca değinildi.

Sunumun bu aşamadan sonraki kısmı SpringSource reklamı tadında geçti. SpringSource Tool Suite demosu yapıldı. Sunumun sonunda ise geleceğe dair 4 tahmin sıralandı. Bunlar:
• Asıl rekabet application server piyasasında olacak.
• Yarının application server ı daha lightweight ve modüler olacak.
• Application server ile ESB arasındaki boşluk bir köprüyle bağlanacak.
• EJB ölecek.

Hello OSGi

Eclipse plug in leri aslında birer OSGi bundle. Bu ilk OSGi Bundle örneğini de eclipse plug in i olarak yapmak istiyorum. Eclipsi açalım ve aşağıdaki adımları takip edelim.











Örnek projeyi oluşturduktan sonra aşağıdaki gibi eclipse içersinde var olan equinox üzerinde çalıştırabiliriz. Ama ben bu projeden export alıp dışardaki bir equinox üzerinde çalıştıracağım. Bunun bir OSGi implementasyonu olan Equinox u biraz daha iyi anlamamızı sağlayacağını düşünüyorum.



Şimdi, projemizi aşağıdaki gibi export edelim.





Benim dizin yapımda C:\Work\Development\eclipseWorkspaces\plugins dizini altında HelloWorldOsgi_1.0.0.jar dosyası oluştu. Bu bir bundle ve herhangi bir OSGi implementasyonunda çalışmasını bekliyoruz. Şimdi, ayrıca indirdiğim ve C:\Work\Download\tools\eclipse\eclipse-equinox-3.3.2 dizinine açtığım Equinox ile Hello World uygulamamızı çalıştıralım.

Bir command prompt açalım ve Equinox\eclipse\plugins dizinine girelim. ve java -jar org.eclipse.osgi_3.3.2.R33x_v20080105.jar -console komutunu çalıştıralım. jar adının son kısmı Equinox versiyonuna göre farklılık gösterecektir. Sizde olanı çalıştırınız. Karşımızda aşağıdaki gibi bir ekran oluşacak.





Görüldüğü gibi bundle ı install edip çalıştırdık. Stop ettiğimizde de beklediğimiz mesajı verip duracaktır.

OSGi

Son dönemde oldukça popüler olan OSGi teknolojisi üzerine biraz konuşmak istiyorum. Bu teknolojide söz sahibi kurum OSGi Alliance. OSGi Alliance, Mart 1999 yılında Ericsson,IBM, Oracle, Sun Microsystems ve başka bikaç ortaklık tarafından kar amacı gütmeyen bir ortaklık olarak kuruldu. Alliance'ın bir yönetim kurulu var ve oraganizasyon bu kurul tarafından yönetiliyor. OSGi Alliance spesifikasyonu ve
referans implementasyonunu sağlıyor.

OSGi specification'ı, geliştirilmiş servis-yönlü mimarinin temeli olan ağ servisleri için bileşen-yönlü (component-oriented) bir standart tanımlar.
Bir ağ cihazına OSGi Hizmet platformu eklendiğinde, ağın herhangi bir yerinden cihaza
ait yazılım bileşenlerinin yaşam döngüsünün yönetilebilmesi yeteneği eklenir.
Yazılım bileşenleri, cihazın işlemine engel olmadan çalışma anında,
yüklenebilir, güncellenebilir veya çıkarılabilir.

Yazılım bileşenleri kütüphaneler ve uygulamalardır, bunlar dinamik olarak diğer
bileşenleri bulup kullanabilirler. Yazılım bileşenleri standart olarak satın alınabilir veya evde geliştirilebilirler. OSGi Alliance, XML, kullanıcı yönetimi, güvenlik, günlüğe kaydetmek (logging), yapılandırma (configuration), HTTP sunucuları ve daha fazlası gibi ortak işlevler için kullanılabilir pek çok standart bileşen
arayüzleri geliştirdi. Bu bileşenlerin tümüyle-uyumlu (Plug-compatible) geliştirilimleri farklı pazarların gereksinimlerini sağlamaları ve en iyi duruma getirmeleri için farklı üreticilerden sağlanabilir.

OSGi spesifikasyonu başlangıçta ev otomasyon sistemleri ile internet erişimini hedefledi. Fakat, standartın özellikleri başka pazarlara uygulanabilir ve çekiciydi.
Örneğin, Nokia ve Motorola sonraki nesil akıllı telefonlar için bir OSGi teknoloji
standardı kullandı. Araç endüstrisi OSGi teknolojisine, pek çok araç üreticisinin
desteklediği GST spesifikasyonunun ana parçalarını yaparak adapte oldu.
OSGi hizmet platformu BMW nin son teknoloji telematik sistemlerinin standart bir
parçası haline geldi ve pek çok Volkswagenin içine girmenin yolunu buldu, ve
CVIS ve VII gibi standartlar OSGi teknolojisini dikkate alır hale geldi.

Son dönemde daha başka pazarlardan bahsetmek gerekiyor. Bu teknolojinin enterprise java uygulamalarında da kulanılabileceğinin ortaya çıkması üzerine enterprise java dünyasının merakı bir anda OSGi teknolojisine kaydı. Dünyada kabul gören önemli java konferanslarındaki seminerlerin büyük kısmını OSGi teknolojisinin
enterprise dünyaya nasıl adapte edilebileği ile ilgili sunumlar oluşturuyor.

Son yılların ön gözde middleware fromeworkü olan Spring'in de OSGi ile ilgili pek çok çalışması var. Son olarak SpringSource, "Spring Source Application Platorm" adında bir application server sürdü piyasaya. Spring, Tomcat ve OSGi teknolojisinin güçlerini birleştiren bir application server olarak tanımlıyorlar.
Şu anda beta versiyonu var, indirdim deniyorum (defect bile açtım :)), en kısa zamanda bu platformla ilgili deneyimerimi de sizlerle paylaşmayı umuyorum.

Basit bir OSGi örneği ile devam edeceğim...

EJB ve POJO

Yaklaşık 4 senedir enterprise java projelerinde görev almaktayım. Son 2 senedir içerisinde bulunduğum projede Spring, Hibernate ve JSF gibi teknolojiler kullanılarak büyük bir proje yapılmakta, daha önceki 2 senemde içerisinde bulunduğum yine büyük bir projede ise Swing ve EJB 2 kullanılmaktaydı. Bu blogda hem EJB hem de lightweight container lar kullanmış bir yazılım geliştirici olarak bu konulardaki gözlemlerimi paylaşacağım.

Mezun olduğum zamanlar (2002) inanılmaz bir EJB fırtınası esiyordu ortalıkta. Hangi arkadaşımla görüşsem J2EE öğrenmem gerektiğini zaten J2EE öğrenmenin yaklaşık olarak EJB öğrenmek olduğundan bahsediyorlardı bana. Ben o sıralar İstanbulda küçük bir firmada VB 6 da buttonlara onClick() falan yazıyorum. Sonuçta yönelimimi java olarak belirleyip askerlikten sonra kendimi büyük bir şirkette büyük bir projenin ortasında buldum. Projenin mimari yapısı genel olarak EJB kullanılan J2EE projelerine benzemekteydi. Yani, session bean -> DAO -> entity bean çağrıları yapılıp sunum için gerekli alanları barındıran getter ve setter ları olan DTO (Data Transfer Object) lar da client server arası gider gelir. Geliştirimde EJB kaynaklı bazı sıkıntılar yaşamadığımız gibi kafamızda bazı soru işaretleri vardı. Örneğin;
· Entity beanleri insert ve update için kullanıp sorgularda pure SQL kullanıyorduk. (daha sonra entity bean iyice çileden çıkarınca insert ve update ler de SQL le yapılır oldu)
· EJB deployment descriptor lar oldukça karmaşıktı ve karıştımı bir daha toparlaması çok zor oluyordu. Bu sebeple entity bean değişikliklerimizi takımdan bir kişi yapardı, bunun deployment ı da epey sürerdi zaten.
· Session beanler de, entity beanler de ilginç interface leri implement ettikleri için kullanmadığımız pek çok metoda sahiptiler. Ekleyeceğimiz her özellik için session bean de ve DAO da yeni bir metod yazıyorduk, iş kurallarıda session bean de metodun içinde tabii. Bu pratik asıl bakım aşamasında sıkıntı doğurmuştu. 5000 satırlık session beanler ve 500 satırlık metodlar bu şekilde doğuyor.
· Öğrendiğimiz Object Oriented konseptlerle javanın Object Oriented bir dil olmasına rağmen hiç karşılaşmadım. Ortada ne bir Domain Model ne de iş mantığını içinde barındıran özel amaçlı sınıflar vardı. Her şey kafanın içinde.
· DB de herhangibir değişikliğin nereyi patlatabileceği hakkında yorum yapmak oldukça zordu. Gözden kaçan SQL ler olabiliyor. Zaten persistent frameworklerin çıkış amaçlarından biri de SQL karmaşasına son vermek değil mi?
Bu saydıklarımın hiç biri bizim yanlışımızdan kaynaklı sorunlar değil. EJB ile geliştirilen projelerin hemen hepsinde benzer sıkıntılar yaşanmış.

Bu sebeple bazı yazılım geliştiriciler acaba J2EE uygulamaları daha basit bir şekilde yazılamaz mı diye kafa yormuş ki ortaya Spring gibi Hibernate gibi lightweight framework ler çıktı. Yazılım dünyası EJB den Spring, Hibernate ikilisine öyle hızlı kaçtı ki sonradan çıkan EJB 3 belki de hakettiği ilgiyi göremedi. EJB 3 ile yazılım geliştirmedim ama okuduğum kadarıyla geliştiricilerin serzenişleri dikkate alınmış ve daha kullanılabilir bişey çıkmış ortaya. Ama bence hala Spring, Hibernate ikilisinin gerisinde.

Önceki projem de Spring i, Hibernate i duyup biraz okudum. Sonra yönelimimi Spring olarak belirleyim şimdiki projeme geldim :).

Spring in ve Hibernate in bence en güzel yanları Domain Modelinize ve POJO larınıza hiç bir şekilde müdahele etmemeleri. Enterprise bir uygulama geliştirirken transaction management ve security gibi servislere ihtiyaç duyarsınız. Daha önce EJB Container tarafından sağlanan bu servisler Spring ile kolayca sağlanabiliyor. Örneğin bir iş servisinin transactional yapılması için belli bir interface i implement etmesi gerekmiyor, Spring ile bunu 2 satır xml yazarak sağlayabiliyorsunuz. Spring ve Hibernate ile POJO tabanlı yazılım geliştirirken iş mantığınız üzerine yoğunlaşıp gerekli diğer servisler için fazlaca vakit harcamanıza gerek kalmıyor. Aşağıdaki tabloda kalsik EJB tarzın ve POJO tabanlı yazılım geliştirmenin kısa bir karşılaştırması yapılmıştır.


Klasik EJB tarzı:
Organizasyon: Prosedural tarz kodlama
Implementation: EJB tabanlı
Database erişimi: JDBC/SQL veya Entity bean
Sunum katmanına dönülen veri: DTO lar
Transaction Management: EJB container managed transactions
Application Assembly: Explicit JNDI lookup

POJO tabanlı:
Organizasyon: Object Oriented dizayn
Implementation: POJO
Database erişimi: Persistence Framework
Sunum katmanına dönülen veri: Business Objects
Transaction Management: Spring Framework
Application Assembly: Dependency Injection

EJB, yazılım geliştiricileri prosedural tarzda kodlamaya zorlarken, POJO tabanlı geliştirim herahangi bir tarza zorlamaz. Eski alışkanlıklar sebebiyle pek çok POJO tabanlı geliştirilen yazılımda maalesef prosedural tarzda geliştirilmeye devam etmiştir. POJO lar birer DTO gibi sadece alanlar ve getter setter larıyla doldurulmuş iş mantığı yine servislere yığılmıştır. Aslında iş mantığının karmaşık olmadığı durumlarda bu tarz geliştirim daha mantıklı olabilir, fakat ortada karışık bir iş mantığı varsa bu mantığı POJO lara koymak ve Object Oriented konseptlerden faydalanmak daha akıllıca olur. Bu konu Martin Fowler ve Chris Richardson gibi ustaların bloglarında da yer almış ve literatüre Anemic Domain Model ve Rich Domain Model olarak geçmiştir.

Schema Export with Ant

After some difficulties I have run schema export with ant. We use a separate propeties file with the same content as the jdbc.properties file that is used in connecting applications to the DB, in order to run the schema export task. Actually schemaexport also have "properties" attribute but it throws an exception like this.

[schemaexport] java.lang.UnsupportedOperationException: The user must supply a JDBC connection
[schemaexport] at org.hibernate.connection.UserSuppliedConnectionProvider.getConnection(UserSuppliedConnectionProvider.java:30)
[schemaexport] at org.hibernate.tool.hbm2ddl.ManagedProviderConnectionHelper.prepare(ManagedProviderConnectionHelper.java:28)

hibernate.cfg.xml





build.xml





You can download here working copy of our sample project.