On 25 May 2009, at 16:18, David Allen wrote:
On Sun, 2009-05-24 at 10:21 -0500, Clint Popetz wrote:
> 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?
In general, it is best to pick a small part of functionality to add,
write the tests, complete the implementation, and check that in.
In this case, the moving of existing interfaces (and
renamings/extraction) has wide-spread implications. If you do not
mind,
I am going to complete that part today. So by Tuesday, you should be
able to work on the SPI itself and add the new functionality without
having to worry about breaking things other than the RI and perhaps
any
extensions that might already be dependent on the RI (there
shouldn't be
any yet that I know of).
Agreed, someone (David has volunteered I think) should do a full
update to the jsr299-api, rather than it being done piecemeal.
>
> (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.
Usually not a good idea to break tests. The tests are always a good
way
to make sure your implementation is sound and that you did not break
any
existing functionality. These tests do depend a bit more on the RI,
but
if you use an IDE that can help with the refactoring between RI and
the
JSR-299 API, problems should be minimal.
>
> (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?
I think it might be OK to work on webbeans extensions afterwards.
As I
stated above, though, I should have all the repackaging/renaming done,
and the rest of the work should just be "new" SPI interfaces extracted
from the RI. That should not have any impact on dependent modules.
We
do not usually write code in other modules dependent directly on the
RI.
>
> (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?
Yes, the next release needs to target the latest version of the spec.
This needs to be done before the end of June, but Pete should have a
more exact date for you.
As David says, by the end of June, but really ASAP.
>
> (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?
Another team member is working on tck-audit.xml and should be done
soon.
I would not write any new TCK tests right now without knowing what the
assertion numbers are going to be. Check back later after you have
more
of the SPI done and the TCK is more in-line with the current spec.
Shane has started on this, and we should see the updates starting to
come. Shane, can you let the list know as you go?
>
> Thanks,
> -Clint
>
> On Sun, May 24, 2009 at 7:21 AM, David Allen <drallendc(a)gmail.com>
> wrote:
> On Sat, 2009-05-23 at 16:51 -0500, Clint Popetz wrote:
>> 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?
>>
>
> As of Thursday evening, nobody claimed the SPI changes yet, so
> I think
> it would be OK for you to do that, if you are still
> interested.
>
>
>> -Clint
>>
>> On Sat, May 23, 2009 at 12:32 PM, Gavin King
> <gavin.king(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> webbeans-dev mailing list
>>>>> webbeans-dev(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Gavin King
>>> gavin.king(a)gmail.com
>>>
http://in.relation.to/Bloggers/Gavin
>>>
http://hibernate.org
>>>
http://seamframework.org
>>>
>>
>>
>>
> --
>
> David Allen <drallendc(a)gmail.com>
>
>
>
>
>
> --
> Clint Popetz
>
http://42lines.net
> Scalable Web Application Development
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev