Re: [Babeldoc-devel] Preparing 1.0 release

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Dejan,

Good point about cvs - The main branch (MAIN) is the current development 
stream.  So, if you checkin/out code, it will go to MAIN unless to attach to 
the 1.0 branch.

Here is a question?  Your changes to scanner - do you want to get them in for 
1.0??

regards,
Bruce.

On Friday 09 May 2003 03:01 am, Dejan Krsmanovic wrote:
> > 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
>
> -------------------------------------------------------
> 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