New Main class for derbytools.jar

[Andrew McIntyre <mc...@gmail.com>]

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

Re: New Main class for derbytools.jar

[Andrew McIntyre <mc...@gmail.com>]

On 2/21/06, Myrna van Lunteren <m....@gmail.com> 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

Re: New Main class for derbytools.jar

[Myrna van Lunteren <m....@gmail.com>]

On 2/21/06, Andrew McIntyre <mc...@gmail.com> wrote:
>
> On 2/21/06, Daniel John Debrunner <dj...@apache.org> 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


+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 automated on 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

[Andrew McIntyre <mc...@gmail.com>]

On 2/22/06, Andrew McIntyre <mc...@gmail.com> 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

["Lance J. Andersen" <La...@Sun.COM>]

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

[Kathy Saunders <ka...@mtrad.com>]

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 <mc...@gmail.com>]

On 2/22/06, Daniel John Debrunner <dj...@apache.org> 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

[Kathy Saunders <ka...@mtrad.com>]

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

Re: New Main class for derbytools.jar

[Daniel John Debrunner <dj...@apache.org>]

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

[Kathy Saunders <ka...@mtrad.com>]

Myrna van Lunteren wrote:

> On 2/22/06, *Øystein Grøvlen* <Oystein.Grovlen@sun.com 
> <ma...@sun.com>> 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

[Myrna van Lunteren <m....@gmail.com>]

On 2/22/06, Øystein Grøvlen <Oy...@sun.com> 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

Re: New Main class for derbytools.jar

[Øystein Grøvlen <Oy...@Sun.COM>]

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

[Andrew McIntyre <mc...@gmail.com>]

On 2/21/06, Daniel John Debrunner <dj...@apache.org> 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

[Daniel John Debrunner <dj...@apache.org>]

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.