Min ändå kommentar är att "db" i detta paket verkar överflödigt:
se.vgregion.dao.domain.patterns.repository.db.jpa
dvs, jag föreslår:
se.vgregion.dao.domain.patterns.repository.jpa
> Jag har dock även
> funderat på att försöka få bort hibernate-beroendet för jpaVendor men
> kunde inte komma på något bra sätt utan att låta en klient göra om
> hela konfigurationen. Man kanske kunde tillhandahålla ett antal
> default-konfigurationer för olika vendors? Om man inte är nöjd med
> någon av dessa så får man göra en egen konf?
Min åsikt är att jpa-infrastructure-configuration.xml inte hör hemma i
ett lib som detta. Det binder inte bara in Hibernate utan även
konfigurering av transaktionsbeteende och datakällan, alla något som
man istället bör hantera närmre deployment (förslagvis i en modul). I
VGRs fall verkar det mer relevant att skapa upp denna inom ramen för
scaffolding-pluginet.
/niklas
2010/10/17 Anders Asplund <aasp...@gmail.com>:
Har gjort en del förändringar i paketstrukturen i dao-fwk. Om dessa
funkar för dig så är jag redo för en release.
Min ändå kommentar är att "db" i detta paket verkar överflödigt:
se.vgregion.dao.domain.patterns.repository.db.jpa
dvs, jag föreslår:
se.vgregion.dao.domain.patterns.repository.jpa
Jag har dock även
funderat på att försöka få bort hibernate-beroendet för jpaVendor men
kunde inte komma på något bra sätt utan att låta en klient göra om
hela konfigurationen. Man kanske kunde tillhandahålla ett antal
default-konfigurationer för olika vendors? Om man inte är nöjd med
någon av dessa så får man göra en egen konf?
Min åsikt är att jpa-infrastructure-configuration.xml inte hör hemma i
ett lib som detta. Det binder inte bara in Hibernate utan även
konfigurering av transaktionsbeteende och datakällan, alla något som
man istället bör hantera närmre deployment (förslagvis i en modul). I
VGRs fall verkar det mer relevant att skapa upp denna inom ramen för
scaffolding-pluginet.
[klipp bort övrigt då jag inte har några starka åsikter]
> En annan sak som jag funderar över är om man kanske skulle nöja sig med en
> implementions-jar då eventuella implementationer blir ganska små (din
> inmemory t.ex.). Vad tror du om det?
Problemet med detta kan jag tycka är att det antingen drar med sig en
rad beroenden, eller så får man sätta beroenden till optional vilket
gör att Mavens transitiva beroenden inte längre blir automatiska. Så,
jag tror nog ändå att nuvarande struktur är bättre.
/niklas
Grymt!
/niklas