Ok, I understand that point. Would it be fine to just have them in separated packages?
LieGrue, strub >________________________________ > From: Romain Manni-Bucau <[email protected]> >To: Mark Struberg <[email protected]>; [email protected] >Sent: Wednesday, June 27, 2012 7:53 PM >Subject: Re: cdi-query > > >Not really, myfaces is not here. >And you are as bas as me wanting to impose your view Mark. >One jar by purpose is easier to maintain or patch too...one jar by class is a >pain. >On the ee/jee i think it is important to split to ease people to understand >what they use. >- Romain >Le 27 juin 2012 19:24, "Mark Struberg" <[email protected]> a écrit : > >This is a perfectly bad example! With this shaded jar you cannot easily >upgrade single projects like MyFaces to a newer version... >> >>LieGrue, >>strub >> >> >> >>----- Original Message ----- >>> From: Romain Manni-Bucau <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Wednesday, June 27, 2012 5:22 PM >>> Subject: Re: cdi-query >>> >>> javaee-api in openejb for instance: >>> http://svn.apache.org/repos/asf/openejb/trunk/javaee-api/pom.xml >>> >>> - Romain >>> >>> >>> 2012/6/27 Pete Muir <[email protected]> >>> >>>> 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 <[email protected]> >>>> > >>>> >> 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 <[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 >>>> >>>>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>> >>>> >> >>>> >> >>>> >>>> >>> >> > >
