Mark, Agreed about you and Gerhard. In the first 10 months DS was in incubation, I was unfortunately working on a project 70-80 hrs/week. With a 1 month overlap, then the last 5 months did something even sillier. Since then though I've been trying to play catch up with where DS ended up (hence the surge in emails). This is also why I took your WindowContext issue and broke it down further, smaller digestable chunks. Hopefully this will help get it implemented faster.
John On Mon, Mar 25, 2013 at 6:09 PM, Mark Struberg <[email protected]> wrote: > well, a roadmap always depends on how much one can spend. > The roadmap for 0.4 originally have been JSF support. This is still the > case. > But with only Gerhard and me doing 80% of the commits it's obvious that we > are not that fast. > > So please just help with the features as well! > > @Pete: it's pretty easy: 0.4 basic JSF support and basic JPA support, 0.5 > even more JSF support and JPA support. > > And then 1.0 is just around the corner. > > LieGrue, > strub > > > > > ----- Original Message ----- > > From: Cody Lerum <[email protected]> > > To: [email protected] > > Cc: > > Sent: Monday, March 25, 2013 3:07 PM > > Subject: Re: DISCUSS DeltaSpike-324 > > > > +1 > > On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <[email protected]> > > wrote: > > > >> I'm currently in the process of porting an application from Seam3 to > >> DeltaSpike, with a clear roadmap I might be able to spend some work > hours > >> in getting stuff forward. > >> > >> > >> On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <[email protected]> wrote: > >> > >> > Hi all, > >> > > >> > At the moment it's really hard for Red Hat to fund more people to > > work on > >> > DeltaSpike. Without a clear roadmap, and a regular release schedule > > (e.g. > >> > time boxed) it's really hard for us to justify more people for > > DeltaSpike > >> > as we can't see how many people we should offer to get to the > > features > >> our > >> > customers need, nor can we see when those features will be available > > for > >> > customers to start using. > >> > > >> > Last time we asked to agree on a roadmap, this group decided it > > wasn't > >> > something that it wanted to do. If we are now able to agree on a > > roadmap > >> > with some sort of regular release schedule (even just having approx > > dates > >> > for a release is good enough) then I can see how I can reprioritise > > our > >> > current work, and get some more help for DeltaSpike, and hopefully > get > > us > >> > closer to 1.0, which is really what I think we are all after (I'm > > not > >> sure > >> > if I will succeed, but right now it's not really worth me even > > trying). > >> > > >> > Pete > >> > > >> > On 24 Mar 2013, at 18:33, Romain Manni-Bucau > > <[email protected]> > >> > wrote: > >> > > >> > > I did a JUG this week with a part on DS and was the main question > > asked > >> > > with those words "when will it be usable?"...kind of > > sad. Releasing > >> even > >> > in > >> > > alpha/beta is better IMO. > >> > > Le 24 mars 2013 19:29, "Jason Porter" > > <[email protected]> a > >> écrit > >> > : > >> > > > >> > >> +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 > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>> > >> > >>>>> > >> > >>>> > >> > > >> > > >> > >> > >> -- > >> Nicklas Karlsson, +358 40 5062266 > >> Vaakunatie 10 as 7, 20780 Kaarina > >> > > >
