I get you and think we agree behund words. My main issue is our 0.4 is not
ready to be released and still doesnt contain what users are waiting for...

When i spoke about > 1.0 just understand when last release answer basic
needs
Le 24 mars 2013 16:49, "John D. Ament" <[email protected]> a écrit :

> Romain,
>
> I'm not sure what to tell you.  One of our founding statements was release
> early and often.  I'm not sure why we haven't stuck to that.  Personally, I
> think we have failed to do that.  We probably have too many features in a
> single release/ not much release planning/attempt to release everything as
> one big release rather than more modular in nature.  Those are just
> thoughts.
>
> As I already stated, I don't want this in 0.4.  But I don't think it's
> appropriate to stick this in after 1.0, who knows when that will be.  I
> would love to see this in 0.5, already have prototypes working.  My biggest
> issue, as I was trying to raise in the other thread, is that when people
> look at the issue list out there, generally the candidates to work on are
> the unassigned issues.  If 80% of what we have out there is assigned, then
> it's assumed someone's work on it.  If it's assigned to someone and they're
> not working on it, that's probably an issue that needs to be addressed.  As
> far as I can tell, of the 10 unassigned issues out there, none of them are
> comprehensible enough (other than the one I already worked on) to be worked
> through.  So I'm not sure, maybe it's an issue of perception, but I don't
> think we have a large pile of open work for future releases.
>
> John
>
>
> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> <[email protected]>wrote:
>
> > Sure but we cant start everything, finishing nothing...our rare releases
> > are already a pain for users.
> >
> > We need jsf + if possible cdi query for 0.4 IMO then i agree rest helpers
> > are a must have (some tools around jaxrs client part can be great) etc...
> > Le 24 mars 2013 16:13, "John D. Ament" <[email protected]> a écrit
> :
> >
> > > Romain,
> > >
> > > My only issue with this is that I don't think we've mapped out what the
> > > common use cases are (at least based on the email I sent out).  If
> we're
> > > favoring JSF, we're neglecting the growing population of REST APIs for
> > rich
> > > javascript clients (from UI).
> > >
> > >
> > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > > <[email protected]>wrote:
> > >
> > > > yes but JMS is clearly not the most used
> > > >
> > > > can't we push it for the > 1.0?
> > > >
> > > > users really wait the first 1.0 to use DS and adding JMS now simply
> > looks
> > > > like forgetting more common use cases
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/3/23 Gerhard Petracek <[email protected]>
> > > >
> > > > > hi @ all,
> > > > >
> > > > > imo it's more a basic question.
> > > > > if we do it for jms 2, we also have to (/should) do it for other
> > > > > specifications like bv 1.1
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2013/3/21 Romain Manni-Bucau <[email protected]>
> > > > >
> > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
> > > others
> > > > > > stuff are needed before.
> > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> > [email protected]
> > > >
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > We should find out if one can simply use a JMS 2.0
> implementation
> > > and
> > > > > put
> > > > > > > it into an deployment. If that will be possible, we would not
> > need
> > > to
> > > > > > > implement it.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Arne
> > > > > > >
> > > > > > > Am 21.03.13 22:34 schrieb "Mark Struberg" unter <
> > [email protected]
> > > >:
> > > > > > >
> > > > > > > >I tend to lean towards +1 simply because EE-7 containers will
> > take
> > > > > > > >another year (or 2) to become used in projects.
> > > > > > > >
> > > > > > > >I just think we should first close a few tasks before we open
> > new
> > > > > ones.
> > > > > > > >
> > > > > > > >LieGrue,
> > > > > > > >strub
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >----- Original Message -----
> > > > > > > >> From: John D. Ament <[email protected]>
> > > > > > > >> To: [email protected]
> > > > > > > >> Cc:
> > > > > > > >> Sent: Thursday, March 21, 2013 6:09 PM
> > > > > > > >> Subject: Re: DISCUSS DeltaSpike-324
> > > > > > > >>
> > > > > > > >> Romain,
> > > > > > > >>
> > > > > > > >> Generally, I'm mixed about these.  However I think there's
> > some
> > > > > pretty
> > > > > > > >> good
> > > > > > > >> benefits.  For an application developer, maybe none of the
> > other
> > > > > JMS 2
> > > > > > > >> features are useful to you (the bulk of the feature went
> into
> > > CDI
> > > > > > > >>support,
> > > > > > > >> app server integration, and documentation clean up).  You
> > don't
> > > > want
> > > > > > to
> > > > > > > >> move off of TomEE 1.5.x to TomEE Y (which could support Java
> > EE
> > > 7
> > > > > Web
> > > > > > > >> Profile) due to downtime in your application.  There's also
> > lead
> > > > > time
> > > > > > > >> required to impelement JMS 2/Java EE 7 features in your
> > > > application
> > > > > > > >>server,
> > > > > > > >> but perhaps you don't want to or need to wait for the whole
> > > thing.
> > > > > > > >>
> > > > > > > >> This solution would be DS oriented, I believe requires
> > > > > > TransactionScoped
> > > > > > > >> (which could require the transaction classes be moved away
> > from
> > > > > > > >> persistence) to operate properly.
> > > > > > > >>
> > > > > > > >> There's also the case of using DeltaSpike as your CDI-JMS
> > > > > > > >>implementation if
> > > > > > > >> you were a JMS implementer.  I haven't reached out to
> > > communities
> > > > > such
> > > > > > > >>as
> > > > > > > >> Apache ActiveMQ or HornetQ to see input here; I know the
> > current
> > > > > > > >>GlassFish
> > > > > > > >> implementation calls their lower level directly (and not by
> > > > wrapping
> > > > > > the
> > > > > > > >> JMS APIs).
> > > > > > > >>
> > > > > > > >> John
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On Thu, Mar 21, 2013 at 12:30 PM, Romain Manni-Bucau
> > > > > > > >> <[email protected]>wrote:
> > > > > > > >>
> > > > > > > >>>  Hi
> > > > > > > >>>
> > > > > > > >>>  i'm globally -1 for redoing something which will exist
> > > somewhere
> > > > > > else
> > > > > > > >>>  (basically if somebody wants JavaEE just let him use
> JavaEE,
> > > CDI
> > > > > > > >> doesn't
> > > > > > > >>>  need the full stack IMO). Was my point for JPA, more again
> > on
> > > > JMS.
> > > > > > > >>>
> > > > > > > >>>  It is great to add feature before the specs not once it is
> > (or
> > > > > > almost)
> > > > > > > >>>  done.
> > > > > > > >>>
> > > > > > > >>>  Maybe i didnt fully get what you want to do so maybe share
> > > some
> > > > > > > >>>pastebin to
> > > > > > > >>>  be sure we speak about the same stuff.
> > > > > > > >>>
> > > > > > > >>>  *Romain Manni-Bucau*
> > > > > > > >>>  *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > > >>>  *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > > >>>  http://rmannibucau.wordpress.com/>
> > > > > > > >>>  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > > >>>  *Github: https://github.com/rmannibucau*
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>  2013/3/21 John D. Ament <[email protected]>
> > > > > > > >>>
> > > > > > > >>>  > All,
> > > > > > > >>>  >
> > > > > > > >>>  > I'd like to open the floor to discussion for porting
> JMS 2
> > > > > > > >> features to
> > > > > > > >>>  > DeltaSpike, specifically the features that added some
> CDI
> > > > > > > >>>capabilities
> > > > > > > >> to
> > > > > > > >>>  > JMS.
> > > > > > > >>>  >
> > > > > > > >>>  > Details of my rough proposal are here:
> > > > > > > >>>  > https://issues.apache.org/jira/browse/DELTASPIKE-324
> > > > > > > >>>  >
> > > > > > > >>>  > Importing these features start to deprecate
> functionality
> > in
> > > > > Seam
> > > > > > > >>>JMS
> > > > > > > >>>  > (ideal).  These features would give access to an API
> very
> > > > > similar
> > > > > > > >>>to
> > > > > > > >> the
> > > > > > > >>>  > JMS2 API around CDI injection.
> > > > > > > >>>  >
> > > > > > > >>>  > Some limitations:
> > > > > > > >>>  >
> > > > > > > >>>  > - This would not be a JMS implementation, simply an
> > inspired
> > > > > > > >>>interface
> > > > > > > >>>  for
> > > > > > > >>>  > use in Java EE 6/JMS 1.x that leveraged CDI injection
> > based
> > > on
> > > > > the
> > > > > > > >> rules
> > > > > > > >>>  > for CDI injection of these interfaces.  We would bring
> in
> > > very
> > > > > > > >>>similar
> > > > > > > >>>  > annotations that supported the injection of the three
> > target
> > > > > > types.
> > > > > > > >>>  >
> > > > > > > >>>  > - Cannot use the exact interface, since the interface
> > > > implements
> > > > > > > >>>  > AutoCloseable which is a Java SE 7 interface.
>  DeltaSpike
> > > uses
> > > > > > Java
> > > > > > > >>>SE
> > > > > > > >> 6
> > > > > > > >>>  > for a compiler.
> > > > > > > >>>  >
> > > > > > > >>>  > - Internally these would have to use the current JMS
> > > > interfaces
> > > > > of
> > > > > > > >>>  > connection, session.
> > > > > > > >>>  >
> > > > > > > >>>  > - Testing would be feasible but require a full Java EE
> > > > container
> > > > > > > >>>(e.g.
> > > > > > > >> no
> > > > > > > >>>  > testing in Weld/OWB directly) that supported deployment
> of
> > > > > > > >> destinations
> > > > > > > >>>  at
> > > > > > > >>>  > runtime.  Since this doesn't touch MDBs we can manually
> > read
> > > > > from
> > > > > > > >> the
> > > > > > > >>>  > destination.
> > > > > > > >>>  >
> > > > > > > >>>  > John
> > > > > > > >>>  >
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to