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

Reply via email to