[webbeans-dev] jsr299-utils

[David Allen]

On Tue, 2009-05-26 at 13:13 +0100, Pete Muir wrote:
> 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?

Most of the heavy refactoring is now done w.r.t. the JSR-299 API.  The
following items still need to be addressed and will be as quickly as
possible:

1.  BeanManager should no longer have getInstanceByType() or
getInstanceByName(), rather the newer getReference(Bean<?>...) type of
methods.  If that is correct, this refactoring requires more manual
programming on the TCK...it is not something that Eclipse can do
automatically due to the new signatures and objects required.

2.  The @Fires annotation has not been removed yet either.  This too
requires more manual work on the TCK and any other projects that might
have used it.  I will start work on this next.

3.  There are still some exceptions in JSR-299 API that are no longer in
the spec.  These need to be removed, but in each case, a replacement
exception is needed.  Since this might affect quite a few classes, it
would be good to get this done ASAP, but I am not really certain what to
replace the exceptions with.  I probably need to see each case and look
it up in the new specifications.

That should hopefully be all of it.  Everything else should be new in
the SPI and thus would not impact existing TCK tests or extensions, etc.

If it looks like something has been overlooked, please let me know.  If
the impact is large scale, I still have all the projects setup for quick
refactoring in Eclipse.  If the impact is small, then Clint can easily
make the change too while doing the SPI.

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