deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Mon, 25 Mar 2013 14:20:22 GMT
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 <cody.lerum@gmail.com> wrote:

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