Re: [Babeldoc-devel] Preparing 1.0 release

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

No. They are still in experimental phase. I even havent tested it in my
company.
Dejan

----- Original Message ----- 
From: "Bruce McDonald" <br...@mc...>
To: "Dejan Krsmanovic" <dej...@nb...>;
<bab...@li...>
Sent: Friday, May 09, 2003 2:33 PM
Subject: Re: [Babeldoc-devel] Preparing 1.0 release

> 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
>
>
> -------------------------------------------------------
> 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