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