From: Artur H. <ko...@pl...> - 2003-10-02 20:15:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, They are not changes indeed, they are rather adds to existing set of features. I always try to preserve current functionality and keep it compatible with earlier versions. So if something works bad on your system let me know. But lets present new features and ideas: 1. Started to add support for Java tools. They are important for at least 2 reasons: - (S)DocBook XSLT extensions are only implemented for Java tools - PDF generation (FOP -> PDF) is only implemented in Java tools 2. Some limited support for catalogs for Java tools 3. Let me return to keeping docbook XSLT in CVS repository issue. I don't like this idea, however I agree that we should provide complete environment with all necessary libraries. Our needs are not limited to those XSLT templates but I see also some Java jars as usefull, at least SDocBook DTD (because we use it for our guides), fop library to generate PDFs and probably some more. Keeping all libraries in CVS repository forces us to use outdated versions or constant updating our repository with new releases. So I propose to not keep external libraries in our CVS repository at all. But on the other hand we should include them in release of our environment. So joining all necessary external libraries should be part of package build process. Since they are all available on the net, it seems to me easy to create appropriate script downloading, unpacking and preconfiguring them. This script could be used as an automatic tool for building generguide release or for downloading libraries when generguide is used directly from CVS. I became real user of generguide project. I use it for 2 different kinds of documentation development. At work I base on Generguide our internal developers guide with some modifications - use all features of generguide and for separate document written in Sdocbook so I use generguide only script and libraries. And as a real user I try to change generguide to my needs. I hope this is correct, if not let me know I will revisit my approach. I understand that all important changes should be discussed first but if I have to do something I have a choice: 1. to write separate tool for this or 2. to extend generguide with lacking feature. Below I present what I am going to do in very short future: 1. Complete support for Java tools 2. Support for generating PDF files (FOP) 3. Script downloading and installing in generguide hierarchy the last releases of all necessary libraries - docbook xsl - fop - sdocbook dtds (they are necessary for complete catalogs support) 4. Complete support for both cygwin and linux systems. And probably (I am not sure yet if I will be able) 5. Generguide HOWTO Assuming you agree with my changes I have one issue: Do you prefer to develop Java-tools support in separate script or include it in existing one? 1. Separate scripts make them a little bit simpler however forces us to do some things in two places 2. One script will become a little bit complex but many actions will be implemented only in one place. I prefer to do one script now and maybe later divide it into more parts. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fIcs0/6x1bjSKPkRAl5HAJ9SVN4xay76Pa8DBBWAFKVQBdBFHgCfXCnN 9IWgX3WxLEQiuAWRCt53yyM= =FVYo -----END PGP SIGNATURE----- |
From: Cameron S. <ca...@sh...> - 2003-10-02 21:27:12
|
On Friday 03 Oct 2003 6:14 am, Artur Hefczyc wrote: > But lets present new features and ideas: > 1. Started to add support for Java tools. They are important for > at least 2 reasons: > - (S)DocBook XSLT extensions are only implemented for Java tools > - PDF generation (FOP -> PDF) is only implemented in Java tools Great. > > 2. Some limited support for catalogs for Java tools ok. > > 3. Let me return to keeping docbook XSLT in CVS repository issue. > I don't like this idea, however I agree that we should provide > complete environment with all necessary libraries. > Our needs are not limited to those XSLT templates but I see also > some Java jars as usefull, at least SDocBook DTD (because we use > it for our guides), fop library to generate PDFs and probably some > more. Keeping all libraries in CVS repository forces us to use outdated > versions or constant updating our repository with new releases. > > So I propose to not keep external libraries in our CVS repository at > all. But on the other hand we should include them in release of our > environment. So joining all necessary external libraries should be part of > package build process. > Since they are all available on the net, it seems to me easy to create > appropriate script downloading, unpacking and preconfiguring them. > This script could be used as an automatic tool for building generguide > release or for downloading libraries when generguide is used directly > from CVS. I agree with your logic. Lets work toward moving docbook XSLT out of CVS as you suggest. > > I became real user of generguide project. I use it for 2 different kinds > of documentation development. Great. > At work I base on Generguide our internal developers guide with some > modifications - use all features of generguide and for separate document > written in Sdocbook so I use generguide only script and libraries. > > And as a real user I try to change generguide to my needs. I hope > this is correct, if not let me know I will revisit my approach. > > I understand that all important changes should be discussed first but > if I have to do something I have a choice: > 1. to write separate tool for this > or > 2. to extend generguide with lacking feature. Yes, 2) is preferable. > > Below I present what I am going to do in very short future: > 1. Complete support for Java tools Great. > 2. Support for generating PDF files (FOP) Great. > 3. Script downloading and installing in generguide hierarchy > the last releases of all necessary libraries > - docbook xsl > - fop > - sdocbook dtds (they are necessary for complete catalogs support) > 4. Complete support for both cygwin and linux systems. Cool. > > And probably (I am not sure yet if I will be able) > 5. Generguide HOWTO Yes, I think this has moved onto the critical path for the next release. I think Sean mentioned that he was interested in this too. > > Assuming you agree with my changes I have one issue: > Do you prefer to develop Java-tools support in separate > script or include it in existing one? > 1. Separate scripts make them a little bit simpler however forces > us to do some things in two places > 2. One script will become a little bit complex but many actions will > be implemented only in one place. > > I prefer to do one script now and maybe later divide it into > more parts. I prefer two scripts. I see distinct communities growing behind generguide: 1. Users who are prepared to install java. 2. 'nix users who don't like java. 3. Windows users who won't install java. (Tech writers) 4. 'nix/cygwin users. Hence, I think we should consider treating java and shell scripts as seperate sub-projects. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
From: Sean W. <se...@ya...> - 2003-10-03 05:55:49
|
--- Cameron Shorter <ca...@sh...> wrote: > On Friday 03 Oct 2003 6:14 am, Artur Hefczyc wrote: > > > But lets present new features and ideas: > > 1. Started to add support for Java tools. They are > important for > > at least 2 reasons: > > - (S)DocBook XSLT extensions are only > implemented for Java tools > > - PDF generation (FOP -> PDF) is only > implemented in Java tools > > Great. Agreed. > > > > > 2. Some limited support for catalogs for Java > tools > > ok. > > > > > 3. Let me return to keeping docbook XSLT in CVS > repository issue. > > I don't like this idea, however I agree that > we should provide > > complete environment with all necessary > libraries. > > Our needs are not limited to those XSLT > templates but I see also > > some Java jars as usefull, at least SDocBook > DTD (because we use > > it for our guides), fop library to generate > PDFs and probably some > > more. Keeping all libraries in CVS repository > forces us to use outdated > > versions or constant updating our repository with > new releases. This is why I want advocating customization layers for the DTD's and XSL's. > > > > So I propose to not keep external libraries in > our CVS repository at > > all. But on the other hand we should include them > in release of our > > environment. So joining all necessary external > libraries should be part of > > package build process. Excellent. > > Since they are all available on the net, it > seems to me easy to create > > appropriate script downloading, unpacking and > preconfiguring them. > > This script could be used as an automatic tool > for building generguide > > release or for downloading libraries when > generguide is used directly > > from CVS. > > I agree with your logic. Lets work toward moving > docbook XSLT out of CVS as > you suggest. Yes. > > Below I present what I am going to do in very > short future: > > 1. Complete support for Java tools > Great. > > > 2. Support for generating PDF files (FOP) > Great. > > > 3. Script downloading and installing in generguide > hierarchy > > the last releases of all necessary libraries > > - docbook xsl > > - fop > > - sdocbook dtds (they are necessary for > complete catalogs support) > > 4. Complete support for both cygwin and linux > systems. > Cool. > > > > > And probably (I am not sure yet if I will be able) > > 5. Generguide HOWTO > Yes, I think this has moved onto the critical path > for the next release. I > think Sean mentioned that he was interested in this > too. Yes, please send me any ideas and lots of small pieces so I can integrate them into what I am currently doing. > 3. Windows users who won't install java. (Tech > writers) :0( They don't know what they're missing. > Hence, I think we should consider treating java and > shell scripts as seperate > sub-projects. Layering. Excellent. Sean Wheller __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Cameron S. <ca...@sh...> - 2003-10-03 12:09:57
|
On Friday 03 Oct 2003 3:55 pm, Sean Wheller wrote: > > > And probably (I am not sure yet if I will be able) > > > 5. Generguide HOWTO > > > > Yes, I think this has moved onto the critical path > > for the next release. I > > think Sean mentioned that he was interested in this > > too. > > Yes, please send me any ideas and lots of small pieces > so I can integrate them into what I am currently > doing. I look forward to seeing your work. It will help me write additions if I can see what bits are missing. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
From: Artur H. <ko...@pl...> - 2003-10-04 06:47:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I prefer to do one script now and maybe later divide it into > > more parts. > I prefer two scripts. I see distinct communities growing behind > generguide: > 1. Users who are prepared to install java. > 2. 'nix users who don't like java. > 3. Windows users who won't install java. (Tech writers) > 4. 'nix/cygwin users. > Hence, I think we should consider treating java and shell scripts as > seperate sub-projects. I was thinking about simple extension of existing bash script first. Support for Java tools would be visible only if you set command line parameter to use Java tools. By default Java tools weren't be used, visible and no JDK and jars are necessary. I need bash because of it's scripting language features, command line parameters parsing, easy way to manage files, setup target and temporary directories and so on. I also need Java tools for its features like XSLDocBook extensions and target PDF format. So I am not ready yet to create support for all kinds of users. I agree that it is better to have separated code for Java and non-Java tools but I wanted to prevent implementation the same part of script in 2 places (command line parameters parsing, seting up target, temp directories and so on). Than I propose to implement this as follows: 1. Leave current generpublish.sh as a master script parsing command line parameters, seting up whole necessary environment and calling proper tool script. 2. Create 2 tool scripts, one using xmlproc tools, and second used Java tools. By default xmlproc tools will be used but if '-j' parameter is given Java tools will be used and target format PDF will be available. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fmzG0/6x1bjSKPkRAjmCAJ9wF77aO05GMuAKdGZLcCgt9GFNoACgqeo6 aIFfZjbzKDVMd6PKKUSNM+M= =mo7Q -----END PGP SIGNATURE----- |
From: Cameron S. <ca...@sh...> - 2003-10-04 08:06:33
|
On Saturday 04 Oct 2003 4:46 pm, Artur Hefczyc wrote: > Than I propose to implement this as follows: > 1. Leave current generpublish.sh as a master script parsing command line > parameters, seting up whole necessary environment and calling proper > tool script. > 2. Create 2 tool scripts, one using xmlproc tools, and second used Java > tools. > > By default xmlproc tools will be used but if '-j' parameter is given Java > tools will be used and target format PDF will be available. Sounds good to me. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
From: Artur H. <ko...@pl...> - 2003-10-03 21:04:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I prefer to do one script now and maybe later divide it into > > more parts. > I prefer two scripts. I see distinct communities growing behind > generguide: > 1. Users who are prepared to install java. > 2. 'nix users who don't like java. > 3. Windows users who won't install java. (Tech writers) > 4. 'nix/cygwin users. > Hence, I think we should consider treating java and shell scripts as > seperate sub-projects. I was thinking about simple extension of existing bash script first. Support for Java tools would be visible only if you set command line parameter to use Java tools. By default Java tools weren't be used, visible and no JDK and jars are necessary. I need bash because of it's scripting language features, command line parameters parsing, easy way to manage files, setup target and temporary directories and so on. I also need Java tools for its features like XSLDocBook extensions and target PDF format. So I am not ready yet to create support for all kinds of users. I agree that it is better to have separated code for Java and non-Java tools but I wanted to prevent implementation the same part of script in 2 places (command line parameters parsing, seting up target, temp directories and so on). Than I propose to implement this as follows: 1. Leave current generpublish.sh as a master script parsing command line parameters, seting up whole necessary environment and calling proper tool script. 2. Create 2 tool scripts, one using xmlproc tools, and second used Java tools. By default xmlproc tools will be used but if '-j' parameter is given Java tools will be used and target format PDF will be available. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/feQk0/6x1bjSKPkRAmaSAKDPVhMvZiTZ094vtFCZGWlL62JzjQCeJ+RY YkAT+8RojFm6CwnKcx3BW6c= =tNvV -----END PGP SIGNATURE----- |