+1 glad I'm not the only one asking for a roadmap now. — Sent from Mailbox for iPhone
On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau <[email protected]> wrote: > Do we already have a roadmap? I think we should define one by iteration > (+handle a backlog if we want). > I can help on cdi query part if needed (jsf is still a bit too new for me). > Le 24 mars 2013 18:49, "Gerhard Petracek" <[email protected]> a > écrit : >> hi john, >> >> we can't keep it currently (i'm also unhappy about it), because if only 2-3 >> people help on a >regular< basis [1], you have to wait until they have >> time. >> it isn't only about unassigned issues. e.g. not that many help with writing >> tests and examples, writing/reviewing javadoc and documentation. >> >> even the graduation process takes (very) long. >> that might be a big blocker for some users. >> at least codi had several users way before v1 (and for sure even more after >> v1). >> however, we would lose more users, if we release v1 which isn't ready. >> >> >imo< our goal for v1 should be >at least< everything (which we know >> already) we need for improving the java-ee web-profile as well as a stable >> api and spi. >> >> regards, >> gerhard >> >> [1] https://github.com/apache/incubator-deltaspike/contributors >> >> >> >> 2013/3/24 Romain Manni-Bucau <[email protected]> >> >> > 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 >> > > > > > > > > >>> > >> > > > > > > > > >>> >> > > > > > > > > >> >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >>
