Great, I'll get started on it Tuesday.
I haven't done work on the core before, only on extensions, and I haven't dealt with the TCK at all. So I have a few questions with regard to the webbeans development process:
(1) I'm going to start by focusing on javax.enterprise.inject.spi. This means some pretty heavy refactoring, including repackaging javax.inject.* and changing Bean and Decorator to be interfaces, which is going to ripple through the whole source base. Is it preferred that this is committed in small chunks, even if that means the resulting source base is not buildable in between commits, or should I commit them in the smallest chunks that allows the core to build, which in this case might be rather large?
(2) Is it acceptable to cause test failures in webbeans-core-test during the early stages of this work, or should I be fixing all tests as I go.
(3) Given that the work involves repackaging/renaming, a lot of things are going to break in dependent modules. Should I be checking/building/testing these other modules, and in particular the webbeans extensions, as I'm making these changes, or can they be corrected at a later date?
(4) What is the timetable for reaching the next release milestone with these changes, i.e. will the next webbeans release target this draft of the spec, and if so, what is its target date? Is there an internal stabilization/qa process on that release?
(5) With regard to the TCK, should I be adding TCK tests as I'm implementing the SPI? If so, does the TCK target a specific revision of the spec? (It's not clear to
me if the spec itself is even versioned during the draft process.) For example,
right now the contents of tck-audit.xml and many of the @SpecAssertions
don't match the current spec, as it just came out. So is it ok to add tests to
tck-impl that target things in the new spec (for example, 11.2 to test
the BeanManager SPI), given that these new @SpecAssertions will overlap
with existing assertions for similar numbers in the older spec, and
given that the audit tool will report garbage for the new assertions?
Thanks,
-Clint
On Sat, 2009-05-23 at 16:51 -0500, Clint Popetz wrote:As of Thursday evening, nobody claimed the SPI changes yet, so I think
> I'm happy to start work on it, but I don't want to step on someone
> else's work. Has any work on the SPI changes been allocated?
>
it would be OK for you to do that, if you are still interested.
David Allen <drallendc@gmail.com>
> -Clint
>
> On Sat, May 23, 2009 at 12:32 PM, Gavin King <gavin.king@gmail.com> wrote:
> > We need an impl of the SPI as soon as possible, since we need to know
> > if there's any bugs in it :-)
> >
> > On Sat, May 23, 2009 at 5:07 AM, Clint Popetz <cpopetz@gmail.com> wrote:
> >> Matt,
> >>
> >> Thanks, 11.4 in the spec (BeanManager.createInjectionTarget and
> >> InjectionTarget.inject) is exactly what I need.
> >>
> >> So, who's implementing that, and what's the time frame for it? I can
> >> do that, if no one's scheduled it do it.
> >>
> >> -Clint
> >>
> >> On Fri, May 22, 2009 at 11:03 PM, Matt Drees <matt.drees@gmail.com> wrote:
> >>> Oops, meant to send that to the list, not just Clint.
> >>> Sorry for the dup, Clint.
> >>>
> >>> -Matt
> >>>
> >>> On Fri, May 22, 2009 at 11:58 PM, Matt Drees <matt.drees@gmail.com> wrote:
> >>>>
> >>>> Before you go too far down this road, you might want to get a new draft of
> >>>> the spec from Gavin. Recently an SPI was added specifically for injection
> >>>> into third-party objects, so I don't think the project you're proposing
> >>>> needs to exist.
> >>>>
> >>>> -Matt
> >>>>
> >>>>
> >>>> On Fri, May 22, 2009 at 6:34 PM, Clint Popetz <cpopetz@gmail.com> wrote:
> >>>>>
> >>>>> I'm investigating how to best move non-contextual injection into a
> >>>>> webbeans extension that's jsr299-impl independent. While I could
> >>>>> rewrite a stripped down version of the reflection scanning/caching
> >>>>> code that is already used by the existing webbeans-specific
> >>>>> non-contextual-injector, but it wouldn't be as performant or compliant
> >>>>> as the code that's already in the core, and I'm wondering if it's
> >>>>> reasonable to try to break out this chunk of the core into a library
> >>>>> which my extension (and possibly others in webbeans-extensions) uses.
> >>>>>
> >>>>> These would be some coherent self-contained subset of
> >>>>> org.jboss.webbeans.{injection, introspector, introspector.jlr,bean,
> >>>>> metadata, util}. I think of this as the part of the core that
> >>>>> examines classes and builds a metamodel about the beans they
> >>>>> represent, and knows how to inject them, but doesn't deal with
> >>>>> contexts, bootstrapping, and the zillion other things the core does.
> >>>>> I think it could probably be made implementation-independent based on
> >>>>> the jsr299-api. It would have to be made independent of ManagerImpl,
> >>>>> mainly.
> >>>>>
> >>>>> It couldn't live in webbeans-extensions obviously, since the core
> >>>>> would depend upon it. But if it lived in webbeans-model, then
> >>>>> webbeans-core could depend on it, as could jsr299-utils.
> >>>>>
> >>>>> Thoughts? This is not terribly well investigated yet, so those with
> >>>>> more experience with the source base, feel free to wave me off. I
> >>>>> just hate duplicating code.
> >>>>>
> >>>>> Thanks,
> >>>>> -Clint
> >>>>>
> >>>>> --
> >>>>> Clint Popetz
> >>>>> http://42lines.net
> >>>>> Scalable Web Application Development
> >>>>> _______________________________________________
> >>>>> webbeans-dev mailing list
> >>>>> webbeans-dev@lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> webbeans-dev mailing list
> >>> webbeans-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Clint Popetz
> >> http://42lines.net
> >> Scalable Web Application Development
> >>
> >> _______________________________________________
> >> webbeans-dev mailing list
> >> webbeans-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >>
> >
> >
> >
> > --
> > Gavin King
> > gavin.king@gmail.com
> > http://in.relation.to/Bloggers/Gavin
> > http://hibernate.org
> > http://seamframework.org
> >
>
>
>
--