Menu
▾
▴
Re: [Babeldoc-devel] Preparing 1.0 release
|
From: Dejan K. <dej...@nb...> - 2003-05-09 07:01:14
|
> On monday, I want to get in touch with the sourceforge folks to restructure > CVS. I thing that we should remove the old babeldoc module and rename the > babeldoc_v1 to babeldoc. We should also delete the other crud thats out > there. We can then tag that release v1_0 and branch it right there. Agreed. No need for useless CVS modules... > > Bug fixes and incremental fixes to this branch will go in this branch. At the > same time I will get a v1_1 branch opened where we will start development. > The culmination of v1_1 development will be a 1.2 release at which point we > branch again. One tehnical question. If we have branch v1_0 for bug fixes and v1_1 for new development, what should go in HEAD branch? I think new development should go in HEAD branch (main branch) and after every major release we should create branch for bugfixes. For other releases we could just use tags (as we did by now). > > Please comment - unless there is a major objection tomorrow, I will be going > ahead as planned. > > Whats in my future for babeldoc: > > 0. Update outdated libraries > > 1. Commons/discovery > I have been tinkering with this library and have been able to get it working > to the point that I am very confident that this can replace the module > discovery code. I have tested this standalone and in tomcat. > > 2. Compiler > I have also been hacking with Javassist (this is an amazing library) and want > to make a compiler. This compiler will take a pipeline definition and create > a class that will represent the computational steps for that pipeline but all > statically resolved (as far as possible). This will result in performance > benefits. > > 3. Gui > Start a gui framework that we can build and extend into a full blown > Application. > > Thoughts, Comments? I am doing some experiments with scanners and I believe it will be well tested for new release. The main idea right now in my head is to separate code for scanning messages and for processing. Baisicly, I am planning to use classic producer/consumer pattern, where scanners will just get new documents and queue them up. Processing of documents should be done in separate thread by getting documents from queue. Documents in queues should be serialized so in case of some accident they will be loaded application starts next time. I am still not sure if we should use JMS for queueing or write class for this stuff... Anyway, I am planning to use JMX for managment of all these components. I have already wrote some basic code for validation and setting configuration options for scanner workers. The code would simply go from option to option and check option value. The code should also try to set option values if getter and setter methods are avaliable. So if you have username option you could provide getUsername and setUsername methods so validatior could set username property. Now, this code could also be applied to pipeline stages. These are basic differences between scanner and pipelineStage configuration: - PipelineStage options are evaluated in runtime for each document. - PipelineStage options can have suboptions - PipelineStage use PipelineStageConfig and scanners use ScannerWorkerConfig classes. I guess both PipelineStageConfig ans ScannerConfig could be generalized in one class that later could be specialized if necessery. All other problems could be solved by this. Other features that I plan in the near future is some kind of ExcelReader pipeline stage that would create xml file from excel file using Jakarta POI, HttpScanner class and maybe some other features we would need... By the way, next week I am starting Babeldoc training for 4 employees in my company. I guess this will give me better picture how successfull ordinary users can use Babeldoc... Best regards, Dejan > > regards, > Bruce. > On Thursday 08 May 2003 05:41 am, Dejan Krsmanovic wrote: > > I agree. > > Dejan > > > > > By the way: I had a look at the jalopy plugin for ant (before I only had > > > used the one for eclipse). Do you (all of you) really want me to include > > > this in all build.xml files? I would put it in a separate task "format" > > > that should be called manually before committing to cvs. We would of > > > course have to apply it once to all files in the repository - not before > > > friday, I assume... :-) > > > > > > Regards, > > > Hans > > > > > > > > > > > > ------------------------------------------------------- > > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > > > The only event dedicated to issues related to Linux enterprise solutions > > > www.enterpriselinuxforum.com > > > > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > ------------------------------------------------------- > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > > The only event dedicated to issues related to Linux enterprise solutions > > www.enterpriselinuxforum.com > > > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
