deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicklas Karlsson <nicka...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Mon, 25 Mar 2013 14:04:03 GMT
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 <pmuir@redhat.com> 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 <rmannibucau@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.jp@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
> >> <rmannibucau@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.petracek@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 <rmannibucau@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.ament@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
> >>>>>> <rmannibucau@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.ament@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
> >>>>>>>> <rmannibucau@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.petracek@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 <rmannibucau@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.limburg@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 <
> >>>>>>> struberg@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.ament@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
> >>>>>>>>>>>>>> <rmannibucau@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.ament@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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
>
>


-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message