Re: Karma request for commons-exec
On Mon, 2005-09-19 at 16:16 +0200, Trygve Laugstøl wrote: Hi I want to start working on getting commons-exec used inside Apache Maven Continuum and would like to review and commit the outstanding patches before starting on some more heavier work. More on the details in another mail. As far is I've understood it I can request this karma because it's only in the sandbox and I was listed as a possible committer in the project proposal. For the reference I'm already a Apache committer on the Maven projects, my Apache id is 'trygvis'. +1 -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On Tue, 2005-08-02 at 16:18 +0200, Niklas Gustavsson wrote: Tomasz Pik wrote: * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. The folks developing Continuum would certainly like to help work on something that is usable in a server environment. We use some command line utilities to call various build tools and we'd love to be able to use the tool developed here instead of maintaining our own (which we borrowed from CruiseControl -- some other people that might want to help contribute to this cause). Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven dependencies (jakarta-commons/configuration build.xml)
On Tue, 2004-02-10 at 09:26, Mark R. Diggory wrote: To clarify one point, we do have our own repository for apache projects which Jason and I worked to setup at this time, we really need to get some documentation on it out there ;-) minotaur.apache.org:/www/www.apache.org/dist/java-repository http://www.apache.org/dist/java-repository However, it is specifically just for the snapshot and release builds of apache projects and not for external dependencies (it is mirrored into the ibiblio.org/maven repository from apache). I suspect a discussion about exposing external dependencies would not be popular and it probably would be concluded that ibiblio is the best place for such dependencies. It should also become standard practice for projects to request their artifacts be place on ibiblio so it will become a matter of asking a project to get involved with the automated upload stuff, once it gets going, in order to get their artifacts to ibiblio. It hasn't been possibly thus far for practical reasons but hopefully soon any project will easily be able to get authoritative verions of their artifacts into ibiblio. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Repository Location
On Sun, 2004-01-18 at 15:04, Henk P. Penning wrote: On 17 Jan 2004, Jason van Zyl wrote: Date: 17 Jan 2004 01:02:27 -0500 From: Jason van Zyl [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Apache Infrastructure [EMAIL PROTECTED] Subject: Re: Apache Maven Repository Location To the best of my knowledge I have place a copy of the Apache projects that were on ibiblio into the maven repository now at Apache: http://www.apache.org/dist/java-repository/ Please take a look, if I missed anything I will grab it from ibiblio, if there are things in there that don't belong please nuke them. As things stand now the apache dist will get sync'd once a day, if you want the maven stuff sync'd more frequently and I will get it pulled more often. Anyway, many thanks to start. I was just waiting for an avid user to step up and push it through. If there's anything else I can do let me know. Please take a look at http://www.apache.org/~henkp/md5/ Where's the nifty script that outputs that? The java-repository contains -- 2 dead symlinks -- 5 cases where the computed md5 is inconsistent with de .md5 file Cool, will fix. I have scripts to regenerate all the md5 files but is there something you would rather me use? -- numerous doubles: the repository contains a lot of stuff that is already somewhere else in 'dist/'. I'll let you guys hash that one out. Projects using Maven only really need the java-repository, or the script I provided could be modified to make the appropriate symlinks. What you guys want, no skin off my back. Jason van Zyl HPP Henk P. Penning, Dept of Computer Science, Utrecht University \__/ \ Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. \__/ Telephone: +31-30-2534106, fax: +31-30-2513791 / \__/ \__/ \__/ \ http://www.cs.uu.nl/staff/henkp.html \__/ \__/ \__/ \__/ -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Repository Location
On Sat, 2004-01-17 at 23:37, Mark R. Diggory wrote:
Yep, I should have announced that. I came to a similar conclusion.
Eventually I think we should start using the artifact plugin because
it automatically generates md5 checksums. The properties are slightly
different for that, but similar.
http://maven.apache.org/reference/plugins/artifact/examples.html
I think we should still change this as a precaution, although I'm not
100% on what it does given that the properties need to be set to get
deployment going elsewhere.
Do not use the artifact plugin, it's immature. Use the repository
plugin. I'm just making sure that's clear :-)
Mark
Tim O'Brien wrote:
Mark R. Diggory wrote:
I think one of the next steps is to get the global Commons project.xml
configured so deployments like jar:deploy got to the right location.
distributionDirectory/www/www.apache.org/dist/java-repository/${pom.artifactId}//distributionDirectory
Mark, I tried that but had no success. Instead, if you put these three
lines in your project.properties file (for each component)
maven.repo.central=www.apache.org
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
maven.remote.group=apcvs
You should eb able to run a jar:deploy.
Tim
Jason van Zyl wrote:
On Sat, 2004-01-17 at 17:21, Mark R. Diggory wrote:
Jason van Zyl and I just worked out some details for distributing a
Apache specific maven repository to ibiblio.
To the best of my knowledge I have place a copy of the Apache projects
that were on ibiblio into the maven repository now at Apache:
http://www.apache.org/dist/java-repository/
Please take a look, if I missed anything I will grab it from ibiblio, if
there are things in there that don't belong please nuke them.
As things stand now the apache dist will get sync'd once a day, if you
want the maven stuff sync'd more frequently and I will get it pulled
more often.
Anyway, many thanks to start. I was just waiting for an avid user to
step up and push it through. If there's anything else I can do let me
know.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Repository Location
On Sat, 2004-01-17 at 22:43, Tim O'Brien wrote:
Mark R. Diggory wrote:
I think one of the next steps is to get the global Commons project.xml
configured so deployments like jar:deploy got to the right location.
distributionDirectory/www/www.apache.org/dist/java-repository/${pom.artifactId}//distributionDirectory
Mark, I tried that but had no success. Instead, if you put these three
lines in your project.properties file (for each component)
maven.repo.central=www.apache.org
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
maven.remote.group=apcvs
You should eb able to run a jar:deploy.
All sounds good, but you should take a peek at the repository plugin.
That's what most of the ibiblio admins use to push stuff up to ibiblio
so no reason you guys can't use it too.
Tim
Jason van Zyl wrote:
On Sat, 2004-01-17 at 17:21, Mark R. Diggory wrote:
Jason van Zyl and I just worked out some details for distributing a
Apache specific maven repository to ibiblio.
To the best of my knowledge I have place a copy of the Apache projects
that were on ibiblio into the maven repository now at Apache:
http://www.apache.org/dist/java-repository/
Please take a look, if I missed anything I will grab it from ibiblio, if
there are things in there that don't belong please nuke them.
As things stand now the apache dist will get sync'd once a day, if you
want the maven stuff sync'd more frequently and I will get it pulled
more often.
Anyway, many thanks to start. I was just waiting for an avid user to
step up and push it through. If there's anything else I can do let me
know.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] snapshot distros now available
On Sat, 2004-01-17 at 20:05, Mark R. Diggory wrote: http://www.apache.org/dist/java-repository/commons-math/ I generated the md5 checksums by hand. I've been talking with the Maven folks about the artifact plugin. I think I'll need to write a maven.xml file to support the goals needed to use the artifact tags. The repository plugin will deal with generating the md5 checksums for you. Dion, you want to give him some pointers? I always use my scripts. -Mark -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Repository Location
On Sat, 2004-01-17 at 17:21, Mark R. Diggory wrote: Jason van Zyl and I just worked out some details for distributing a Apache specific maven repository to ibiblio. To the best of my knowledge I have place a copy of the Apache projects that were on ibiblio into the maven repository now at Apache: http://www.apache.org/dist/java-repository/ Please take a look, if I missed anything I will grab it from ibiblio, if there are things in there that don't belong please nuke them. As things stand now the apache dist will get sync'd once a day, if you want the maven stuff sync'd more frequently and I will get it pulled more often. Anyway, many thanks to start. I was just waiting for an avid user to step up and push it through. If there's anything else I can do let me know. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] developer repository?
On Sat, 2003-12-20 at 19:01, Greg Stein wrote: I'd also like to point out the Board has specifically requested that the Apache Maven Project should distribute jars from ASF hardware. We make certain guarantees to our users, and those guarantees require distributing ASF code from known, secure hardware (the ASF itself). Thus, a jar repository will be created at the ASF, and ibiblio will mirror from that (and probably add some additional jars which won't ever be distributed by the ASF for various reasons). The repository will fit into our mirror framework, and there will be automatic mechanisms for ASF software releases to automatically flow into that repository (e.g. the point about releases taking (sometimes) months to appear at ibilio will not occur). If some wants to make a maven-like directory within the standard distribution location on ASF hardware right now they can. That could be a first, very practical step the repo project could make. Then let projects put their artifacts in there as they wish. Please sign up at [EMAIL PROTECTED] to participate. Cheers, -g On Sat, Dec 20, 2003 at 05:04:04PM -0600, Tim O'Brien wrote: I be a little clearer here. Do not redistribute anything from ASF hardware that is covered on a license that is incompatible with the Apache License. If you are unsure as to what that means, I'd suggest joining the licensing list and asking. I'd suggest using your own resources for something like this. Keep in mind that ASF pays for bandwidth, and that we have a series of mirrors to reduce our overall bandwidth. Tim __matthewHawthorne wrote: As Noel pointed out, there's a repo project starting up elsewhere. In the meantime, though, please be *very* careful about what you make available in your public_html directory. Specifically, you need to ensure that the licenses for all of those components permit redistribution, since that is effectively what you are doing. Will do. I'm not using anything for which there isn't already an older version on ibiblio -- so I think I'm ok. But I'll be sure to double check. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] developer repository?
On Sat, 2003-12-20 at 20:49, __matthewHawthorne wrote: Jason van Zyl wrote: If some wants to make a maven-like directory within the standard distribution location on ASF hardware right now they can. That could be a first, very practical step the repo project could make. Then let projects put their artifacts in there as they wish. This is what I was suggesting. I figured that others had the same problem that I did, and would be willing to create a space together to hold newer versions than what is currently on ibiblio. Maybe a dirctory in /www/maven.apache.org/repo or something like that. The [EMAIL PROTECTED] project looks great, and I would imagine that this is what Maven will be using in the future (right?). All depends on what works for Maven users. If you as a Maven user like what they have to offer then we will use it. However, I'm looking for a solution which will work with Maven right now. Yup, a simple directory structure would do it. You just have to tell infrastructure that as a maven user and an apache committer you would like to see a directory structure for placing artifacts for use with Maven and see what they say. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jrcs/diff status
On Thu, 2003-12-04 at 18:54, Geoff Howard wrote: I just discovered the jrcs project in a renewed search for a diff algorithm implementation compatible with the ASF license. I searched the archives for an indication if this is a living project or not and read the trail from september following the proposal to remove it from Commons/Jakarta and thought I perceived at least a lazy consensus to increase the project visibility instead of scrubbing it. I saw some cvs activity after that, and a post on users which seemed to confirm that direction. But now I see that jrcs is gone from the Commons navigation, apparently removed in this commit with no further explanation: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107020830121776w=2 Was this a mistake which went unnoticed or did something happen off list? I'm interested particularly in the diff portion of the project and have written a quick first stab at an Ant task based on it because I need it for work. I'd like to see about contributing it, some utility code to make usage simpler, and possibly developing some supporting code for Cocoon (where I'm active) such as a generator which creates an xml representation of a diff between files, etc. The rcs code could prove useful elsewhere in the Cocoon project which has struggled trying to provide some cvs support without a cvs project which isn't GPL'd. The code being maintained by the primary author now lives here: http://cvs.codehaus.org/viewcvs.cgi/jrcs/?root=codehaus TIA, Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Move JRCS out of Jakarta
On Fri, 2003-09-26 at 01:34, Juancarlo Añez wrote: There are some interesting legalities. When we donate code to Apache, we obviously are giving ownership of that code over to the ASF. The original author also retains copyright. And given that no one else has contributed to the project Juan is basically the only committer, in addition the project is in the sandbox. It is really only a problem if the ASF were going to pursue anything and is it really for a project in the sandbox with a single author who wishes to leave and keep the name of his project. Probably not. Not a biggy under a BSD-like licence as we can just fork it. However, we're also giving over the copyright on the name, so possibly ASF own 'JRCS' as a name. If you decide to migrate away, we might just have to do a bit of quick figuring out of an exit strategy for code that is effectively under 'incubation'. Hen, I hadn't thought about that. Thanks for the insight. In all honesty, I think that the name JRCS was always a bad choice, so I don't expect the name of the project to be an issue. Juanca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [graph] is the projec alive?
On Wed, 2003-09-17 at 16:50, robert burrell donkin wrote: henri's right but there's one corollary i'd like to add: in order to gain promotion to the commons proper, graph needs an apache committer to champion it. maven seems like the best place to find one. I was talking to David Dixon-Peugh and what might happen is we just pick up the code and move it to codehaus. - robert On Wednesday, September 17, 2003, at 02:10 PM, Henri Yandell wrote: People to talk to look like jvanzyl, dion and mvdb. I think they all listen here, but the Maven list might be better monitored. There's no PROPOSAL.html or STATUS.html in there, so it's not got the necessary requirements for a promotion to Commons proper to be considered. Hen On Wed, 17 Sep 2003, Tomasz Pik wrote: Commons developers, There's a 'graph2' module in sandbox CVS containing implementation of 'graph' structure. I'd like to ask about status of this project. CVS looks like untouched for about a year. This package is not released (because it's in sandbox). On the other side Maven depends on this. So - are there any plans for promoting this to 'commons' and release? Thanks Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jelly] inconsistency in boolean handling
Howdy,
I have a variable in the context that is a String and has a value of
true. Using j:if/ and j:when/ yield different results.
If ${value} is set to true :
j:if test=${value} evaluates to false and the body doesn't run.
while
j:when test=${value} evaluates to true and the body runs.
Before each of these blocks I am echoing the value of ${value} and it
appears to be true. From the source they they look like they are
evaluated the same yet I am getting different results?
Anyone know of any oddities with boolean evaluation?
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] inconsistency in boolean handling
On Sun, 2003-06-29 at 16:41, Jason van Zyl wrote:
Howdy,
I have a variable in the context that is a String and has a value of
true. Using j:if/ and j:when/ yield different results.
If ${value} is set to true :
j:if test=${value} evaluates to false and the body doesn't run.
while
j:when test=${value} evaluates to true and the body runs.
Before each of these blocks I am echoing the value of ${value} and it
appears to be true. From the source they they look like they are
evaluated the same yet I am getting different results?
Anyone know of any oddities with boolean evaluation?
This is part of another more subtle error, in my j:if/ evaluation the
body is indeed run but the body is an ant task where a NPE occurs and it
seems to get completely eaten and everything continues. So it looks like
it doesn't evaluate but does. I'll dig deeper.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [committer] Peter Royal commons committer (specificallyjelly)
On Thu, 2003-06-19 at 11:28, Tim O'Brien wrote: I'm not an active committer to commons-jelly, but I trust Bob's recommendation, and it is true that Jelly needs a champion. +1 +1 Tim On Thu, 19 Jun 2003, bob mcwhirter wrote: I'd like to recommend Peter Royal (proayl) as a commons committer. He's a core developer in Avalon land, and I've worked with on the jaxen (non-jakarta) project. Jelly needs a champion, so if Peter has patches, I'd pick path the produce privs, please. +1. -bob On Thu, 19 Jun 2003, Tim O'Brien wrote: Bob, I don't mean to be obstructionist, but to do this right, I'd recommend... ..Renaming the thread to [VOTE] [committer] Peter Royal commons committer. This is a commons-wide vote, many people filter on particular projects and might miss the vote. Tim On Wed, 18 Jun 2003, bob mcwhirter wrote: On Wed, 18 Jun 2003, Peter Royal wrote: I know there are users, but it anyone maintaining it? Anyone interested in applying outstanding patches and pushing for a release? I'm willing to help, I just have no commit rights :) I'm a committer, but not actively active. Post patches here, and I'll apply. Meanwhile, I'd like to propose giving proyal commits to commons-jelly. here's my +1. -bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bob McWhirter[EMAIL PROTECTED] The Werken Company http://werken.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] What resources must be present for compiling?
On Thu, 2003-06-19 at 11:43, Jason van Zyl wrote: On Thu, 2003-06-19 at 11:17, Peter Royal wrote: On Thursday, June 19, 2003, at 11:10 AM, Jason van Zyl wrote: If you are compiling a bit of Jelly to a Script what resources must be present to simply compile. This bit of Jelly may have various references to classes that must be loaded and my question is must these resources be present for the compile and if so which ClassLoader is used? Or will the resources be searched for only when Script is run against a JellyContext? How/where are those references to classes? In my case they may be jelly beans or taskdef references. In the XMLParser classloading does only appear to be used to resolve taglib references but I just wanted to make sure. Bob also just pinged me and said that if a particular taglib can't be found then a StaticTag will be created and when the Script is run the taglib will be looked for again. So theoretically I don't need anything to compile to Script form which is good news for me. It is my understanding that to compile into a Script, the engine just needs to be able to resolve all of the tags. So if your references are only used when tags are evaluated, they shouldn't be needed at script compilation time.. That's what I'm hoping. -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] moving commons-sql, commons-dbcp and commons-dbutils todb.apache.org
On Thu, 2003-02-13 at 11:02, Martin Poeschl wrote: I would like to move the following packages to db.apache.org o commons-sql o commons-dbcp o commons-dbutils +1 should we move them to db-commons or should they become db subprojects?? we can use irc.werken.com#db to discuss martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Graph2] nsUML license problem
On Wed, 2003-02-05 at 12:32, Morgan Delagrange wrote: Hey all, If you follow the community list, it sounds like the board is coming down on libraries that distribute or link to LGPL software. Unfortunately, graph2 is one of those libraries, by way of the nsUML license: http://nsuml.sourceforge.net The choices seem to be: 1) Convince nsUML to redistribute under a new license 2) Remove nsUML from graph Does anyone want to volunteer for the first option? If not, we're stuck with option number two. Or I'll just move it to werken.com. This is just ridiculous. We can't make everyone on the face of planet switch licenses over night. I _hate_ _hate_ _hate_ GPL licenses but no one has time to try to convert everyone, and some won't, so what do we do? Negate a whole universe of software already written. It's just so stupid. - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Graph2] nsUML license problem
On Wed, 2003-02-05 at 14:11, David Dixon-Peugh wrote: The nsUML stuff isn't central to the Graph package. Indeed it might be better off if it isn't included in the Jars. I can see taking some of the domain packages and distributing them separately. (Its doubtful that many people need to convert statecharts from UML into Graphs for manipulation.) These are the kinds of things that shouldn't be necessary though. It's in there because it was serving a purpose and needs to be removed because of bureaucratic nonsense. It just doesn't sit well. DDP --- Jason van Zyl [EMAIL PROTECTED] wrote: On Wed, 2003-02-05 at 12:32, Morgan Delagrange wrote: Hey all, If you follow the community list, it sounds like the board is coming down on libraries that distribute or link to LGPL software. Unfortunately, graph2 is one of those libraries, by way of the nsUML license: http://nsuml.sourceforge.net The choices seem to be: 1) Convince nsUML to redistribute under a new license 2) Remove nsUML from graph Does anyone want to volunteer for the first option? If not, we're stuck with option number two. Or I'll just move it to werken.com. This is just ridiculous. We can't make everyone on the face of planet switch licenses over night. I _hate_ _hate_ _hate_ GPL licenses but no one has time to try to convert everyone, and some won't, so what do we do? Negate a whole universe of software already written. It's just so stupid. - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sql] Re: Transition of commons-sql to db.apache.org
On Tue, 2003-02-04 at 05:43, James Strachan wrote: +1 There's still a few patches that need to be applied to commons-sql from Tim and John. Should we apply those before the move? Sure, no rush. Everything is setup for new projects. It takes about 5 seconds to get new project info on the main page because you don't have to do anything. Just run the reactor and presto, the new project information is harvested from the project's POM and shows up on the main db.apache.org pages. James --- http://radio.weblogs.com/0112098/ - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:58 PM Subject: Transition of commons-sql to db.apache.org Hi, If anyone wants to add anything to commons-sql then do so now. I'm going to copy the repo over to db.apache.org and rename the one in the jakarta-commons. Also, if the committers of dbutils and dbcp are interested in moving their stuff over to db.apache.org I will help with that also. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving commons-sql to db.apache.org
Hi, This pertains to primarily to James and Daniel but I would like to move the commons-sql package over to db.apache.org. I'm in the process of moving OJB and Torque over there so this is the next set of code I want to move. Any objections? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transition of commons-sql to db.apache.org
Hi, If anyone wants to add anything to commons-sql then do so now. I'm going to copy the repo over to db.apache.org and rename the one in the jakarta-commons. Also, if the committers of dbutils and dbcp are interested in moving their stuff over to db.apache.org I will help with that also. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where did StreamUtils go in commons-io?
-- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where did StreamUtils go in commons-io?
On Sun, 2003-02-02 at 19:17, Jason van Zyl wrote: Found them, sorry about the noise. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sql] [PATCH] on-the-fly schema updates to existing db
On Tue, 2003-01-21 at 14:31, John wrote: I have completed major changes to the sql sandbox project. The changes add the capability to generate ddl to alter an existing database to match the current desired schema. The ant tasks were enhanced to support this as well as executing the ddl against a database connection. I have included a new test case that tests creation of a table and subsequent alterations. The test passes against mySQL, and all existing tests still work. I do not have other databases to test against. I hope this spurs interest in the project and keeps it alive. Oh, I think things are just fine :-) I'll take a look at your changes and try to integrate them this weekend if no one else gets to them. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Jelly] BCEL Taglibrary Beginnings
On Sun, 2003-01-19 at 18:06, Mark R. Diggory wrote:
I started writting the beginnings of a BCEL taglibrary. Although it may
be a bit different than others may anticipate.
Basically I've built two tags and a supporting BeanExtender class to
support them.
bcel:extends
baseClass=java.lang.Object
packageName=org.foo
className=Test
bcel:add-property name=bar propertyType=int write=false/
bcel:add-property name=bam propertyType=java.lang.String/
/bcel:extends
Basically creates a new Class (org.foo.Test) that has:
package org.foo;
public Test extends java.lang.Object {
private int bar;
private String bam;
public Test(){}
public int getBar(){
return bar;
}
public String getBam(){
return bam;
}
public void setBam(String bam){
this.bam = bam;
}
}
It then changes the Security access on the ClassLoader define
method. Allowing the class to be added into the current loader. Once the
class is available it can then be instantiated by useBean or new.
I'm sure there are some more flexible ways to design the Taglibrary, I
consider this to be a first blush over the idea. I'd be glad to donate
the code if others are interested in developing it too.
+1
I think that's nifty neato! What I'm really interested in is the Java
code backing the Jelly. I've always wanted to make a simple API for BCEL
for creating bytecode and it looks like you've got a awesome start to
one.
-Mark Diggory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] reactor building with maven tags-build
On Sat, 2003-01-18 at 01:20, [EMAIL PROTECTED] wrote: I'm +1 on all of the parent's dependencies. After thinking about it for a while I think this is the best way as the behaviour can be well defined and I think all cases can be satisfied. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Jason van Zyl [EMAIL PROTECTED] wrote on 18/01/2003 04:38:51 PM: On Fri, 2003-01-17 at 09:45, James Strachan wrote: From: [EMAIL PROTECTED] Before I forget I've been able to get the maven reactor going if I remove the use of the commonDeps; entity. I've not found a way around this other than to copy the file into another location, which is not a great answer. We can either 'fix' this issue by changing the maven reactor, or stop using the commonDeps, or ?. Personally I like the commonDeps. Any suggestions? Maybe we'd best add a 'dependency reuse' feature to Maven? It would be easy to do now. You tell me how you would like it to work and we'll go from there. All of the parent's dependencies? A labelled subset of the dependencies? Multiple labelled subsets? It easy to add things like this now. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ForwardSourceID:NT000A4E8A -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] reactor building with maven tags-build
On Fri, 2003-01-17 at 09:45, James Strachan wrote: From: [EMAIL PROTECTED] Before I forget I've been able to get the maven reactor going if I remove the use of the commonDeps; entity. I've not found a way around this other than to copy the file into another location, which is not a great answer. We can either 'fix' this issue by changing the maven reactor, or stop using the commonDeps, or ?. Personally I like the commonDeps. Any suggestions? Maybe we'd best add a 'dependency reuse' feature to Maven? It would be easy to do now. You tell me how you would like it to work and we'll go from there. All of the parent's dependencies? A labelled subset of the dependencies? Multiple labelled subsets? It easy to add things like this now. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] moved werkz tags
On Tue, 2002-12-31 at 06:36, James Strachan wrote: From: Jason van Zyl [EMAIL PROTECTED] Hi, I moved the Werkz jelly tags of out of jelly proper and into the Werkz repository. I also changed a couple of others things like test resource copying and the project.xml file to update the version of Werkz being used. I just did a massive refactoring of Maven so the test build works for me and I've asked Dion to try the jelly build to try and find any problems before anyone else does. This sounds like a good idea. One problem this causes is that the Jeez tag library (terrible name, probably calling it the Maven tag library or Maven core tag library would be better) which is a combination of Werkz + Ant + a couple more tags). Its probably worth moving this Jeez tag library into either Werkz or Maven; the latter probably makes most sense then any other Maven specific tags could be put into this single tag library that is then bound to the default XML namespace. So how about we move this Jeez library into Maven? I have copies of them there which I'm now using. I just wasn't sure what you had planned vis-a-vis general ant usage. If it's cool with you I think moving them into Maven would make the most sense. I just didn't want to break your ant tests which seemed to use Jeez. I would also not be averse to moving the ant tag lib to maven either. I think I'm close to being able run build.xml files directly now and having all the tags in maven would probably help with this. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/ant/tagsuite.jelly
On Tue, 2002-12-31 at 11:14, [EMAIL PROTECTED] wrote: jstrachan2002/12/31 08:14:46 Modified:jelly/src/test/org/apache/commons/jelly/jsl suite.jelly jelly/src/test/org/apache/commons/jelly/ant suite.jelly jelly/src/test/org/apache/commons/jelly/ant/tag suite.jelly Log: patched the test cases to use the Ant tag library rather than the old Jeez library thats moving to Maven Cool, I'll check Maven as I think I detached from Jeez in Jelly but I'll clear it out after I check. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] moved werkz tags
On Tue, 2002-12-31 at 11:16, James Strachan wrote: I think I'd like to keep the Ant tag library inside the Jelly distro as its very useful to be able to use Ant tasks inside of Jelly. It also means Jelly based testing frameworks like Latka or Ant based frameworks that use Jelly like Anteater can make use of Ant tasks without being dependent on Maven. Who knows, maybe one day Ant itself could use Jelly to script its tasks too. Yes, it would be nice if all that great utility code was taken out of Ant and put in the commons and use a dynabean adapter to turn the utility bean into a task for use in Ant. I think that is the most fundametnal design error and drawback to Ant is that everything that is basically really just a bean is bound Task and the very problematic AntClassLoader. If the utility code was taken out of Ant I imagine you could get an compatible mechanism up and running in a couple months. That would be a huge unification and allow access to all the utility code in Ant which is very annoying to use outside of Ant currently. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[jelly] moved werkz tags
Hi, I moved the Werkz jelly tags of out of jelly proper and into the Werkz repository. I also changed a couple of others things like test resource copying and the project.xml file to update the version of Werkz being used. I just did a massive refactoring of Maven so the test build works for me and I've asked Dion to try the jelly build to try and find any problems before anyone else does. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Fri, 2002-12-06 at 09:13, James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [x] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Promote FileUpload from Commons Sandbox to CommonsPrope r
On Wed, 2002-10-23 at 01:51, Martin Cooper wrote: The FileUpload component in the Commons Sandbox provides a simple means of integrating HTTP file upload requests (i.e. requests which conform to RFC 1867) into a servlet or web application. The original code for the FileUpload component came from Turbine. The current Commons FileUpload component is in use within both Struts and Turbine, in addition to some external applications. The code base has been stable for some time. This vote is to promote the FileUpload component from the Commons Sandbox to Commons Proper, with the initial developers as listed in the STATUS.html file. An official release of the FileUpload component is anticipated in the near future, but that is *not* the subject of this vote. - 8 - Vote to promote the FileUpload component from Commons Sandbox to Commons Proper: [x] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: - 8 - Here's my +1. -- Martin Cooper -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [VOTE] CLI 1.0 Release
On Wed, 2002-10-23 at 16:22, John Keyes wrote: When: Saturday, November 2nd, 2002 Release Manager: John Keyes Repository Code Freeze: Thursday, October 31st, 2002 CVS Tag: CLI_1_0 [X] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: -John K - - - - - - - - - - - - - - - - - - - - - - - Jakarta Commons CLI http://jakarta.apache.org/commons/cli -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [sql] Refactor JDBCTransformTast?
On Mon, 2002-10-21 at 09:30, [EMAIL PROTECTED] wrote: I noticed that Steven Caswell commited some changes for commons-sql. Is this the code that JVZ was referring to? No. The code I received from J. Russell Smyth. I was taking a peek this morning and noticed what Steven had done and that work touches a lot of files that Russel worked on. James and I usually shoot messages back and forth when changing things and Russell asked a few questions before sending me his patches. Steven just duplicated what Russell has done. It looks like that plan is to take the JDBCTransformTask and use the MetadataReader to get all the meta data, which then is output in the format that commons-sql wants. So, I could start taking the MetadataReader and also leverage it to pull out the metadata and output it in the format that I need as well. Maybe this is a question for Steven, but are you still working on MetadataReader, or should I take a crack at adding in the Forign Key support etc..? I don't want to mess around if you have this code already thought out/in progress... Thanks, Eric Pugh -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [Proposal] Scamp: Source Control Abstraction
On Tue, 2002-09-17 at 13:53, Weber, Lance wrote: Following some interesting discussions on the Maven list, I'd like to propose starting an SCM abstraction project, tentatively named Scamp. Proposed Goal: Scamp is a Source Control Manager abstraction layer. It provides a standard interface to SCM systems allowing common source control operations such as checkin/checkout, labelling/tagging, reading changelogs and diffs. Initial design goals: -- expose a stable SCM interface contract for consuming applications (Maven, Ant, etc). -- provide extensible infrastructure for specific SCM implementations. -- configuration driven implementations -- file system independent -- supports multiple projects, multiple/distributed source providers Architecture: My initial thoughts are to utilize a combination of AbstractSCMFactory and a SourceControlManager interface with concrete implementations of both. We might possible need some secondary classes representing projects, connections, and filesystems, but I'm not sure on those yet. 0.1 Release Goals/Requirements: -- First version of SCM Interface, focused on primary/core SCM operations -- AbstractSCMFactory -- Stubbed concrete factories for cvs/vss/vfs? -- exception infrastructure Any thoughts, feedback, requirements, design, existing code pointers, etc very welcome. Potential participants more than welcome!! I think this would be great. There's code lying around all over the place and it would be nice to collect it together in one place. +1 I know several people using Maven have been wanting to use various SCMs and I'm sure Ant could use this code too. Maybe we could put out a call for any SCM related code people have lying around (JCVS would be great to get a hold of), pile it all in the sandbox and start sorting it out. Maybe the CruiseControl folks would like to donate what they have. Thanks, Lance Lance Weber Chief Architect CareEnhance Services Systems McKesson Health Solutions ___ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: I need karma
On Wed, 2002-06-12 at 18:16, Jon Scott Stevens wrote: I need karma for the betwixt project now that it has moved over to commons from sandbox. Thanks, Done. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: I need karma
On Wed, 2002-06-12 at 19:10, Michael A. Smith wrote: While you're granting karma, can you give me karma to the sandbox? I've wanted to apply people's patches to sandbox code and I've had a few myself, so I asked once before but it never happened. Done. thanks, michael On 12 Jun 2002, Jason van Zyl wrote: On Wed, 2002-06-12 at 18:19, bob mcwhirter wrote: Crap. Likewise, I probably need commons karma for CLI since it exited the sandbox. Done. -bob On Wed, 12 Jun 2002, Jon Scott Stevens wrote: I need karma for the betwixt project now that it has moved over to commons from sandbox. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Sean Sullivan
On Tue, 2002-06-04 at 15:39, [EMAIL PROTECTED] wrote: I would like to nominate Sean Sullivan as a committer for the Jakarta Commons project. Sean has been active in providing patches and support the HttpClient project over the last several months and I think he would be a good addition to the community. +1 Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Sean Sullivan
On Tue, 2002-06-04 at 15:39, [EMAIL PROTECTED] wrote: I would like to nominate Sean Sullivan as a committer for the Jakarta Commons project. Sean has been active in providing patches and support the HttpClient project over the last several months and I think he would be a good addition to the community. I take it Sean isn't a committer on any other apache project because I don't see his name in /etc/passwd. Is this correct? If so just get Sean to send me his email address and the login he would like and I'll get his account set up. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] betwixt documentation
On Tue, 2002-06-04 at 18:05, Martin van den Bemt wrote: There is a mistake in the docs on how to build the demos. Fixed that.. Applied, thanks. Mvgr, Martin Index: xdocs/overview.xml === RCS file: /home/cvspublic/jakarta-commons-sandbox/betwixt/xdocs/overview.xml,v retrieving revision 1.1 diff -u -r1.1 overview.xml --- xdocs/overview.xml22 May 2002 18:13:41 - 1.1 +++ xdocs/overview.xml4 Jun 2002 22:03:28 - @@ -17,7 +17,7 @@ build system working, by installing Ant and creating your own build.properties to point to the required JARs type the following at a command line/p -preant demo-rss/pre +preant demo.rss/pre pThis uses the Commons Digester RSSDigester example to parse an RSS document, create a Channel bean and then write it out again as XML using the default @@ -26,7 +26,7 @@ pThe next example to look at is/p -preant demo-rss2/pre +preant demo.rss2/pre pThis is similar to the above but uses a BeanReader to parse the RSS file. So this is Betwixt defaulting the Digester rules required to parse the XML document. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/pool maven-build.xml project.xml
On Tue, 2002-06-04 at 19:05, Jon Scott Stevens wrote: on 6/4/02 8:05 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Added: pool maven-build.xml project.xml Shouldn't that be build-maven.xml to be consistent with what you have done on other projects? Yup, it should be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BETWIXT : Failing testcases..
On Tue, 2002-06-04 at 19:13, Martin van den Bemt wrote: What is your advice on my problem ? Just create my own tool ? (which I was doing in the first place, but I though, what the heck, let's try not to write everything myself..) Need to get that working tomorrow ;(( I'll take a peek but I'm not promising anything. I have been trying to fix for the last couple of days but haven't been able to spend more then a couple hours. (including db generation via jdbc, etc,etc..) You can do that with torque. After the time spend with what is happening, I could have easily made what I had in mind.. If Jason can fix this tonight I will be very happy ;) I probably won't fix it tonight. Either use XO or use the digester directly. If you can get my little xml file example working I'll be even happier ;) Post your NameMapper implementation and a testcase if you have one and I will commit it and try to get that working with Jon's (the ever persistent Jon :-)) example. Mvgr, Martin On Wed, 2002-06-05 at 01:07, Jon Scott Stevens wrote: on 6/4/02 4:03 PM, Martin van den Bemt [EMAIL PROTECTED] wrote: Betwixt fails on the scarab tests.. On the betwixt site the scarab tests are not included though.. It is failing on the TestScarabSettings.java line 196 (about), it is the assertEquals(UI, gao.getChildOption()); I seem to suffer a bit with the same problems (it looks like it, that is), which I mentioned in an earlier mail.. Mvgr, Martin Yup. Jason is supposed to be fixing this...;-) Those test cases show that betwixt has some pretty serious bugs in it. It is actually failing before that test is run because betwixt is trying to call the a method on the wrong object... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JJar via authenticating proxy
On Sun, 2002-06-02 at 11:41, Ross Gardler wrote: Is it possible to use the JJar ANT task via an authenticating proxy? It works fine through a non-authenticating proxy using the http.proxyHost and http.proxyPort system properties, but with an authenticating proxy a 407 (authentication failure) is returned. No, but this is one of the first things I fixed in Maven. http://jakarta.apache.org/turbine/maven/ Ross -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Betwixt MethodUpdaters
On Fri, 2002-05-31 at 03:42, James Strachan wrote:
Hi Jason
From: Jason van Zyl [EMAIL PROTECTED]
Hi James,
Is is possible to control at which point updaters are called with newly
created objects?
In Maven the project object has a method:
void addDistribution(Distribution distribution)
{
distributions.add(distribution);
}
But I would additionally like to place the distributions in a Map so
that I can subsequently look them up but it appears that the
distribution object added is not yet complete.
This isn't a huge deal because I can lazily initialize the distribution
Map I need but I was just wondering if the addXXX() method can be
delayed until the object has been fully populated.
It'd be a good idea to do this by default I think.
Some hacking of the BeanCreateRule should do the trick; to move the call of
the updater from the begin() method, called on the start of the element to
the end() method after the bean has been completely initialized. We'd
probably have to introduce a stack to keep track of the beans; I think one
of the reasons I did it this way was I could avoid writing that bit of code
;-)
Wanna have a go or would you like me to do it?
I can take a crack at it, I might take a look at some of the refactoring
we were talking about too. But it's looking great and it's working in
Maven very nicely. I'm glad to be rid of the xo mapper: that can now be
culled and I'll work on betwixt/digester now. Thanks for getting it all
up and running with the tests!
James
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] adding DynaBean.populate(Map) method?
On Thu, 2002-05-30 at 07:34, James Strachan wrote: When working with DynaBeans it might be nice to offer a populate(Map) method to easily populate a DynaBean from a map where the keys are property names and the values are the new property values to populate. I've already hit a use case for this in Jelly. Adding this method to DynaBean would also mirror the BeanUtils.populate(Object bean, Map) method in a more OO way. I'm happy to go ahead and do the work for this if folks agree. Does this seem a sensible idea? I'm +1 +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Betwixt MethodUpdaters
Hi James,
Is is possible to control at which point updaters are called with newly
created objects?
In Maven the project object has a method:
void addDistribution(Distribution distribution)
{
distributions.add(distribution);
}
But I would additionally like to place the distributions in a Map so
that I can subsequently look them up but it appears that the
distribution object added is not yet complete.
This isn't a huge deal because I can lazily initialize the distribution
Map I need but I was just wondering if the addXXX() method can be
delayed until the object has been fully populated.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Vote?
On Thu, 2002-05-30 at 16:15, Richard Sitze wrote: OK, so there were a number of +1 votes for both Arron Bates (+6) and myself, Richard Sitze (+4 : Arron wins)... Any volunteers to submit our names to the powers-that-be to turn on committer status? Done. Thanks! ras *** Richard A. Sitze -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/d igester AddDefaultsRule.java RuleSupport.java XMLIntrospectorHelper.java
On Tue, 2002-05-28 at 10:53, James Strachan wrote: From: Jason van Zyl [EMAIL PROTECTED] Right now betwixt is close to being able to round trip Maven's Project object model; just need configurable extra wrapping elements around collections for Turbine/Maven style XML documents. Cool!!! James can we call this version of betwixt 0.3 or something like that instead of the 1.0-dev name. I would like to cut a little release so that I can integrate betwixt into maven with a uniquely identified version. Why don't we do a full 1.0 release? Its about time; the code has been pretty stable for some time. Let me do a bit more hacking to ensure a clean round trip from XML - bean - XML - bean for Maven project beans; then thats a good time to do a release. I should get the code finished today I hope, then we can test it out for a few days. Sounds good to me, we should also push betwixt up to the commons proper. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Promote Modeler from Sandbox to Commons, Release 1.0
On Tue, 2002-04-30 at 12:15, Craig R. McClanahan wrote: The modeler package in jakarta-commons-sandbox provides easy APIs to create Model MBeans (see the JMX Specification) in server-side applications, based on configuration data loaded from an XML document. It is used in the nightly builds of Tomcat 4 (and in the Tomcat 4.1.0 test release) to provide the back-end JMX MBeans required for the new administrative web application in Tomcat. The code has been stable for several months, and there are no outstanding bug reports against it. I am calling this vote to (a) promote the modeler package from the sandbox to commons proper (with the initial developers as listed in the STATUS.html file), and (b) release the current modeler code base as a 1.0 release (I will act as release manager). Because these are two different actions, I've listed the votes separately in case people have different opinions about the two actions (although the first is a prerequisite for the second). -- Cut Here -- Vote to promote the modeler package from Sandbox to Commons proper [ ] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: +0 Vote to release Commons Modeler 1.0: [ ] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: +0 -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/docs/latka/apidocs stylesheet.cssserialized-form.html packages.html package-list overview-tree.htmloverview-summary.html overview-frame.html index.html index-all.htmlhelp-doc.html deprecated-list.html constant-values.htmlallclasses-noframe.html allclasses-frame.html
On Mon, 2002-04-01 at 00:36, [EMAIL PROTECTED] wrote: dion02/03/31 21:36:11 Added: docs/latka/apidocs stylesheet.css serialized-form.html packages.html package-list overview-tree.html overview-summary.html overview-frame.html index.html index-all.html help-doc.html deprecated-list.html constant-values.html allclasses-noframe.html allclasses-frame.html Dion, I don't think you want to check in a Maven generated site. The next time you change something the checkin is going to be massive and the changelog will definitely break the 100k limit. We haven't checked in any of the generated docs for the Turbine sites and things are working just fine. Is there a particular concern you had? Why you want to check in the whole generated site into CVS? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/latka project.xml build-maven.xml
On Fri, 2002-03-29 at 04:01, [EMAIL PROTECTED] wrote: Jason van Zyl [EMAIL PROTECTED] wrote on 29/03/2002 06:13:51 PM: On Fri, 2002-03-29 at 01:51, [EMAIL PROTECTED] wrote: dion02/03/28 22:51:00 Added: latkaproject.xml build-maven.xml Log: Initial maven project descriptor and build file Dion, Do you mind if I add you to Maven's powered by page? Go for it...the build is 'working' on most fronts. I'm still working out how to get a few things going, though, so the site isn't quite done yet, but we are on the way. I'm sure there will be some glitches :-) It was an amazingly painless exercise to setup, compared with the usual process. Cool. Next is to make the upgrade process as easy. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [httpclient] release and development questions
On Thu, 2002-03-28 at 10:48, Marc Saegesser wrote: I think the recent Tomcat 4.0.x releases have done a good job in this respect. Their release-plan document contains a list of all bug fixes and enhancements (or tasks, if you prefer that term) that are planned to be in the release. When all those items are done, it's time to cut the release. Obviously, there is some planning involved to decide what tasks will go into what release. The important thing is that we know what we're shooting for so we know when we're done. Cool, I'll take a look. -Original Message- From: Jason van Zyl To: Jakarta Commons Developers List Sent: 3/28/02 7:47 AM Subject: RE: [httpclient] release and development questions On Thu, 2002-03-28 at 09:35, Marc Saegesser wrote: We need the 'must have' list of things that have be complete prior to a release. You already mentioned the switch to commons-logging. I'd like to finish up the test cases for the new HttpMultiClient stuff. What format were you thinking of presenting the 'must have' todo for a release? I'm thinking about the same thing for Maven right now and I'm trying to come up with a visually appealing format because I need that doc for Maven right now. I was thinking of using some graphics to indicate priority but haven't found any yet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
On Thu, 2002-03-21 at 13:55, Craig R. McClanahan wrote: As long as the Ant property names themselves do not include the version numbers, the scheme would accomodate filenames that do. But, for the defaults (i.e. in build.properties.sample) the unversioned version of the names should be used. So you are actually swapping a JAR when you change it? So if you have a project that requires has moved from v1.1 to v1.2 of foo.jar what do you do with the v1.1 of the jar and what do you do if you have a project that requires v1.1 of foo.jar? Do you keep a directory structure with version numbers and version jars with no version numbers contained within that structure? I am trying to figure out a document that describes a JAR repository. The way Maven works both methods would work: a versioned directory structure with versionless jars, or a single directory with versioned jars. Even if the version is in the manifest, if you want to store more than a single version of the JAR you obviously can't put them in the same directory. The JAR repository could be made to work both ways. If it's on a unix machine symlinks could be used on the server and if this was to cause problems on a windows machine they could be duplicated I suppose. Personally, I think version numbers belong inside the JAR (in the META-INF/MANIFEST.MF file) where tools can get to them reliably, rather than in the filename itself, where users can easily mess them up. It should be up to a repository system (JJAR, Maven, whatever) to grab me version x.y of foo.jar when I ask for it. Then it is just a matter of how you store them. You need to store by version in some fashion or other. But the naming convention works either way. - Gidado Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: property naming (Re: cvs commit: jakarta-commons/digesterbuild.properties.sample)
On Tue, 2002-03-19 at 10:59, Henri Yandell wrote: I've been playing with it to use for work too. Trying to figure out what advantages JJAR has over just using cvs and ant-cvs tasks. Using something like JJAR or Maven (which has auto JAR downloading feature) allows you to use a single set of JAR files for building all your projects instead of having each project store JARs in CVS. Maven will currently see if you have the required JARs for building and brings them down from a central repository and stores them in your local repository for use. It's not fool proof yet, in Turbine land we battled with Maven yesterday to get all the distributions out the door but we did it and it worked and all of used the same set of JARs. So other than space issues and duplication of JARs everywhere there is the issue of using the JAR that was produced by the project itself. So if Turbine puts some JARs in the central repository they are guaranteed to be the JARs produced by Turbine and not some tweaked JAR that was placed in CVS. It's definitely easier to check everything into CVS but I believe the central repository of JARs theory will win out :-) On Tue, 19 Mar 2002, Tomasz Pik wrote: Jason van Zyl wrote: What about Commons-Sandbox JJar Component? I use a little modified version of this tool and I think this is a very good solution for 'continous integration' and managing of differen versions of libraries at all. BTW what is the future of JJar? Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/periodicity/conf/torquebuild.jars.properties deps.list
On Mon, 2002-03-18 at 00:26, Jeff Prickett wrote: On 17 Mar 2002, Jason van Zyl wrote: On Sun, 2002-03-17 at 12:57, [EMAIL PROTECTED] wrote: snip If you're trying to use the turbine stuff you can toss almost everything if you use maven. All you need is a project descriptor file and install maven. Thanks, I took a small break and checked out maven. Looks interesting... I will check it out for generating the site and possibly for building the build.xml file. However, my build.xml file is getting quite complicated and am not sure I want to trade the flexibility of a custom coded build process for maven. We have some pretty hairy builds in Turbine, dealing with code generation as you are and performing run time tests that are complicated in themselves. I will take a peek at your system, but I think most things can be accommodated. My theory is this: One big property file is too confusing because new users to the software do not necessarily know which properties they have to configure in order to get the software configured properly. For building I like no properties files :-) My solution to the problem is to break out the properties files into smaller groups and include multiple property files in the build.xml file. The build.properties file that resides in the top level directory will contain only the properties that are essential for a new user to configure and include links to the other property files that are needed. We hope to have ant do as much of the heavy lifting in the installation/configuration process as we can. It is our hope that we can get the build/install process down to four easy steps. 1. Edit the properties in the build.properties file. 2. Type ant update-dependencies 3. Type ant dist 4. Type ant install-db snip I probably wont be able to check out maven more thoroughly until after we get a 0.0.1 release of periodicity out the door. Thanks again for the heads up. No problem. Maven probably can't cover 100% of cases in it's current form. But the family of Turbine applications is pretty good test case and things are looking positive. Sincerely, Jeff Prickett -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/periodicity/lib tdk.jar
On Sun, 2002-03-17 at 12:33, [EMAIL PROTECTED] wrote: prickett02/03/17 09:33:39 Added: periodicity/lib tdk.jar Log: Added tdk.jar. This is the only file that we will keep in the library. It will enable us to retrieve all the other library files that we need. Revision ChangesPath 1.1 jakarta-commons-sandbox/periodicity/lib/tdk.jar The utility used for this is now in maven and has been removed from the TDK. You can just replace that jar with the maven.jar or you can use maven to take care of the whole thing for you. I've setup the graph2 package in the sandbox to use maven. Take a look at the docs here: http://jakarta.apache.org/turbine/maven/ Or come into the turbine chat room: irc.whichever.com: 6667 #turbine Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/periodicity/conf/torquebuild.jars.properties deps.list
On Sun, 2002-03-17 at 12:57, [EMAIL PROTECTED] wrote:
prickett02/03/17 09:57:31
Added: periodicity/conf/torque build.jars.properties deps.list
Log:
More torque configuration files. We are currently streamlining the build
process.
If you're trying to use the turbine stuff you can toss almost everything
if you use maven. All you need is a project descriptor file and install
maven.
I'm using maven for all the turbine projects now and I've generated all
the turbine sites using maven:
http://www.apache.org/~jvanzyl/tsite/
The maven installers are here:
http://www.apache.org/~jvanzyl/maven/
The installers are pretty green so back up your ~/build.properties.
There is also a JAR file that contains a maven installation.
Submitted by:Jeff Prickett
Revision ChangesPath
1.1
jakarta-commons-sandbox/periodicity/conf/torque/build.jars.properties
Index: build.jars.properties
===
lib.repo=./lib
velocity.jar = ${lib.repo}/velocity-1.3-dev.jar
xerces.jar = ${lib.repo}/xercesImpl-2.0.0.jar
xmlParserAPIs.jar = ${lib.repo}/xmlParserAPIs-2.0.0.jar
village.jar = ${lib.repo}/village-1.5.3-dev.jar
log4j.jar = ${lib.repo}/log4j-1.1.3.jar
commons-collections.jar = ${lib.repo}/commons-collections.jar
commons-lang.jar = ${lib.repo}/commons-lang-0.1-dev.jar
jdbc.jar = ${lib.repo}/jdbc2_0-stdext.jar
junit.jar = ${lib.repo}/junit-3.7.jar
stratum.jar = ${lib.repo}/stratum-0.1-dev.jar
1.1 jakarta-commons-sandbox/periodicity/conf/torque/deps.list
Index: deps.list
===
commons-collections.jar
commons-lang-0.1-dev.jar
jdbc2_0-stdext.jar
junit-3.7.jar
log4j-1.1.3.jar
stratum-0.1-dev.jar
velocity-1.3-dev.jar
village-1.5.3-dev.jar
xercesImpl-2.0.0.jar
xmlParserAPIs-2.0.0.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[betwixt] Strategy for dealing with addXXX() methods
Hi James, I was just looking at a way for trying to deal with addXXX() methods in a configurable way. I think I might have come up with a way to handle it. While passing through the bean information in XMLIntrospector.introspect() when discovering a loop type could we take the name, say Hobbies, and apply a strategy to determine its singular form? Then store that singular form for later use. So I could use a plural stemmer strategy that would turn Hobbies into Hobby and then in the XMLIntrospectorHelper.defaultAddMethods() the addHobby(Hobby hobby) would be matched up with Hobbies. We could maintain the current behaviour and possibly make these strategies stackable so that different attempts can be made. This would also allow things like i18n plural stemmers. I'm still trying to sort out some of the, it looks like there is some duplicated code in the XMLIntrospector* classes but I'm not exactly sure yet. But I think this method would work, I'll take any pointers. I think in a few more hours I'll be able to give it a whirl if the approach is acceptable. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [betwixt] Strategy for dealing with addXXX() methods
On Sun, 2002-03-10 at 20:26, James Strachan wrote: Hi Jason I think that approach sounds great. I'm sure we could plug in a few different Strategy patterns so that folks can customize the XMLIntrospector to suit their needs. e.g. some folks like to use mixedCaseNames for bean properties and mixed-case-names style XML elements. So go for it. BTW yes you're right, there's some duplicate code I introduced when implementing the loading of .betwixt files. I'm sure we can refactor that a bit cleaner to promote code reuse. Ok, I will give this a first go tomorrow. I would like to dump my mapper and I think we'll be using betwixt heavily in Tambora so I'll get on it. Just wanted to double check the approach: I will attempt to make the behaviour pluggable. James - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, March 10, 2002 5:17 PM Subject: [betwixt] Strategy for dealing with addXXX() methods Hi James, I was just looking at a way for trying to deal with addXXX() methods in a configurable way. I think I might have come up with a way to handle it. While passing through the bean information in XMLIntrospector.introspect() when discovering a loop type could we take the name, say Hobbies, and apply a strategy to determine its singular form? Then store that singular form for later use. So I could use a plural stemmer strategy that would turn Hobbies into Hobby and then in the XMLIntrospectorHelper.defaultAddMethods() the addHobby(Hobby hobby) would be matched up with Hobbies. We could maintain the current behaviour and possibly make these strategies stackable so that different attempts can be made. This would also allow things like i18n plural stemmers. I'm still trying to sort out some of the, it looks like there is some duplicated code in the XMLIntrospector* classes but I'm not exactly sure yet. But I think this method would work, I'll take any pointers. I think in a few more hours I'll be able to give it a whirl if the approach is acceptable. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[betwixt] Default Behaviour
Hi James, I'm just looking over the maven project descriptor in the tests and I was thinking again about a 'standard' format for XML files and was wondering if you had any opinions? Using all lower case: project ... /project Where the root element matches to a Project class. And something like: short-descriptionProject Management Tool/short-description and having that map to the setShortDescription(String) property. Or having the XML elements have Java variable looking names like: Project ... /Project and shortDescription.../shortDescription I honestly prefer the lower case with hypens but I'm not all that fussy. I will use the default behavior of betwixt to map everything that I've used my little mapper for so that all things Turbine will eventually use the a common format so that mapping will be consistent, error free and easy. Also how are nested objects created? Are they expected to be in the same package as the parent class? So if I have: project mailing-lists mailing-list name/ description/ subscribe/ unsubscribe/ archive/ /mailing-list /mailing-lists /project Is the MailingList class expected to be in the same package as Project class? Also would you mind if something like the following was added as default behaviour: pipeline valve className=o.a.t.valve.Valve1/ valve className=o.a.t.valve.Valve2/ /pipeline Where the className attribute would be used to instantiate the desired object? In the little mapper I made I used attributes as mapping information and the elements as bean data. Maybe you are doing the same but I'm just getting familiar with betwixt but I love it so far it's exactly what I've been wanting I just didn't know it :-) -- jvz. Jason van Zyl [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [betwixt] Default Behaviour
On Sat, 2002-03-09 at 22:13, Jason van Zyl wrote: pipeline valve className=o.a.t.valve.Valve1/ valve className=o.a.t.valve.Valve2/ /pipeline Correction: pipeline valve-list valve className=o.a.t.valve.Valve1/ valve className=o.a.t.valve.Valve2/ valve-list /pipeline -- jvz. Jason van Zyl [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [betwixt] UML Diagrams
On Thu, 2002-03-07 at 19:07, James Strachan wrote: From: Jason van Zyl [EMAIL PROTECTED] I'm just playing with betwixt, here are some UML diagrams I generated while taking a peek. http://www.apache.org/~jvanzyl/betwixt/ Way cool, thanks Jason. BTW for some time I've wanted an (open source) Ant task that autogenerates UML diagrams as part of the build along with the javadoc. Has anyone seen anything like that around? I guess you used Together/J to make these? Yup. I definitely want one for Maven. You could probably generate XMI from source/bytecode analysis, and there is jgraph (www.jgraph.org) and GVF (gvf.sourceforge.net) so you could produce graphs. What's very difficult is the layout. I know GVF has some stuff, have only started looking at jgraph. I want to make visual displays of the dependency graphs for projects. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[betwixt] UML Diagrams
Hi, I'm just playing with betwixt, here are some UML diagrams I generated while taking a peek. http://www.apache.org/~jvanzyl/betwixt/ -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[betwixt] coupling to digester
Hi James, Is betwixt now coupled to the digester? I removed the digester package from my build because I want to try to use your code to provide round trip goodies for my simple mapper and it didn't want to build. Would it be possible to make the input mechanism for the XMLIntrospector more flexible so it doesn't rely solely on the digester? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Conventions in new Sandbox Projects
On 1/22/02 2:52 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote:
Several of the newer jakarta-commons-sandbox packages don't follow the
build.xml conventions of the remainder of them -- not too surprising,
since these conventions are only documented in old email threads at the
moment (yes, copying them into a web page is on my TODO list unless
someone beats me to it). Nevertheless, it would be nicer for people
trying to build these packages if the build.xml files were tweaked a
little. Would that be possible?
GRAPH - Doesn't document its dependency on ${minml2.jar} so the
build breaks without it. It also doesn't appear that this
library is actually used???
Fixed, I copied the build file from JJAR.
JDBC2POOL - General convention is to have a dist build target that
creates a dist subdirectory with the JAR file, a copy of
the license, and the documentation.
SIMPLESTORE - Implicitly depends on an internal copy of lib/jisp.jar
instead of documenting an external dependency and using
build.properties.sample to show how to customize your
own pathname to it
UTIL- Same issue as with GRAPH, and same question about whether
minml2.jar is actually required or not.
Fixed, same as the graph package.
Thanks!
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Karma?
On 1/17/02 9:24 PM, dIon Gillard [EMAIL PROTECTED] wrote: I'd like to make some patches to Latka, but don't have sufficient karma...I'm guessing I can't update avail myself using cvs, so who do I ask nicely to add me?? Done. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Synergies between Avalon and Commons projects (was: Re:Breaking Excalibur into smaller swords)
On 12/26/01 8:42 AM, Berin Loritsch [EMAIL PROTECTED] wrote: James Strachan recently committed werken.opt to the Commons sandbox, illustrating that if Avalon doesn't take the initiative by moving stuff to Commons, code will materialize from somewhere else. Take a look at: http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt cache, configuration, lifecycle, pipeline, pool... it's like a second Excalibur, only without the IoC emphasis. Ok, that I do *not* understand. We already have a framework project, and that's Avalon. If the authors want to work on a framework work on this one. Who is we? After the Jserv project both Avalon and Turbine were started and continued down their own paths. Do we not have a right to pursue what we think a framework should be? I have some thoughts and designs that I would like to try that might not necessarily fit in with Avalon. I am not going to stop and try and make everything work with Avalon right off the bat. And Avalon did not start as a general framework, it started as a server framework and has slowly started changing it's charter over time to subsume more and more just as Turbine has. At the moment I want to work on Turbine not Avalon. All the code that will be pulled into stratum is code that I've refactored and pulled out of the original turbine code base. I'm not going to toss it all and start using Avalon. When I see multiple projects all with similar lifecycles, using different libraries, and thus uncompatible it makes me sick. C'mon, you guys have done the _exact_ same thing. Logging, pooling, database connection pooling, configurations. Lots of these things existed elsewhere but you wanted to try the IoC pattern with things and maybe some of these existing components weren't 100% usable in their existing form but I don't think anyone went out of their way really to try and work on these other packages to make them fit into avalon. Now don't get me wrong, I have done the same thing in many cases myself because it was easier to make things fit and I too didn't want to give up control over the development of a particular component. But don't try and tell me that Avalon has the only legitimate claim to being a framework around here because that's just nonsense. Competition is good, diversity of ideas is good even at the cost of the replication. Lots of people don't want to use Avalon, even more probably don't want to use Turbine and competing packages are showing up everywhere here and that's the way it is. There's a new services package in the commons which I'm sure will spawn some sort of lifecycle and configuration as always happens. That doesn't bother me at all. I know why people don't want to use Turbine and I honestly rarely recommend using it because it's not for the faint of heart right now. If someone can get the job done easier with something else like Struts than all the power to them. Turbine exacts a high toll in terms of forcing people into a lot of patterns (some that aren't very good I admit) and Avalon does the exact same thing which is why many turn to the commons for components. Don't be surprised if the whole of avalon is rebuilt in the commons in little pieces because it's going to happen. I have something nifty that I want to try in stratum and then I hope to put all the pieces into the commons. I don't think stratum has a long life expectancy but I need it to refactor Turbine. But in the long run I think people are going to look toward the commons for components. I think I share with you the philosophy of providing a consistent mechanism for develop WRT to components and methodologies all wrapped up in one package but I am always arguing with people about this. I like my arguments with Geir because he often counters my sometimes monolithic approach to things. I am honestly trying to provide a consistent development environment in Turbine just as you are in Avalon but it's a monumental task. Plus I think that around here people are more like us anyway and are going to take the bits and pieces and roll their own systems. And the components in the commons make this easier so it's something I'm definitely rethinking. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Possible addition to StringUtils
On 12/9/01 11:19 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Sun, 9 Dec 2001, Jason van Zyl wrote: Date: Sun, 09 Dec 2001 22:09:05 -0500 From: Jason van Zyl [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: Possible addition to StringUtils On 12/9/01 9:14 PM, Chad Johnson [EMAIL PROTECTED] wrote: Hey, Just wondering if a method that escapes single and double quotes, and other potential SQL query breaking characters has been considered for addition to the StringUtils class? Probably not. I'd say that's a little specific and the quoting schemes are sometimes different for different databases. This type of string manipulation that's database specific should probably be handled in your persistence mechanism. In Torque (http://jakarta.apache.org/turbine/torque) the behaviour of a particular database is modeled in an individual class, quoting is handled here. I've never had a problem with quote escaping since I went to using PreparedStatements for *all* database accesses (even if you're not going to reuse the PreparedStatement more than once). It's a much simpler programming approach. You're right, I just took a closer look at each of the torque adapters and they are all the same with respect to quoting. For some reason I thought that Interbase and Informix were different but I'm definitely wrong. I suppose the single quote is the SQL-92 string delimiter. This also deals with all the wierdness of representing dates, times, and so on in a database-independent manner. Of course, no solution is perfect -- you still have database-specific things for arcane join syntax and the like, but prepared statements for all calls covers 90-95% of the issues. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Digester documentation
On 11/13/01 11:43 AM, James Strachan [EMAIL PROTECTED] wrote: It might be a nice idea if we use JJAR's XML document format on Jakarta Commons projects to clearly document the exact dependencies each version has (both released and CVS HEAD). -1 The project descriptors in alexandria can be used for that. Then we could use XSLT or Velocity to generate the HTML documentation on the web and with each release of the exact version dependencies. Plus we could then use JJAR to do automated downloads of JARs too... James - Original Message - From: Afshartous, Nick [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:39 PM Subject: Digester documentation Just wanted to make a suggestion that the module dependencies for the digester (i.e. JAXP1.1, SAX 2.0) be put in more visible places other than the PROPOSAL.html in the source distribution. For instance on the web page and also in the binary distribution. -- Nick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
