deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernard Łabno <s4...@pjwstk.edu.pl>
Subject Re: cdi-query
Date Tue, 26 Jun 2012 08:31:40 GMT
Did you consider
seam3-persistence-framework<http://blog.it-crowd.com.pl/2012/02/seam3-persistence-framework-comes-to_28.html>which
is seam2 "framework" (the EntityQuery and EntityHome) ported seam3?

2012/6/26 Mark Struberg <struberg@yahoo.de>

> 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 <rmannibucau@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Tuesday, June 26, 2012 12:30 AM
> > Subject: Re: cdi-query
> >
> > +1
> >
> > - Romain
> >
> >
> > 2012/6/26 Gerhard Petracek <gerhard.petracek@gmail.com>
> >
> >>  @ 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 <pmuir@redhat.com>
> >>
> >>  > 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 [struberg@yahoo.de]
> >>  > > Gesendet: Montag, 25. Juni 2012 14:21
> >>  > > An: deltaspike-dev@incubator.apache.org
> >>  > > 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 <pmuir@redhat.com>
> >>  > >> To: deltaspike-dev@incubator.apache.org
> >>  > >> 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
> >>  > >>
> >>  >
> >>  >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message