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 <strub...@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.limb...@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:rmannibu...@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....@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:strub...@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 <rmannibu...@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.petra...@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 <pm...@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 [strub...@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 <pm...@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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>
