Romain, this is really almost impossible to maintain if you split the stuff too 
much!

A lot of things are depending on each others. I see absolutely no sense to 
exclude stuff which works perfectly fine in SE and EE just because you would 
not use it. This are 5 classes so far - just don't use them and they wont hurt 
you :)

LieGrue,
strub


----- Original Message -----
> From: Romain Manni-Bucau <[email protected]>
> To: [email protected]
> Cc: 
> Sent: Wednesday, June 27, 2012 5:17 PM
> Subject: Re: cdi-query
> 
> @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
>>  >>>>>>>>>
>>  >>>>>>>
>>  >>>>>>>
>>  >>>>>>
>>  >>>>>
>>  >>>>
>>  >>>
>>  >>>
>>  >>>
>>  >>
>> 
>> 
>

Reply via email to