[jira] Commented: (VELOCITY-413) DVSL doesn't appear to work with Velocity 1.5
[ http://issues.apache.org/jira/browse/VELOCITY-413?page=comments#action_12446871 ] Claude Brisson commented on VELOCITY-413: - Right. And to be more rigorous, we should open another DVSL issue for the dom4j version problem. That's what I'm gonna do right now. We should leave this one open until a commiter put in a velocity-1.5-dev.jar in the /dvsl/lib instead of the previous /lib/velocity-1.3-dev.jar and a new velocity-dvsl jar (it may be quite pertinent to also upgrade the DVSL subversion number). DVSL doesn't appear to work with Velocity 1.5 - Key: VELOCITY-413 URL: http://issues.apache.org/jira/browse/VELOCITY-413 Project: Velocity Issue Type: Bug Components: DVSL, Source Affects Versions: 1.5 Environment: WinXP Pro Reporter: Nathan Bubna Fix For: 1.5 I tried to generate the docs for VelocityTools (which are generated via DVSL) using a recent build of Velocity-1.5-dev, and the files DVSL generated were empty. No error messages were sent to std out and Ant considered the build successful. Also, DVSL only appears to work with older versions of Dom4j (such as 1.1). If used with Dom4j 1.6.1, then NoClassDefFoundErrors pop up. It might be good to upgrade DVSL, if possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-476) Howto have DVSL work with Dom4j 1.6.1
Howto have DVSL work with Dom4j 1.6.1 - Key: VELOCITY-476 URL: http://issues.apache.org/jira/browse/VELOCITY-476 Project: Velocity Issue Type: Bug Components: DVSL Environment: linux Reporter: Claude Brisson To have DVSL work with Dom4j 1.6.1, one need to use an 1-1-beta version of jaxen, for instance http://www.ibiblio.org/maven/jaxen/jars/jaxen-1.1-beta-11.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Right way to use docbook and xdoc support from Velocity in other
Marshall Schor [EMAIL PROTECTED] writes: Hi Marshall, let's see if I got your questions right. First thing is, how to integrate the docbook environment in your project so that you don't duplicate libraries etc. Well, I wouldn't. That is why I started the docbook documentation outside the Velocity engine tree. The libraries included in the docbook tree are there for the one reason of creating the documentation. If you share them with the build path of your application, you will at some point have to update the dependencies of your project and if then your documentation creation process fails, you will have to split up anyway. So in a way, I consider the docbook framework to be a tool in itself just as e.g. LaTeX which you wouldn't copy into your project either if the docs were written in TeX. For Velocity, the documentation in docbook format will probably live in .../docbook/src/docbook/userguide/VelocityUsersGuide.xml .../docbook/src/docbook/devguide/VelocityDevelopersGuide.xml in the docbook repository. For the actual release versions of the Velocity engine, the docs get built _outside_ the engine tree and then copied (probably to .../engine/pdf or .../engine/doc/pdf, no decision about that yet. The xdocs are a different beast because they are likely to change with every release of the engine (or even change with each build; release notes etc.). So the PDFs will just be linked from the xdoc documentation. Second, how do you put your own docs into the docbook framework. I just did a similar thing at a customer project; here is my recipe: - get the tree from .../velocity/docbook - follow the instructions from README.FIRST (get the jai stuff) - now you have to carve out the current velocity documentation (that is in there already): - remove src/docbook/userguide and its contents - remove src/images/* - Let's say you want to start with the docs for your project. Let's say you have two guides, the FooGuide and the BarGuide. - create src/docbook/foo and src/docbook/bar. - If you already have a docbook skeleton for your guides, copy them to src/docbook/foo/FooGuide.xml and src/docbook/bar/BarGuide.xml - Now open the main build.xml file. Look for the all target. - Remove the !-- Build the Users Guide -- ant antfile=build-docbook.xml target=all property name=docbook.dir value=userguide/ property name=docbook.file value=VelocityUsersGuide/ /ant section. Add !-- Build the Foo Guide -- ant antfile=build-docbook.xml target=all property name=docbook.dir value=foo/ property name=docbook.file value=FooGuide/ /ant !-- Build the Bar Guide -- ant antfile=build-docbook.xml target=all property name=docbook.dir value=bar/ property name=docbook.file value=BarGuide/ /ant instead. - Now run ant. The framework should create directories for foo and bar in the target folder, containing the foo and bar guide. Obviously the two guides will use the same kind of styles and formatting, but for common documentation, this might actually be wanted. - Files you want to look into: - src/styles/htmlsingle.xsl - src/styles/html.xsl - src/styles/pdf.xsl for anything that should be ant-filtered (these files can be left alone most of the times) - src/styles/html/custom.xsl - src/styles/pdf/custom.xsl these files are called custom for a reason, mainly because they can and should be customized to your needs. They define e.g. the numbering of chapters and sections, whether you get ToC and/or title pages, borders etc. These files are currently customized for Velocity but you might find that the settings here work for you. If not, they should provide a starting point but then you have to read up on the docbook xsl docs to customize these files further. - src/css/html/stylesheet.css is the stylesheet (referenced from src/styles/html/custom.xsl) used to render the HTML docs. There you might want to change the color of h1,h2,h3,h4,h5, because it is the Velocity greyish-blue used so prominently. :-) My general recommendation would be (mainly because that it how I will try to do it with Velocity, but with a current known user base of one for the docbook framework it is hard to speak of best practice... :-) ) that you simply create a docbook sub-project either inside your project or next to your project (like Velocity). There you keep the docbook files and simply copy rendered versions (HTML or PDF) into your actual project. Best regards Henning I have a general question about reusing the docbook and xdoc support that Velocity nicely provides. One way that works is to copy the docbook (or xdoc) trunk (e.g. jakarta/velocity/docbook/trunk) into my project, and start modifying my copy to be for my documentation. This includes the code, libs, ant build scripts, etc. However, that duplicates in my project the
[jira] Created: (VELTOOLS-68) VelocityViewServlet has hard coded ServletLogger
VelocityViewServlet has hard coded ServletLogger Key: VELTOOLS-68 URL: http://issues.apache.org/jira/browse/VELTOOLS-68 Project: VelocityTools Issue Type: Bug Components: VelocityView Affects Versions: 1.3 Reporter: Henning Schmiedehausen Priority: Minor VelocityViewServlet configures the Velocity engine to use the ServletLogger (~line 323). Integration of the servlet into applications that use other logging systems (e.g. log4j / commons-logging) is very hard because of that. - VVS should honor the logging setttings in velocity.properties (e.g. for explicit jdk logging) - It should add the ServletLogger to the log engine search path and only use it if no other logger was found (log4j / avalon etc.) - The ServletLogger class implements the deprecated LogSystem. VelocityTools should provide a LogChute implementation of the SrevletLogger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=all ] Henning Schmiedehausen updated VELOCITY-24: --- Bugzilla Id: (was: 4483) Affects Version/s: 1.5 beta1 (was: 1.1-rc2) Priority: Blocker (was: Major) Issue is trivially reproducable using ab -c 2 -n 8 http://localhost:8080/testbed/templates/issues/velocity-24.vm There definitely is a race condition somewhere in the Velocity engine that should be fixed for 1.5. Raising prio to blocker for 1.5. calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r470900 - /jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Author: henning
Date: Fri Nov 3 08:52:38 2006
New Revision: 470900
URL: http://svn.apache.org/viewvc?view=revrev=470900
Log:
move iso umlauts - utf-8, silencing the Java 1.5 compiler
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java?view=diffrev=470900r1=470899r2=470900
==
---
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
(original)
+++
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Fri Nov 3 08:52:38 2006
@@ -13,7 +13,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*
- * $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * $Id$
*/
package examples.app4;
@@ -30,8 +30,8 @@
* pA simple tile-controller that puts a string into the request scope.
* Check out the tiles-defs to see the definition that uses the
controller/p
*
- * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
- * @version $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
+ * @version $Id$
*/
public class MyTileController extends ControllerSupport {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Right way to use docbook and xdoc support from Velocity in other
Henning P. Schmiedehausen wrote: Marshall Schor [EMAIL PROTECTED] writes: Hi Marshall, let's see if I got your questions right. First thing is, how to integrate the docbook environment in your project so that you don't duplicate libraries etc. Well, I wouldn't. Hi Henning - You make a good point. Let's assume the particular jars, zip-files of docbook transforms, etc., are not integrated into my project, but rather are kept in the lib/ directory of my special docbook project. Now suppose producing docbooks this way becomes popular with other Apache projects (as xdoc has) and rather than being just 1, there are many projects in Apache using this. Is there a way Apache shares the sharable parts of all these doc books in many projects (for example, the FOP jars, the docbook xsl transforms, etc.) that would be the same for all of these, or is it a better practice to have every one of these projects have their own copy of all of this? If this did exist - I suppose it would consist of some kind of a shared repository of tools found useful in Apache project maintenance, and a way to have the Ant scripts reference such a repository of shared objects (not just JARs, but also other resources like docbook XSL Transforms). That was what my question was trying to get at... Thanks for the rest of your note - I'm on my way converting our documentation to docbook format so we can produce PDFs with all the nice features that make for readable documentation (TOCs, cross refs with page numbers, footnotes, etc.). -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r470900 - /jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
What's up with this? Shouldn't that have been expanded?
+ * $Id$
WILL
On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: henning
Date: Fri Nov 3 08:52:38 2006
New Revision: 470900
URL: http://svn.apache.org/viewvc?view=revrev=470900
Log:
move iso umlauts - utf-8, silencing the Java 1.5 compiler
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java?view=diffrev=470900r1=470899r2=470900
==
---
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
(original)
+++
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Fri Nov 3 08:52:38 2006
@@ -13,7 +13,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*
- * $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * $Id$
*/
package examples.app4;
@@ -30,8 +30,8 @@
* pA simple tile-controller that puts a string into the request scope.
* Check out the tiles-defs to see the definition that uses the
controller/p
*
- * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
- * @version $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
+ * @version $Id$
*/
public class MyTileController extends ControllerSupport {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=comments#action_12447018 ] Henning Schmiedehausen commented on VELOCITY-24: hmmm. it seems that the whole getTemplate() path is not really threadsafe with respect to local macros. The culprit lies in the dumpNamespace() methods. Will investigate further... calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-68) VelocityViewServlet has hard coded ServletLogger
[ http://issues.apache.org/jira/browse/VELTOOLS-68?page=comments#action_12447009 ] Nathan Bubna commented on VELTOOLS-68: -- Integration w/commons-logging used to be trivial until Tomcat decided to use c-l as a full logging provider instead of a wrapper. :( Adding the ServletLogger to the search path sounds good, however, there is the question of where in the priority it should be. i don't necessarily think it should be the last option. i do have LogChute implementations for VelocityTools on the wiki (http://wiki.apache.org/jakarta-velocity/VelocityTools), but i've held off adding them to Veltools 1.3-dev because i want to be free to release 1.3 before Velocity 1.5 comes out. If we get Vel 1.5 out before i roll Veltools 1.3, then i'll add the LogChutes in. VelocityViewServlet has hard coded ServletLogger Key: VELTOOLS-68 URL: http://issues.apache.org/jira/browse/VELTOOLS-68 Project: VelocityTools Issue Type: Bug Components: VelocityView Affects Versions: 1.3 Reporter: Henning Schmiedehausen Priority: Minor VelocityViewServlet configures the Velocity engine to use the ServletLogger (~line 323). Integration of the servlet into applications that use other logging systems (e.g. log4j / commons-logging) is very hard because of that. - VVS should honor the logging setttings in velocity.properties (e.g. for explicit jdk logging) - It should add the ServletLogger to the log engine search path and only use it if no other logger was found (log4j / avalon etc.) - The ServletLogger class implements the deprecated LogSystem. VelocityTools should provide a LogChute implementation of the SrevletLogger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Right way to use docbook and xdoc support from Velocity in other
Marshall Schor [EMAIL PROTECTED] writes: Hi, hm. It should be possible to do some ant magic to have a docbook generation environment that can be shared all over projects and is static (containing libs, transformer zip's etc.) and just have the src tree outside it. However that would in its current state require the user to download two trees (one with the environment, one with the actual docbook sources), probably set an environment variable or property to find the tree and then convert it. Will think about this some more. Might even be easily doable. Best regards Henning Henning P. Schmiedehausen wrote: Marshall Schor [EMAIL PROTECTED] writes: Hi Marshall, let's see if I got your questions right. First thing is, how to integrate the docbook environment in your project so that you don't duplicate libraries etc. Well, I wouldn't. Hi Henning - You make a good point. Let's assume the particular jars, zip-files of docbook transforms, etc., are not integrated into my project, but rather are kept in the lib/ directory of my special docbook project. Now suppose producing docbooks this way becomes popular with other Apache projects (as xdoc has) and rather than being just 1, there are many projects in Apache using this. Is there a way Apache shares the sharable parts of all these doc books in many projects (for example, the FOP jars, the docbook xsl transforms, etc.) that would be the same for all of these, or is it a better practice to have every one of these projects have their own copy of all of this? If this did exist - I suppose it would consist of some kind of a shared repository of tools found useful in Apache project maintenance, and a way to have the Ant scripts reference such a repository of shared objects (not just JARs, but also other resources like docbook XSL Transforms). That was what my question was trying to get at... Thanks for the rest of your note - I'm on my way converting our documentation to docbook format so we can produce PDFs with all the nice features that make for readable documentation (TOCs, cross refs with page numbers, footnotes, etc.). -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r470900 - /jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Will Glass-Husain [EMAIL PROTECTED] writes:
What's up with this? Shouldn't that have been expanded?
+ * $Id$
Nope. Subversion only expands when checking out, keeping the only
revision has changed diff nightmares of CVS away. :-)
If you check the file out, your local copy has an Id.
That file probably has never been touched before since the CVS - SVN
conversion. This was actually the old CVS id version in the
repository.
Best regards
Henning
WILL
On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: henning
Date: Fri Nov 3 08:52:38 2006
New Revision: 470900
URL: http://svn.apache.org/viewvc?view=revrev=470900
Log:
move iso umlauts - utf-8, silencing the Java 1.5 compiler
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java?view=diffrev=470900r1=470899r2=470900
==
---
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
(original)
+++
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Fri Nov 3 08:52:38 2006
@@ -13,7 +13,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*
- * $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * $Id$
*/
package examples.app4;
@@ -30,8 +30,8 @@
* pA simple tile-controller that puts a string into the request scope.
* Check out the tiles-defs to see the definition that uses the
controller/p
*
- * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
- * @version $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp
$
+ * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
+ * @version $Id$
*/
public class MyTileController extends ControllerSupport {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
