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 server start and stop scripts. 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 practically every other Java project at Apache (think Ant). Should I formalize that with a vote? Or perhaps the vote to deprecate the scripts can happen once we have new, better ones. Now, off to file a JIRA for myself to write some better scripts... andrew +1 I like this approach. It should work well for existing customers and make it easier for new customers. Kathy
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 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 server start and stop scripts. 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 practically every other Java project at Apache (think Ant). Should I formalize that with a vote? Or perhaps the vote to deprecate the scripts can happen once we have new, better ones. Now, off to file a JIRA for myself to write some better scripts... andrew +1 I like this approach. It should work well for existing customers and make it easier for new customers. Kathy
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-level bin directory with a simple readme on how to run the tools. I would think there might be applications that currently depend on these scripts. They would break if the scripts are removed. -- Øystein
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 the ability to run with -jar. Perhaps we could have a top-level bin directory with a simple readme on how to run the tools.I would think there might be applications that currently depend on thesescripts.They would break if the scripts are removed.--Øystein It's a point...Although I always thought of the scripts as more of a 'sample' type file, I would expect a production application to need additional things, like their own jars, additional settings and the like, and/or have the jars in another place than the derby-home dir as indicated by the scripts... Myrna
Re: New Main class for derbytools.jar
Myrna van Lunteren wrote: On 2/22/06, *Øystein Grøvlen* [EMAIL PROTECTED] mailto:[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 the ability to run with -jar. Perhaps we could have a top-level bin directory with a simple readme on how to run the tools. I would think there might be applications that currently depend on these scripts. They would break if the scripts are removed. -- Øystein It's a point...Although I always thought of the scripts as more of a 'sample' type file, I would expect a production application to need additional things, like their own jars, additional settings and the like, and/or have the jars in another place than the derby-home dir as indicated by the scripts... Myrna 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 expect to see a startserver script or executable in a bin directory. My opinion is that we keep the scripts (with appropriate clean up), but move them to a bin directory under DERBY_HOME where they will be easier to find. Kathy
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 expect to see a startserver script or executable in a bin directory. My opinion is that we keep the scripts (with appropriate clean up), but move them to a bin directory under DERBY_HOME where they will be easier to find. 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 new bin directory. Ones that work without the user having to modify them or run separate setup scripts. Dan.
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 new bin directory. Ones that work without the user having to modify them or run separate setup scripts. 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 server start and stop scripts. 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 practically every other Java project at Apache (think Ant). Should I formalize that with a vote? Or perhaps the vote to deprecate the scripts can happen once we have new, better ones. Now, off to file a JIRA for myself to write some better scripts... andrew
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 practically every other Java project at Apache (think Ant). Forgot to mention that a major benefit of this approach is that it gives us much more time to manage the rather significant doc impact of this change. andrew
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, I believe that users expect to see a startserver script or executable in a bin directory. My opinion is that we keep the scripts (with appropriate clean up), but move them to a bin directory under DERBY_HOME where they will be easier to find. 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 new bin directory. Ones that work without the user having to modify them or run separate setup scripts. Dan. That's a good question. I suspect we'll be ok if we move them and still have the same commands available, but it would certainly need to be documented in the release notes as something that might affect existing applications. But, if we want to be *very* careful we could leave them or announce they would be moved (or removed) in a later release. I've seen applications that rely on these scripts, but my take is that they would make the adjustment to a bin directory without much fuss. I think that if someone decides to move the scripts, it would be good to post a question to the user list. Some of us who work with existing customers could also check. I could check with some of the Cloudscape customers to see what they think. If someone decides to take ownership of moving the scripts and wants me to query my customers, let me know. Kathy
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 file a JIRA for tracking purposes, and commit this. andrew toolsrun.diff Description: Binary data
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.jar dblook etc. +1 That's a very cool idea. Got to love that about open source development, throw out a half baked idea and someone else takes it a step further or a new direction and comes up with a great idea. Thanks, Dan.
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.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. +1 That's a very cool idea. 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-level bin directory with a simple readme on how to run the tools. What do you think? The downside is there's quite a bit of doc impact, but I'll be glad to help out with that. andrew
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, then you can do: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. +1 That's a very cool idea.Great, let's take it one step further. Why don't we remove the frameworks directory. Completely. All the scripts there are forrunning the above three classes, and NetworkServerControl, which wealso recently added the ability to run with -jar. Perhaps we couldhave a top-level bin directory with a simple readme on how to run the tools.What do you think? The downside is there's quite a bit of doc impact,but I'll be glad to help out with that.andrew +1 on that. I'm assuming the lib in (eg)lib/derbytools.jar is referring to the default location thus optional? Should also make implementing (a reworded)DERBY-667 - (test)more feasible (before it was hard to think of a way of making this work automatedon all platforms). And/but vice versa, if we are indeed doing this, we need to obviously definitely implement automated tests. Myrna
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 making this work automated on all platforms). And/but vice versa, if we are indeed doing this, we need to obviously definitely implement automated tests. Agreed. I'm having a hard time coming up with a good way to do that, though, besides pulling the location of the jar file out of the classpath, and then Runtime.exec()-ing the three java -jar commands with the tools jar and capturing the output. We could test the run class directly, but that doesn't test the manifest generation or that -jar actually works. Got any good ideas? I should also put the usage message into the locale file instead of hardcoding it in the file. andrew
