deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: cdi-query
Date Wed, 27 Jun 2012 15:22:14 GMT
javaee-api in openejb for instance:
http://svn.apache.org/repos/asf/openejb/trunk/javaee-api/pom.xml

- Romain


2012/6/27 Pete Muir <pmuir@redhat.com>

> Do you have some good examples of shade working well, I've never ever seen
> it be a good approach for frameworks.
>
> On 27 Jun 2012, at 11:17, Romain Manni-Bucau wrote:
>
> > @Pete: DS can deliver fine grain modules which are nice for some part of
> > the users and shade modules ("big jar") for advances user. Just a maven
> > trick. this way everuone is happy and honestly today any nice IDE
> supports
> > it without any issue.
> >
> > - Romain
> >
> >
> > 2012/6/27 Pete Muir <pmuir@redhat.com>
> >
> >> It's insanely complex for a new user. Java is already confusing, with
> it's
> >> hundreds of libs. Adding more complexity to packaging won't help with
> >> DeltaSpike adoption IMO.
> >>
> >> On 27 Jun 2012, at 07:58, Romain Manni-Bucau wrote:
> >>
> >>> 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 <struberg@yahoo.de>
> >>>
> >>>> 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 <arne.limburg@openknowledge.de>
> >>>>> To: "deltaspike-dev@incubator.apache.org" <
> >>>> deltaspike-dev@incubator.apache.org>
> >>>>> 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:rmannibucau@gmail.com]
> >>>>> Gesendet: Mittwoch, 27. Juni 2012 11:46
> >>>>> An: deltaspike-dev@incubator.apache.org
> >>>>> 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 <Thomas.Hug@ctp-consulting.com>
> >>>>>
> >>>>>> @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:struberg@yahoo.de]
> >>>>>> Sent: Dienstag, 26. Juni 2012 07:58
> >>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>> 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 <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