[webbeans-dev] jsr299-utils

[David Allen]

I should also have noted that the Examples have not been updated yet.  I
think we can wait on that one for a day or two.

On Tue, 2009-05-26 at 15:10 +0200, David Allen wrote:
> 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.
> > 
> > >
>