Menu
▾
▴
Re: [Babeldoc-devel] On how to commit
|
From: Vincent H. <vin...@hu...> - 2003-06-26 14:26:25
|
Hi, I used to work on xdoclet but this is no more the case nowadays. Anyway I know it quite well. scanner and pipeline stages: service/query.properties could be generated by a xdoclet task as you propose. module: A MyShinyModule could also have xdoclet tags to generate the build.properties (there is an overlap between Depends there and the depends in MyShinyModule.java), the services/com.babeldoc.core.module.BabeldocModule file I am not sure this would be a good idea : a good doc would be more simple to catch by the beginners i18n: The properties files could also be generated from xdoclet tags : xdoclet itself uses a special module to do that. servlet: the web.xml can be generated Apart from that I do not see anything else, but xdoclet can quickly help a lot. Vincent > Dejan, Vincent, All: > > Looking good - thanks for the good work. We really need lots of work > here with the web console. Vincent, I believe that you are involved > with XDoclet. Would you be prepared to think about how to get xdoclet > into babeldoc. I have some code that uses xdoclet in the build. My > code (not checked in) allows you to put a tag (@babeldoc.service > PipelineStage.MyShinyStage) in code which needs to become a service - > this then gets added to the config/service/config.properties file. I > have also added the @web tags to the console, and httpfeeder servlets. > What else can you think of that can benefit from this most excellent > tool? Also when we start on the J2EE module, we will need to get > XDoclet working with this. Additionally we can use its tags for JMX to > help us make MBeans. > > looking forward to hearing some ideas here! > > regards, > Bruce. > > On Wednesday 25 June 2003 03:25 am, Dejan Krsmanovic wrote: >> On how to commitHi Vincent >> >> > - The addMessage tin the error handler saves the complete statck >> trace in >> >> case of exception (with jakarta commans lang ExceptionUtils) >> >> >> >> To be honest this method was a workaround for some problems I had (I >> needed some way to inform users what happend to their document). I >> guess there are better ways of doing it. At least, I don't like this >> method's name. But if you have found this method usefull - feel free >> to change it. >> >> > - SmtpWriter will not add a Body in case smtpMessage is blank (A >> blank >> >> body is not good, No body is better) : else that breaks smtp/x400 >> gateway >> >> >> >> OK. I like that. I guess this won't break existing pipelines, right? >> >> > - I added some velocity pages to see only failed tickets, and in >> general >> >> to make the web console look a bit nicer. This is a place where I ant >> to do some more in the near future. >> >> >> >> Cool. We need much improvements here. I think that part of Babeldoc is >> still in the same state as before. >> >> > - The Lock mechanism on FtpWriter : optional parameter to send a >> lock >> >> file before sending the file and look if it does not exist before >> sending them >> >> >> >> I guess it is OK as long as this stage works as before when locks are >> not used. >> >> > - etc. >> > Are you OK with these ? >> > I have done all that on branch 1.0 so I want now to patch back the >> main >> >> branch. >> >> >> Excelent. I am OK with all these. Others? Vincent, could you also >> update changes file? >> >> > I have seen the changes on the scanner : It is great but at the same >> time, >> >> running babeldoc in "synchronized" mode is sometimes more easy to >> debug (else the threads gets mixed together) : Have you think a >> parameter at the scanner level to force it to work "as before" in >> synchronize mode ? >> >> >> Scanner module is still in development phase. I haven't switched all >> workers to use new way of feeding. As you might noticed scanner works >> with IFeeder, so it could work with Synchronous and Asynchronous >> feeder. It will use ScannerFactory to get IFeeder implementation >> class. Right now, this method d oes not use configuration file - it is >> hardcoded and it only returns new Asynchronous feeder. But we plan to >> make that configurable, too. >> >> What is your opinion is it better to keep this configuration in >> separate file or it should be part of scanner configuration? Also, >> should this be hardcoded (something like switch) or we should let >> users to specify its implementation class like we do with >> ScanerWorkers? That way users will have more freedom but currently I >> don't see some benefits of it! >> >> >> All, note that 1.1 release will be developmental - many new features >> but not stable enough. I suggest we should soon release one stable >> version - 1.0.2 with Vincent's changes, and probably some other >> changes. Are you all OK with that? Are there other changes/fixes we >> should put in this release? >> >> >> Dejan >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: INetU >> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! INetU Dedicated Managed Hosting >> http://www.inetu.net/partner/index.php >> _______________________________________________ >> Babeldoc-devel mailing list >> Bab...@li... >> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
