Just an update on my progress on this issue - 

- I have back ported all bug fixes from the Fulcrum version.
- I have merged in changes that Henning made in his version of Intake to
allow for multiple xml definition file.
- I have fixed the defect described in TTWS20.
- I have converted all logging to commons-logging

Next:
- Improve error handling & reporting
- Testing
- Update the javadocs, DTD, and xdocs
- Try to come up with some Junit tests

I have had one request to change the the IntakeTool to prevent it from
throwing Exception when on the getGroup(name) method.  I was thinking
about changing this to throw IntakeException which would just be a
subclass of TurbineException.

I could also throw IntakeException to be the exception thrown any time
the intake service encounters an unrecoverable error.  Any comments on
this idea?

> -----Original Message-----
> From: Quinton McCombs [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, December 13, 2002 12:20 AM
> To: Turbine Developers List
> Subject: Changes to intake service
> 
> 
> I am about to start working going through the entire intake 
> service and making some changes.  When I first got started 
> with intake, it was a little confusing at first (2.1).  
> Seeing the posts on the user's list, this is an area where 
> many people seem to have some trouble.  My main goal is to 
> make it a little easier to get working for people new to Turbine.
>  
> Here is a brief list of things that I am planning to address.
> - Better error reporting to the log file.  It can be very 
> difficult to troubleshoot a simple mistake in intake.xml.
> - Fix the problem of not being able to set a mapped property 
> to null.  
> - Update the documentation to fully describe the types of 
> fields, attributes, available rules, etc.  
> - Backport any bug fixes in the fulcrum version back to the 
> coupled version.
> - Update the javadocs
> - Better error handling
> - Develop some JUnit tests
>  
> Is there anything else that anyone would like to suggest?
>  
> Have we decided on what to do about logging?  I suppose that 
> I could just keep it using the current logging mechanism if 
> that debate is not over yet.  
>  
>  
>  
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:turbine-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to