Mark,

what's the issue? The thing to take care is to not create a module simply
for integration. But a module by feature is fine and nice IMO.

- Romain


2012/6/27 Mark Struberg <[email protected]>

> 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
> >> >>  > >>
> >> >>  >
> >> >>  >
> >> >>
> >> >
> >>
> >
> >
> >
>

Reply via email to