Agreed, getting a roadmap will help everyone. Users can know when they can move a feature from CODI or Seam3 to DS. Committers can know which issues have top priority in a release and know when to work on it.
RE getting more people, I've been trying to spend more time on this. John On Mon, Mar 25, 2013 at 10:07 AM, Cody Lerum <[email protected]> wrote: > +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 > > >
