Romain, Arne.
Please make suggestions which classes/features we should push into which module. Any suggestion is welcome I think our whole JPA functionality is not that huge and are just 30 classes overall. Splitting those into 6 modules (3x api + impl each) might really be too much! LieGrue, strub >________________________________ > From: Arne Limburg <[email protected]> >To: "[email protected]" ><[email protected]> >Sent: Wednesday, June 27, 2012 1:07 PM >Subject: AW: cdi-query > >I completely agree with Romain on that topic > >-----Ursprüngliche Nachricht----- >Von: Romain Manni-Bucau [mailto:[email protected]] >Gesendet: Mittwoch, 27. Juni 2012 11:46 >An: [email protected] >Betreff: Re: cdi-query > >Still not totally agree on modules stuff (should it be pushed in another >thread?), in particular from a user perspective. I think allowing users to >take small bundle or an already aggregated one (shade) is a great feature. > >- Romain > > >2012/6/27 Thomas Hug <[email protected]> > >> @Mark, +1 on not being excessive on the amount of modules. As a user I >> don't think I'd like maintaining another x dependencies, those POMs >> are usually big enough :-) Anyway, depending on the amount of features >> integrating for such a query API, that might well fall into the >> "decent size" category. >> >> @Pete, +1 for the ServiceHandler - IMO very convenient when using >> methods just as metadata (e.g. for calling stored procs, obviously JPA >> queries or a JAX-RS client). >> >> @Jason, Bernard: Agree that I have rarely used the Home API in a >> productive application, still I found it quite handy for prototyping. >> Could be useful to add this on top of a query API (and create e.g. a >> Forge scaffolding provider?). >> >> Cheers, >> Tom >> >> -----Original Message----- >> From: Mark Struberg [mailto:[email protected]] >> Sent: Dienstag, 26. Juni 2012 07:58 >> To: [email protected] >> Subject: Re: cdi-query >> >> I fear that would get us into jarmageddon... >> >> We discussed the module structure at the very beginning, and we all >> concluded that there are 2 reasons for introducing a new module: >> .) a dependency to another project or EE api (like jta, jpa, jsf) >> .) an area which is an completely own block and has a decent size (min >> ~30..50 new classes) >> >> Since the whole JPA area doesn't have more than 10 classes yet, I do >> not see a reason for introducing a new API for them. >> >> Also the whole EE vs SE is moot imo. Either we have a new API or not. >> The classic J2EE patterns are dead dead dead anyway. EE-6 gave us much >> better possibilities, so we should use them and not fall back to _old_ EE >> patterns. >> >> What we could do is to disucss whether the 'jta' module would better >> called 'deltaspike-jpa-ee' and not only contain JTA but also >> TransactionAttributeType handling from EJB? >> >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >> > From: Romain Manni-Bucau <[email protected]> >> > To: [email protected] >> > Cc: >> > Sent: Tuesday, June 26, 2012 12:30 AM >> > Subject: Re: cdi-query >> > >> > +1 >> > >> > - Romain >> > >> > >> > 2012/6/26 Gerhard Petracek <[email protected]> >> > >> >> @ pete: >> >> +1 >> >> >> >> @ java-se vs java-ee features: >> >> >> >> we can think about a more fine-grained structure (similar to seam3). >> >> e.g.: >> >> deltaspike-jpa-transaction >> >> deltaspike-jpa-query >> >> ... >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> 2012/6/25 Pete Muir <[email protected]> >> >> >> >> > Well, we were looking for some good use cases for the ServiceHandler. >> >> > >> >> > I would be in support of adding it to DS core, now we have a >> >> strong >> > use >> >> > case. >> >> > >> >> > Property util should not be controversial. Maybe we can improve >> > it's API >> >> > whilst we are at it :-) >> >> > >> >> > On 25 Jun 2012, at 10:25, Thomas Hug wrote: >> >> > >> >> > > Eventually this came in a little early, but it's already on >> > the radar: >> >> > > https://issues.apache.org/jira/browse/DELTASPIKE-60 >> >> > > >> >> > > The current implementation mainly depends on the Solder >> > ServiceHandler >> >> > (as far as I remember not yet in DS, waiting for CDI 1.1) and >> >> the Property > utils. >> >> > > >> >> > > Cheers, >> >> > > Tom >> >> > > >> >> > > ________________________________________ >> >> > > Von: Mark Struberg [[email protected]] > > Gesendet: Montag, >> >> 25. Juni 2012 14:21 > > An: [email protected] >> >> > > Betreff: Re: cdi-query >> >> > > >> >> > > +1 great stuff to review and add them! >> >> > > >> >> > > That would fit great into the deltaspike-jpa module, wdyt? >> >> > > >> >> > > LieGrue, >> >> > > strub >> >> > > >> >> > > >> >> > > >> >> > > ----- Original Message ----- >> >> > >> From: Pete Muir <[email protected]> > >> To: >> >> [email protected] >> >> > >> Cc: >> >> > >> Sent: Monday, June 25, 2012 1:53 PM > >> Subject: Re: >> >> cdi-query > >> > >> IMO this would be a great thing to add! >> >> > >> >> >> > >> On 24 Jun 2012, at 16:56, Romain Manni-Bucau wrote: >> >> > >> >> >> > >>> Hi, >> >> > >>> >> >> > >>> just browsed >> >> > http://ctpconsulting.github.com/query/1.0.0.Alpha4/index.html >> >> > >> and >> >> > >>> it is really amazing (a spring-data CDI oriented). >> >> > >>> >> >> > >>> it is currently based on solder but since DS integrates a >> > lot of this >> >> > stuff >> >> > >>> i wonder if it could be integrated in DS in a really >> > portable way? >> >> > >>> >> >> > >>> - Romain >> >> > >> >> >> > >> >> > >> >> >> > >> > > >
