deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Oliveira <br...@abstractj.org>
Subject Re: DeltaSpike planning
Date Tue, 24 Jul 2012 13:44:19 GMT
+1 

A high level roadmap is really important atm.

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Tuesday, July 24, 2012 at 10:01 AM, Pete Muir wrote:

> I think a high level roadmap, showing how we get from here to 1.0, will help a lot:
> 
> * it will give users confidence that their favourite feature will be added
> * it will give people planning new projects based on CDI an understanding of when they
can start adding DeltaSpike to their project, and allow them to plan out their work better
> * it will allow people (like JBoss projects such as Aerogear) to understand when they
should plan to incorporate DeltaSpike
> 
> 

We've already incorporated DeltaSpike security modules into our demo and currently DS support
is being added to aerogear-controller.
 
> * will give people interested in adding features to DeltaSpike (such as some of the Seam
contributors) an understanding of when it's a good idea to start working on it
> * it will give us a clearer understanding of what our priorities are
> * generally, it gives a picture of "good health" to a project
> 
> On this high level roadmap, we would just have some very basic info e.g.
> 
> 0.4, targeting 01-01-2001:
> 
> * IDM
> * Spring bridge
> * securing REST resources 
> 
> (all for example ;-)
> 
> Obviously, this would need a big warning at the top, that this is the proposed roadmap.
> 
> On 20 Jul 2012, at 18:13, Bruno Oliveira wrote:
> 
> > Hi Jason, 
> > 
> > +1 
> > 
> > Are you talking about the part 4 from https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts,
right? I think that Shane has been working in some ideas to the authentication API and maybe
we could start the discussions about IDM, count me in for it.
> > 
> > 
> > Do you have plans or ideas to authenticate REST resources and token based authentication?
> 
> I think we should, especially if we can have someone like you help us with documenting
the use cases and requirements on the page you mention :-D
> 
> > 
> > -- 
> > "The measure of a man is what he does with power" - Plato
> > -
> > @abstractj
> > -
> > Volenti Nihil Difficile
> > 
> > 
> > 
> > On Wednesday, July 18, 2012 at 7:18 PM, Jason Porter wrote:
> > 
> > > As we near the release for v0.3-incubating I'd like to discuss a couple of
> > > ideas I've been thinking about for a little while.
> > > 
> > > The first is our roadmap, or perhaps more adequately, the lack of a
> > > roadmap. I know we've gotten better at looking at what's next, at least for
> > > v0.4-incubating we're looking at IDM, JSF and possibly Spring and XML
> > > Config. That's better than what we have had in the past. I'd like us to
> > > continue to discuss what and when we plan on doing things. Having that
> > > information up on our site and / or JIRA would be very helpful for our
> > > users, contributors and community at large. I think it also helps us focus
> > > what we're working on for a particular release to minimize creep. I hope we
> > > would end up with a more long term high level roadmap to 1.0. Of course
> > > that roadmap would be subject to change, but at least everyone would know
> > > approximately when their favorite feature would be making its DeltaSpike
> > > debut.
> > > 
> > > Along those lines would be release timing. We haven't had any sort of
> > > schedule we're aiming to keep. The last two releases have been around 8
> > > weeks, but they've drifted, as I recall. I propose we lock down a time
> > > frame for releases, six weeks, eight weeks, whatever it may be. This should
> > > help us with timing and also what goes into the various releases.
> > > 
> > > -- 
> > > Jason Porter
> > > http://lightguard-jp.blogspot.com
> > > http://twitter.com/lightguardjp
> > > 
> > > Software Engineer
> > > Open Source Advocate
> > > Author of Seam Catch - Next Generation Java Exception Handling
> > > 
> > > PGP key id: 926CCFF5
> > > PGP key available at: keyserver.net (http://keyserver.net), pgp.mit.edu
> > > 
> > 
> > 
> 
> 
> 



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