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