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
