deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cody Lerum <cody.le...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Mon, 25 Mar 2013 14:07:35 GMT
+1
On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <nickarls@gmail.com> 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 <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