It works, but is a PITA to maintain!
There are of course small issues with JavaDocs and Sources if it gets more 
complicated ...
Shading is only the ultimo ratio and shall only be used to slice modules 
because they would introduce another dependency.


LieGrue,
strub



----- Original Message -----
> From: Pete Muir <[email protected]>
> To: [email protected]
> Cc: 
> Sent: Wednesday, June 27, 2012 5:19 PM
> Subject: Re: cdi-query
> 
> 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
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>

Reply via email to