Re: New Main class for derbytools.jar

definitely need to make the scripts more portable i had hoped to do it but just not enough cycles in the day right now. There might be a JIRA already there for this Kathy Saunders wrote: Andrew McIntyre wrote: This sounds reasonable to me. I was a little hasty in wanting to just get rid o

Re: New Main class for derbytools.jar

Andrew McIntyre wrote: This sounds reasonable to me. I was a little hasty in wanting to just get rid of the scripts. Experience has shown that having an example of how to set the classpath has always been useful, especially for people who might be new to Java, and it is pretty common to have se

Re: New Main class for derbytools.jar

Daniel John Debrunner wrote: Kathy Saunders wrote: I agree with Oystein. I do think there are customers who use these scripts--they are not just viewed by everyone as sample files. I also think that it's very common to have a bin directory that contains scripts like these. In particular,

Re: New Main class for derbytools.jar

On 2/22/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote: > > Perhaps we should advertise that the frameworks scripts are deprecated > as of 10.2 and will be removed in 10.3, and provide new scripts in a > bin directory that rely on DERBY_HOME and JAVA_HOME and self-configure > from there, like practi

Re: New Main class for derbytools.jar

On 2/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > > Do we need to leave the scripts in the frameworks directory as well? > If we care about backwards compatibility for these then they should > remain where they are. > > We may want to look at what useful scripts should be provided in a

Re: New Main class for derbytools.jar

Kathy Saunders wrote: > > I agree with Oystein. I do think there are customers who use these > scripts--they are not just viewed by everyone as sample files. I also > think that it's very common to have a bin directory that contains > scripts like these. In particular, I believe that users exp

Re: New Main class for derbytools.jar

Myrna van Lunteren wrote: On 2/22/06, *Øystein Grøvlen* <[EMAIL PROTECTED] > wrote: Andrew McIntyre wrote: > Great, let's take it one step further. Why don't we remove the > frameworks directory. Completely. All the scripts there are for > running the

Re: New Main class for derbytools.jar

On 2/22/06, Øystein Grøvlen <[EMAIL PROTECTED]> wrote: Andrew McIntyre wrote:> Great, let's take it one step further. Why don't we remove the> frameworks directory. Completely. All the scripts there are for > running the above three classes, and NetworkServerControl, which we> also recently added t

Re: New Main class for derbytools.jar

Andrew McIntyre wrote: Great, let's take it one step further. Why don't we remove the frameworks directory. Completely. All the scripts there are for running the above three classes, and NetworkServerControl, which we also recently added the ability to run with -jar. Perhaps we could have a top-

Re: New Main class for derbytools.jar

On 2/21/06, Myrna van Lunteren <[EMAIL PROTECTED]> wrote: > I'm assuming the lib in (eg) lib/derbytools.jar is referring to > the default location & thus optional? Correct. > Should also make implementing (a reworded) DERBY-667 - (test) more feasible > (before it was hard to think of a way of mak

Re: New Main class for derbytools.jar

On 2/21/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote: On 2/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:> Andrew McIntyre wrote: >> > Dan, expanding on your previous idea, what if we add a class to> > derbytools.jar as it's default run class that just switches on the> > available tools,

Re: New Main class for derbytools.jar

On 2/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > Andrew McIntyre wrote: > > > Dan, expanding on your previous idea, what if we add a class to > > derbytools.jar as it's default run class that just switches on the > > available tools, then you can do: > > > > java -jar lib/derbytools.j

Re: New Main class for derbytools.jar

Andrew McIntyre wrote: > Dan, expanding on your previous idea, what if we add a class to > derbytools.jar as it's default run class that just switches on the > available tools, then you can do: > > java -jar lib/derbytools.jar ij > java -jar lib/derbytools.jar sysinfo > java -jar lib/derbytools.j

New Main class for derbytools.jar

Following Dan's suggestion to be able to run ij with the -jar command, I thought why not have derbytools.jar itself be runnable with the -jar command, and have it switch on the tools, and pass the remaining arguments to the specific tool. Attached is the patch. If there are no objections, I'll fil