Disable Jenkins job notification
Hi, I continuously receive Jenkins job notification from DeltaSpike project. Is it possible to disable that ? https://builds.apache.org/job/DeltaSpike Regards -- Charles Moulliard Apache Committer & PMC / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
SpringIntegration status
Hi, Is the spring integration project coming from seam 3 and described here -> https://cwiki.apache.org/confluence/display/DeltaSpike/Spring+CDI+integration still in the radar of the project ? Regards, -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: Feedback on CMS with Github and Asciidoctor
Wonderfull ! On Thu, Aug 28, 2014 at 7:13 PM, Jason Porter wrote: > Great work! > > > On Thu, Aug 28, 2014 at 11:03 AM, Rafael Benevides > wrote: > > > I believe that the work for the asciidoc documentation is ready! > > > > Please, check this generated asciidcotor page: > > http://deltaspike.apache.org/documentation/container-control-test.html > > > > The branch with the source code is here: https://github.com/rafabene/ > > deltaspike/tree/documentation/documentation > > > > > > Em 8/27/14, 18:14, Rafael Benevides escreveu: > > > > Yeap. I have to agree with you. > >> > >> So I've changed my strategy... > >> > >> I've taken your PoC and made some minor modifications and place it on my > >> branch: https://github.com/rafabene/deltaspike/tree/documentation/ > >> documentation > >> > >> Note that I'm using the agreed path for documentation folder and that I > >> also included a Readme.md that instructs how to setup the credentials on > >> ~/.m2/settings.xml and what maven command that should be used to deploy. > >> > >> The result was published here: http://deltaspike.apache.org/ > >> documentation/container-control-test.html > >> > >> What is missing now is the generated html template/styles. > >> > >> > >> Em 8/27/14, 17:23, John D. Ament escreveu: > >> > >>> IMHO, the current approach is a bit safer and more testable. running > >>> mvn site will generate the asciidoc. That would be a bit harder to do > if > >>> we need to support running it as a part of a staging pull. > >>> > >>> > >>> On Wed, Aug 27, 2014 at 4:14 PM, Rafael Benevides < > benevi...@redhat.com > >>> <mailto:benevi...@redhat.com>> wrote: > >>> > >>> I was trying to avoid two steps to deploy: > >>> > >>> 1 - mvn site-deploy on git repo to copy it to the CMS staging are > >>> 2 - CMS deploy to publish it > >>> > >>> But I think that should not be a problem, Right? > >>> > >>> So what I'll do now, based on your PoC is to make the templates of > >>> the generated html to be close to deltaspike site style. > >>> > >>> Em 8/27/14, 17:10, John D. Ament escreveu: > >>> > >>>> Rafael, > >>>> > >>>> This shouldn't be needed any longer. Based on what I did, we can > >>>> now do a mvn site-deploy to copy everything into the CMS staging > >>>> area. Once verified go into CMS and do a publish. > >>>> > >>>> John > >>>> > >>>> > >>>> On Wed, Aug 27, 2014 at 3:57 PM, Rafael Benevides > >>>> mailto:benevi...@redhat.com>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> This email is just to give a feedback about making CMS to > >>>> work with Github and Asciidoc. > >>>> > >>>> Finally I was able to understand enough how CMS works and > >>>> probably I'm stopped where John Ament was. > >>>> > >>>> What I'm doing now is writing a GitUtil Perl Module that will > >>>> be hosted at > >>>> http://svn.apache.org/repos/asf/deltaspike/site/trunk/lib/ > >>>> that will be responsible for cloning the documentation (on > >>>> deltaspike git repo) and then another module will run the > >>>> build (asciidoc to html) just for [/documentation/]. > >>>> > >>>> The idea is that the final documentation gets hosted at > >>>> deltaspike.apache.org/documentation/ > >>>> <http://deltaspike.apache.org/documentation/> (note the sub > >>>> folder). > >>>> > >>>> Further steps: Prepare a template so asciidoc generated html > >>>> uses the same style of deltaspike.apache.org > >>>> <http://deltaspike.apache.org>. > >>>> > >>>> Well, the idea here is to make everyone aware about this and > >>>> also say that if is there anybody if Perl knowledge, you're > >>>> welcome to give some hints! > >>>> > >>>> Thanks > >>>> > >>>> > >>>> -- > >>>> *Rafael Benevides | Senior Software Engineer* > >>>> JBoss Developer > >>>> M: +55-61-9269-6576 > >>>> > >>>> Red Hat > >>>> > >>>> Better technology. Faster innovation. Powered by community > >>>> collaboration. > >>>> See how it works at www.redhat.com <http://www.redhat.com/> > >>>> > >>>> LinkedIn <http://www.linkedin.com/company/3258288> Youtube > >>>> <https://www.youtube.com/redhatlatam> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > -- > Jason Porter > http://en.gravatar.com/lightguardjp > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [VOTE] logo-shape
+1 for #12, #13 On Wed, Jun 11, 2014 at 6:51 PM, Gerhard Petracek wrote: > hi @ all, > > this first vote is just about the basic shape/style and >not< the color. > > i've uploaded the candidates provided by jim at [1]. > please send a +1 for one (or two) logo shape/s. > (there will be a 2nd vote about the color afterwards.) > > regards, > gerhard > > [1] http://s.apache.org/DS_LOGO1_VOTE1 > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Sorry about my previous remark. I was thinking that we would like to integrate the "Spring Integration" project. Confusion around the wording. +1 to move into the direction to integrate Spring AND CDI. This was the motivation of my tweet of yesterday evening but not related to this thread ( https://twitter.com/cmoulliard/statuses/426105815683321856). On Thu, Jan 23, 2014 at 7:42 AM, Romain Manni-Bucau wrote: > @Charles: ? don't get the point. You would like to use camel to bridge > spring and cdi? seems just overengineered and not efficient compared > to real integration + why doing a route, setuping camel context just > for it + you need then to use camel proxies to get a "normal" API > which is a lot to get nothing fancy and surely slow. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014/1/23 Charles Moulliard : > > -1. Why would you like to support Spring Integration while we have Apache > > Camel which is the most elaborated Spring Java Integration Framework > > available today, easier to setup, ... proposing also annotations > @Produce, > > @Consume to produce an exchange from and to a Camel Route (= list of > > processors) > > > > > > On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter >wrote: > > > >> +1 for adding the Spring integration > >> > >> > >> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament >> >wrote: > >> > >> > +1 to Romain > >> > I'd like to see something like this for a 1.0 release. It would be a > >> > real game changer. > >> > > >> > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau > >> > wrote: > >> > > I'd release 0.6 before having it, it will surely create discussion > >> > > once we'll get something and it is easy to do something totally > >> > > brokenn in particular when we'll want to get something clever in a > web > >> > > context > >> > > > >> > > btw we shouldn't do it without pivotal IMO > >> > > Romain Manni-Bucau > >> > > Twitter: @rmannibucau > >> > > Blog: http://rmannibucau.wordpress.com/ > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> > > Github: https://github.com/rmannibucau > >> > > > >> > > > >> > > > >> > > 2014/1/22 Jason Porter : > >> > >> Do we just want to take what we had in Seam 3 and move it over? > >> > >> > >> > >> > >> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > >> > >> gerhard.petra...@gmail.com> wrote: > >> > >> > >> > >>> hi jason, > >> > >>> > >> > >>> the bridge doesn't introduce an api and the spi just provides a > >> simple > >> > >>> contract for starting the container as well as a bean-filter. > >> > >>> -> if needed, we could improve the implementation at any time. > >> > >>> imo we should add it before the release of v0.6 (since a lot of > users > >> > >>> requested such a bridge). > >> > >>> > >> > >>> regards, > >> > >>> gerhard > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2014/1/22 Jason Porter > >> > >>> > >> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to > see > >> > if we > >> > >>> > can get some of there help as well to create a really good > >> > integration. > >> > >>> > > >> > >>> > > >> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > >> > >>> > gerhard.petra...@gmail.com> wrote: > >> > >>> > > >> > >>> >> hi @ all, > >> > >>> >> > >> > >>> >> i would like to continue with this discussion. > >> > >>> >> > >> > >>> >> [1] describes a two-way bridge which is already based on > >> deltaspike. > >> > >>> >> it offers a simple spi which allows more advanced add-ons like > it > >> is > >> > >
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
> > >>> >>> > >>>>>>>>> I guess this is _not_ covered in your proposal,
> right?
> > Imo
> > >>> >>> this
> > >>> >>> > >>> is
> > >>> >>> > >>>>>>>>> perfectly fine, I just mention it for clarity.
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>>> LieGrue,
> > >>> >>> > >>>>>>>>> strub
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>>> - Original Message -
> > >>> >>> > >>>>>>>>>> From: Marius Bogoevici
> > >>> >>> > >>>>>>>>>> To: deltaspike-...@incubator.apache.org
> > >>> >>> > >>>>>>>>>> Cc:
> > >>> >>> > >>>>>>>>>> Sent: Monday, October 15, 2012 8:33 AM
> > >>> >>> > >>>>>>>>>> Subject: [DISCUSS] Spring - CDI Integration in
> > DeltaSpike
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Hello all,
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Please check [1] before you answer.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> I'd like to propose the addition of a new module for
> > >>> >>> integrating
> > >>> >>> > >>>>>>> Spring
> > >>> >>> > >>>>>>>>> with
> > >>> >>> > >>>>>>>>>> CDI. We have discussed this on the e-mail list but
> > let me
> > >>> >>> > >>> provide a
> > >>> >>> > >>>>>>> quick
> > >>> >>> > >>>>>>>>>> rationale for it.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> - it eases adoption of CDI and, by extension, Java
> > EE, in
> > >>> >>> > >>>>>>> environments
> > >>> >>> > >>>>>>>>> with a
> > >>> >>> > >>>>>>>>>> significant existing Spring codebase;
> > >>> >>> > >>>>>>>>>> - it provides a general solution for Spring/Java EE
> > >>> >>> integration;
> > >>> >>> > >>>>>>>>>> - it provides users with more options in choosing
> the
> > best
> > >>> >>> > >>>>>>> components
> > >>> >>> > >>>>>>>>> for their
> > >>> >>> > >>>>>>>>>> application, knowing that they are not locked in
> > either of
> > >>> >>> the
> > >>> >>> > >>>>>>> paradigms
> > >>> >>> > >>>>>>>>> (e.g. a
> > >>> >>> > >>>>>>>>>> user can integrate a project with a strong CDI-based
> > >>> >>> programming
> > >>> >>> > >>>>> API
> > >>> >>> > >>>>>>> with
> > >>> >>> > >>>>>>>>>> something like Spring Batch or Spring Integration);
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Features (proposed)
> > >>> >>> > >>>>>>>>>> -
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> a) bidirectional injection of beans (Spring into CDI
> > and
> > >>> >>> > >>>>>>> vice-versa);
> > >>> >>> > >>>>>>>>>> b) bridging EntityTransaction support between
> > DeltaSpike
> > >>> and
> > >>> >>> > >>>>> Spring;
> > >>> >>> > >>>>>>>>>> c) integrating the CDI event model with Spring (the
> > best
> > >>> >>> > >>> approach
> > >>> >>> > >>>>>>> in my
> > >>> >>> > >>>>>>>>> opinion
> > >>> >>> > >>>>>>>>>> being Spring Integraton rather than the core)
> > >>> >>> > >>>>>>>>>> d) integration with other Spring portfolio projects
> > >>> wherever
> > >>> >>> > >>>>>>> possible;
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> For version 0.4 a minimal goal would be a), followed
> > by b)
> > >>> >>> if
> > >>> >>> > >>>>>>> possible.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> General approach (covers a))
> > >>> >>> > >>>>>>>>>> =
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> For 0.4. my intent, by and large, is to follow the
> > >>> >>> approaches of
> > >>> >>> > >>>>> the
> > >>> >>> > >>>>>>>>> Seam 3
> > >>> >>> > >>>>>>>>>> Spring module (including a code migration), making
> > >>> >>> improvements
> > >>> >>> > >>> on
> > >>> >>> > >>>>>>> its
> > >>> >>> > >>>>>>>>> design
> > >>> >>> > >>>>>>>>>> wherever possible. I intend to create individual
> JIRAs
> > >>> for a
> > >>> >>> > >>> more
> > >>> >>> > >>>>>>>>> detailed
> > >>> >>> > >>>>>>>>>> discussion, but here's the outline:
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> The general principle is that each side (Spring,
> CDI)
> > >>> >>> should not
> > >>> >>> > >>>>>>> know
> > >>> >>> > >>>>>>>>> about the
> > >>> >>> > >>>>>>>>>> existence of the other. Spring beans should be used
> > as CDI
> > >>> >>> beans
> > >>> >>> > >>>>>>>>> transparently
> > >>> >>> > >>>>>>>>>> and vice-versa.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> So where do beans come from?
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Spring beans are exposed through a /resource
> producer
> > >>> >>> > >>> pattern//./
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> @Produces @SpringBean Foo bar;
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Will produce a CDI bean of the type Foo acquired
> from
> > the
> > >>> >>> Spring
> > >>> >>> > >>>>>>> context
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Details:
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>
> > >>> >>> > >>>
> > >>> >>> >
> > >>> >>>
> > >>>
> >
> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us
> > >>> >>> > >>>>>>> age.html#d0e92
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> What Spring context?
> > >>> >>> > >>>>>>>>>> --
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> For flexibility reasons, we do not assume where the
> > Spring
> > >>> >>> > >>> context
> > >>> >>> > >>>>>>> is
> > >>> >>> > >>>>>>>>> coming
> > >>> >>> > >>>>>>>>>> from. Therefore, we allow different mechanisms for
> > >>> >>> accessing a
> > >>> >>> > >>>>>>> Spring
> > >>> >>> > >>>>>>>>> context.
> > >>> >>> > >>>>>>>>>> In fact, multiple contexts can be used for import.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> a) parent web context [3]
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> @Produces @Web @SpringContext ApplicationContext
> > >>> >>> > >>>>> applicationContext;
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> b) Configuration-file based application context [4]
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> @Produces
> > >>> >>> > >>> @Configuration("classpath*:META-INF/spring/context.xml")
> > >>> >>> > >>>>>>>>>> @SpringContext ApplicationContext
> applicationContext;
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> (TBD: issues like auto-import and auto-vetoing, as
> > well as
> > >>> >>> > >>> sensible
> > >>> >>> > >>>>>>>>> defaults)
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> The Spring bean producer can reference a specific
> > context
> > >>> >>> (see
> > >>> >>> > >>>>>>>>> documentation for
> > >>> >>> > >>>>>>>>>> details)
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Note: When we get to the JIRAs we can consider
> > alternative
> > >>> >>> > >>> designs
> > >>> >>> > >>>>> -
> > >>> >>> > >>>>>>> e.g.
> > >>> >>> > >>>>>>>>>> grouping all producers for a particular context in a
> > >>> single
> > >>> >>> bean
> > >>> >>> > >>>>> and
> > >>> >>> > >>>>>>>>> making that
> > >>> >>> > >>>>>>>>>> bean the Spring context reference marker.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Note #2: In regards to the CDISource implementation:
> > I am
> > >>> >>> happy
> > >>> >>> > >>>>> with
> > >>> >>> > >>>>>>>>> reusing
> > >>> >>> > >>>>>>>>>> some of the stuff there, but I have a hard time
> > looking at
> > >>> >>> the
> > >>> >>> > >>>>> code,
> > >>> >>> > >>>>>>> it's
> > >>> >>> > >>>>>>>>>> never been released (as in a Maven release), lacks
> > >>> >>> > >>> documentation,
> > >>> >>> > >>>>>>> and
> > >>> >>> > >>>>>>>>> reverse
> > >>> >>> > >>>>>>>>>> engineering is hard. So if someone that is familiar
> > with
> > >>> the
> > >>> >>> > >>> code
> > >>> >>> > >>>>>>> and
> > >>> >>> > >>>>>>>>> finds
> > >>> >>> > >>>>>>>>>> something particularly apt for reuse, and it's also
> OK
> > >>> from
> > >>> >>> an
> > >>> >>> > >>>>>>> Apache
> > >>> >>> > >>>>>>>>> code
> > >>> >>> > >>>>>>>>>> policy point of view, we should incorporate anything
> > that
> > >>> >>> helps.
> > >>> >>> > >>>>>>> What
> > >>> >>> > >>>>>>> I
> > >>> >>> > >>>>>>>>> am not
> > >>> >>> > >>>>>>>>>> particularly happy with is the approach of
> annotating
> > CDI
> > >>> >>> > >>> injection
> > >>> >>> > >>>>>>>>> points with
> > >>> >>> > >>>>>>>>>> the @Spring marker, which I believe violates
> > separation of
> > >>> >>> > >>> concerns
> > >>> >>> > >>>>>>> - I
> > >>> >>> > >>>>>>>>> consider
> > >>> >>> > >>>>>>>>>> production or auto-registration a better approach
> (CDI
> > >>> >>> targets
> > >>> >>> > >>>>>>> should
> > >>> >>> > >>>>>>>>> not know
> > >>> >>> > >>>>>>>>>> about the provenience of the bean).
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> CDI into Spring integration [5]
> > >>> >>> > >>>>>>>>>> ===
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Conversely, CDI beans can be injected into Spring
> > >>> >>> applications.
> > >>> >>> > >>> To
> > >>> >>> > >>>>>>> that
> > >>> >>> > >>>>>>>>> end, we
> > >>> >>> > >>>>>>>>>> will provide a namespace (and possibly a JavaConfig
> > >>> >>> > >>> configuration
> > >>> >>> > >>>>>>>>> mechanism)
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Structure
> > >>> >>> > >>>>>>>>>> ==
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> The integration can be split into multiple modules,
> > one
> > >>> for
> > >>> >>> each
> > >>> >>> > >>>>>>>>> features above.
> > >>> >>> > >>>>>>>>>> a) can be split into two different modules too.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> Roadmap
> > >>> >>> > >>>>>>>>>> ==
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> I think that the first vote would be for the
> > inclusion of
> > >>> >>> the
> > >>> >>> > >>>>> module
> > >>> >>> > >>>>>>> (or
> > >>> >>> > >>>>>>>>>> modules), followed by discussion of the JIRAs.
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>> [1] http://markmail.org/message/7yefspfuvtz4jvmp
> > >>> >>> > >>>>>>>>>> [2]
> > >>> >>> > >>>>>
> > >>> https://cwiki.apache.org/DeltaSpike/spring-cdi-integration.html
> > >>> >>> > >>>>>>>>>> [3]
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>
> > >>> >>> > >>>
> > >>> >>> >
> > >>> >>>
> > >>>
> >
> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us
> > >>> >>> > >>>>>>> age.html#d0e92
> > >>> >>> > >>>>>>>>>> [4]
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>
> > >>> >>> > >>>
> > >>> >>> >
> > >>> >>>
> > >>>
> >
> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us
> > >>> >>> > >>>>>>> age.html#d0e92
> > >>> >>> > >>>>>>>>>> [5]
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>
> > >>> >>> > >>>
> > >>> >>> >
> > >>> >>>
> > >>>
> >
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManag
> > >>> >>> > >>>>>>> er.html
> > >>> >>> > >>>>>>>>>>
> > >>> >>> > >>>>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>>
> > >>> >>> > >>>>>>
> > >>> >>> > >>>>>>
> > >>> >>> > >>>>>> --
> > >>> >>> > >>>>>> 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, pgp.mit.edu
> > >>> >>> > >>>>>
> > >>> >>> > >>>>>
> > >>> >>> > >>>>
> > >>> >>> > >>>
> > >>> >>> > >>
> > >>> >>> > >>
> > >>> >>> > >>
> > >>> >>> > >> --
> > >>> >>> > >> Jason Porter
> > >>> >>> > >> http://en.gravatar.com/lightguardjp
> > >>> >>> > >>
> > >>> >>> >
> > >>> >>> >
> > >>> >>>
> > >>> >>
> > >>> >>
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Jason Porter
> > >>> > http://en.gravatar.com/lightguardjp
> > >>> >
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jason Porter
> > >> http://en.gravatar.com/lightguardjp
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>
--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [DISCUSS] next release version? 0.6 or 1.0?
gt; >> > >>> > >> > >>> regards, > >> > >>> gerhard > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2013/11/11 Mark Struberg > >> > >>> > >> > >>>> > >> > >>>> > >> > >>>> how should that work? > >> > >>>> > >> > >>>> Please note that we will have some not perfectly > > finished modules > >> very > >> > >>>> often. Basically whenever we add a new module... > >> > >>>> There is just no way to avoid this other than making > > those modules > >> own > >> > >>>> releases. But this does not work out neither (as seen > > on a few other > >> > >>>> projects I don't like to name). > >> > >>>> > >> > >>>> LieGrue, > >> > >>>> strub > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>>> > >> > >>>>> From: Romain Manni-Bucau > > > >> > >>>>> To: Mark Struberg ; > > dev@deltaspike.apache.org > >> > >>>>> Sent: Monday, 11 November 2013, 20:54 > >> > >>>>> Subject: Re: [DISCUSS] next release version? 0.6 > > or 1.0? > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> Well if code is released it should be stable or > > explicitely in > >> > >>>> alpha/beta..maybe we should do subreleases for > > unstables modules > >> > >>>>> Le 11 nov. 2013 18:43, "Mark Struberg" > > a > >> écrit : > >> > >>>>> > >> > >>>>> Oki folks, txs 4 the feedback, all! > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> I'd say we should create the > > module-maturity-matrix.md first and > >> > then > >> > >>>> we might do the version bump. > >> > >>>>>> Maybe something like green/blue/orange/red > > for mature / ready but > >> > still > >> > >>>> needs a few features / ready but might change > > it's api still / work > >> in > >> > >>>> progress > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> LieGrue, > >> > >>>>>> strub > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> - Original Message - > >> > >>>>>>> From: Charles Moulliard > > > >> > >>>>>>> To: dev@deltaspike.apache.org > >> > >>>>>>> Cc: Mark Struberg > > > >> > >>>>>>> Sent: Monday, 11 November 2013, 18:25 > >> > >>>>>>> Subject: Re: [DISCUSS] next release > > version? 0.6 or 1.0? > >> > >>>>>>> > >> > >>>>>>> +1 to move to 1.0. We have done the same > > thing with Apache Aries > >> > moving > >> > >>>>>>> Blueprint from 0.5 to 1.0 release > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> On Mon, Nov 11, 2013 at 6:17 PM, John D. > > Ament > >> > >>>>>>> wrote: > >> > >>>>>>> > >> > >>>>>>>> Yep, agreed. Users care about the > > version #. I would recommend > >> > >>>> that if we > >> > >>>>>>>> could release a 1.0 based on the > > current code base + some > >> > additional > >> > >>>> bug > >> > >>>>>>>> fixes we'll get huge wins. > >> > >>>>>>>> > >> > >>>>>>>> +1 to switching current to > > 1.0.0-SNAPSHOT. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> On Mon, Nov 11, 2013 at 12:08 PM, > > Mark Struberg < > >> > strub...@yahoo.de> > >> > >>>>>>> wrote: > >> > >>>>>>>> > >> > >>>>>>>>> Hi! > >> > >>>>>>>>> > >> > >>>>>>>>> In the last 2 months I did a few > > conference talks and smaller > >> > >>>>>>>>> presentations (OpenBlend, W-JAX, > > ..) and always got the same > >> > >>>>>>> questions: > >> > >>>>>>>>> "it's only a 0.x > > version, so is it already stable? I > >> > >>>>>>> don't like to use it > >> > >>>>>>>>> in production with 0.x" > >> > >>>>>>>>> > >> > >>>>>>>>> And the actual answer is: > > "well, core, cdictrl, etc are stable > >> > >>>>>>> since a > >> > >>>>>>>>> long time, other modules are not > > yet 100% where we like them". > >> > >>>>>>>>> > >> > >>>>>>>>> The other fact is that we will > > never get all our modules 100% > >> > >>>> stable. > >> > >>>>>>>>> Because new modules cannot be > > released with the same quality > >> than > >> > >>>>>>>>> established and well known and > > bugfixed modules. > >> > >>>>>>>>> > >> > >>>>>>>>> Thus I think we should rather > > introduce a kind of > >> majurity-matrix > >> > >>>> for > >> > >>>>>>>>> DeltaSpike. > >> > >>>>>>>>> A simple list of modules and > > their majurity grade. > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> By officially moving to 1.0 we > > would gain much more users. > >> > >>>>>>>>> I personally do not care about > > numbers, but LOTS of users do! > >> > >>>>>>>>> > >> > >>>>>>>>> Wdyt? > >> > >>>>>>>>> > >> > >>>>>>>>> LieGrue, > >> > >>>>>>>>> strub > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> -- > >> > >>>>>>> Charles Moulliard > >> > >>>>>>> Apache Committer / Architect @RedHat > >> > >>>>>>> Twitter : @cmoulliard | Blog : > > http://cmoulliard.github.io > >> > >>>>>>> > >> > >>>>>> > >> > >>>>> > >> > >>>>> > >> > >>>> > >> > >> > >> > >> > >> > > >> > > >> > > > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament wrote: > Yep, agreed. Users care about the version #. I would recommend that if we > could release a 1.0 based on the current code base + some additional bug > fixes we'll get huge wins. > > +1 to switching current to 1.0.0-SNAPSHOT. > > > On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg wrote: > > > Hi! > > > > In the last 2 months I did a few conference talks and smaller > > presentations (OpenBlend, W-JAX, ..) and always got the same questions: > > "it's only a 0.x version, so is it already stable? I don't like to use it > > in production with 0.x" > > > > And the actual answer is: "well, core, cdictrl, etc are stable since a > > long time, other modules are not yet 100% where we like them". > > > > The other fact is that we will never get all our modules 100% stable. > > Because new modules cannot be released with the same quality than > > established and well known and bugfixed modules. > > > > Thus I think we should rather introduce a kind of majurity-matrix for > > DeltaSpike. > > A simple list of modules and their majurity grade. > > > > > > > > By officially moving to 1.0 we would gain much more users. > > I personally do not care about numbers, but LOTS of users do! > > > > Wdyt? > > > > LieGrue, > > strub > > > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Add extra configuration to a bean (Solder)
Hi, This is a point that we have started to discuss before but I would like to continue this discussion. What finaly have we planned to do to allow to add extra configuration to a bean (like we can with spring and propertyplaceholder). Guillaume Nodet has proposed to use Blueprint in combination with CDI and something similar has also been developed with solder project ( http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/introduction.html ) Regards, -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: OSGi support
Hi, Done some tests a couple of months on Apache Karaf where I have deployed DeltaSpike + Camel. When I will have more time (hope in August), I will continue my tests. Regards, On Sat, Jul 13, 2013 at 2:47 AM, John D. Ament wrote: > Hi all > > I was curious about our OSGi support. From what I've seen, it looks like > we mostly handle import and export packages, as well as some pax stuff. > Has anyone tried packaging this into their apps? > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: news feed for our site?
+1 to add latest news and go (for me) to option of openwebbeans On Wed, Jun 12, 2013 at 8:40 AM, Mark Struberg wrote: > Hi! > > We have the option to add a blog to blogs.apache.org. This is just a > plain roller setup but it's a nice goodie to have some blog. > > But the really nice feature is that we are able to add those to our CMS > and setup a buildbot to refresh this on a daily basis. > > There are (at least) 2 options how this could look like: > > http://openwebbeans.apache.org (section "Latest News") > > or > > http://tomee.apache.org/ (section "Latest News") > > > wdyt? > Would not be too much work to set up. > > LieGrue, > strub > > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: [VOTE] [RESULT] Release Apache DeltaSpike-0.4
+1 & sorry to be late On Fri, May 31, 2013 at 5:02 PM, Mark Struberg wrote: > Hi! > > The VOTE has passed with the following > > > +1: John Ament, Cody Lerum Mark Struberg, Florian Hell (nb), Romain > Manni-Bucau, Shane Bryzak, Nicklas Karlsson (nb), Christian Kaltepoth, Ove > Ranheim (nb) Ken Finnigan, Arne Limburg, Gerhard Petracek > > +0: none > > -1: none > > txs all 4 voting! > > > Gonna propagate the artifacts and write the announce once they did hit the > maven.central repo. > > > LieGrue, > strub > > > > - Original Message - > > From: Mark Struberg > > To: deltaspike > > Cc: > > Sent: Tuesday, 28 May 2013, 15:40 > > Subject: [VOTE] Release Apache DeltaSpike-0.4 > > > > Hi! > > > > I'd like to call a VOTE for the release of DeltasSpike-0.4. > > > > The staging repo is: > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-011/ > > > > The tag is available here: > > > https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.4 > > This will get pushed to the ASF repo once the VOTE succeeded. > > > > The source release is available here: > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-011/org/apache/deltaspike/deltaspike-project/0.4/deltaspike-project-0.4-source-release.zip > > sha1: 261897829b42f003ad43a157c607ed931686c482 > > > > > > Guide to testing: > > Add the following to your ~/.m2/settings.xml: > > > > > > staging > > > > > > apache_staging > > > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-011/ > > > true > > > > false > > > > > > > > > > Then upgrade your project to 0.4 and build with mvn -Pstaging. > > > > LieGrue, > > your Apache DeltaSpike Team > > > -- Charles Moulliard Apache Committer / Sr. Enterprise Architect (RedHat) Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
