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