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 <rmannibu...@gmail.com> 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" <lightguard...@gmail.com> 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 >> <rmannibu...@gmail.com> 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" <gerhard.petra...@gmail.com> 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 <rmannibu...@gmail.com> >>>> >>>>> 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" <john.d.am...@gmail.com> 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 >>>>>> <rmannibu...@gmail.com>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" <john.d.am...@gmail.com> 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 >>>>>>>> <rmannibu...@gmail.com>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 <gerhard.petra...@gmail.com> >>>>>>>>> >>>>>>>>>> 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 <rmannibu...@gmail.com> >>>>>>>>>> >>>>>>>>>>> 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" < >>>>>>> arne.limb...@openknowledge.de >>>>>>>>> >>>>>>>>> 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 < >>>>>>> strub...@yahoo.de >>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>>> 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 <john.d.am...@gmail.com> >>>>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> <rmannibu...@gmail.com>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 <john.d.am...@gmail.com> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>
