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