Andrew McIntyre wrote:
[snip discussion about Class-Path manifest entries on backwards compat]
Also note that it only affects jars loaded via the -jars option or via
the classpath. The Class-Path attribute would have no affect on
classes loaded via a custom classloader or in an environment
dumb question. Wouldn't I find it useful to have all the jar files
munged together besides use with a tool like ij? What's wrong with
derbyall.jar?
David
Andrew McIntyre wrote:
On 3/1/06, Stanley Bradbury [EMAIL PROTECTED] wrote:
Having all the jars start with 'derby' has the advantage
Here's a thought for a totally different approach to solving
the original problem, which I will unfairly summarize as:
Make it easier for brand new users to run Derby in trial
situations without having to learn a lot about scripts and
CLASSPATH settings.
What if we shipped two
Bryan Pendleton wrote:
Here's a thought for a totally different approach to solving
the original problem, which I will unfairly summarize as:
Make it easier for brand new users to run Derby in trial
situations without having to learn a lot about scripts and
CLASSPATH settings.
What
Bryan Pendleton wrote:
Here's a thought for a totally different approach to solving
the original problem, which I will unfairly summarize as:
Make it easier for brand new users to run Derby in trial
situations without having to learn a lot about scripts and
CLASSPATH settings.
What
On 3/1/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Bryan Pendleton wrote:
Then, the new user tools and examples could just tell users
to run things like
java -jar derbyall.jar ij
java -jar derbyall.jar NetworkServerControl start
+1
I like it!
This is certainly reasonable,
Daniel John Debrunner wrote:
Bryan Pendleton wrote:
Here's a thought for a totally different approach to solving
the original problem, which I will unfairly summarize as:
Make it easier for brand new users to run Derby in trial
situations without having to learn a lot about scripts and
Andrew McIntyre wrote:
On 3/1/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Bryan Pendleton wrote:
Then, the new user tools and examples could just tell users
to run things like
java -jar derbyall.jar ij
java -jar derbyall.jar NetworkServerControl start
+1
I like it!
On 3/1/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How about *goderby.jar*
Only 7 letters and documents itself as a vehicle to get you on your way.
I like this. I also like the fact that it starts with g instead of d.
It will stand out in the list of jars: one of these things is not
like
Andrew McIntyre wrote:
On 3/1/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How about *goderby.jar*
Only 7 letters and documents itself as a vehicle to get you on your way.
I like this. I also like the fact that it starts with g instead of d.
It will stand out in the list of jars:
On 3/1/06, Stanley Bradbury [EMAIL PROTECTED] wrote:
Having all the jars start with 'derby' has the advantage of making them
easy to search for and they will short together in an alphabetical
listing like is produced by most directory listings. Having them sort
together when listing out
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
So from what I understand, your patch for DERBY-1063 will reintroduce
the DERBY-1045 regression that derbytools will load a different
derbyclient.jar than the one specificed by the user CLASSPATH but will
improve the sysinfo output . Is
On 2/27/06, Myrna van Lunteren [EMAIL PROTECTED] wrote:
If we're talking about making something easy to use, I would think this is
confusing - which derbyclient.jar will it pick up?
If possible, it would be nice to have the jar that's getting picked up first
listed at the top, and then
Andrew McIntyre wrote:
And this is a valid concern, which I understand.
I think the question here boils down to: in what situations would a
third party ship derbytools.jar, and include it on the classpath with
a previous version of derbyclient.jar? Is that a good practice anyway?
I don't have
Andrew McIntyre wrote:
On 2/28/06, Kathey Marsden [EMAIL PROTECTED] wrote:
There was lots of talk in old code sharing threads about the potential
for two different parties to have interaction and won't get into that
here. I am not sure though about the potential for tools impact in
these
Andrew McIntyre wrote:
*Two applications should be able to use one version of the Derby
network client driver and a different version of the Derby embedded
driver within the same Java VM without having to resort to creating
specialized classloaders.
This would still be true, but care must be
On 2/28/06, Kathey Marsden [EMAIL PROTECTED] wrote:
The two applications are not aware of each other and have no control
over classpath order.
Right. How is the classpath determined then? It's not random. This is
the question I posed at the end of my last mail and the problem I'm
trying to get
Andrew McIntyre wrote:
10.2 tools : 10.1 client : 10.1 engine = 10.2 client / 10.2 engine
10.1 client : 10.2 tools : 10.1 engine = 10.1 client / 10.2 engine
10.1 derby : 10.1 engine : 10.2 tools = 10.1 client / 10.1 engine
Of course, I'm not sure what sort of usage (outside of our tests)
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
derbytools.jar will automatically put derbyclient.jar in the
classpath. Since you have derbytools.jar from trunk before
derbyclient.jar version 10.1 in your classpath, derbyclient.jar will
be shadowed. Sysinfo will however report that you
Andrew McIntyre wrote:
I hadn't considered the mixed jar environment, sorry, and I guess
there's no choice but to take out the Class-Path attribute from
derbytools.jar. Sadly, it cripples the spirit of 1019: there is then
no direct path to using the tools and one must explain classpath
before
Andrew McIntyre wrote:
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
derbytools.jar will automatically put derbyclient.jar in the
classpath. Since you have derbytools.jar from trunk before
derbyclient.jar version 10.1 in your classpath, derbyclient.jar will
be shadowed. Sysinfo will
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Andrew McIntyre wrote:
I hadn't considered the mixed jar environment, sorry, and I guess
there's no choice but to take out the Class-Path attribute from
derbytools.jar. Sadly, it cripples the spirit of 1019: there is then
no direct path to
Kathey Marsden wrote:
Andrew McIntyre wrote:
I hadn't considered the mixed jar environment, sorry, and I guess
there's no choice but to take out the Class-Path attribute from
derbytools.jar. Sadly, it cripples the spirit of 1019: there is then
no direct path to using the tools and one must
Andrew McIntyre wrote:
On 2/27/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
Let's not rush into removing this feature, which is really useful for
the majority of Derby users. Let's understand the impact on existing
users and see what the best way forward is.
Ack! Read this about two
Daniel John Debrunner wrote:
Isn't DERBY-1019 the correct place for this?
Or perhaps a separate issue created to autoload derbyclient.jar with
derbytools.jar.I certainly did not glean that impact from the
DERBY-1019 description. It would be nice to see it as a separate issue.
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:
Isn't DERBY-1019 the correct place for this?
Or perhaps a separate issue created to autoload derbyclient.jar with
derbytools.jar.I certainly did not glean that impact from the
DERBY-1019 description.
Andrew McIntyre wrote:
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:
Isn't DERBY-1019 the correct place for this?
Or perhaps a separate issue created to autoload derbyclient.jar with
derbytools.jar.I certainly did not glean that impact
On 2/27/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Andrew McIntyre wrote:On 2/27/06, Kathey Marsden
[EMAIL PROTECTED] wrote:Daniel John Debrunner wrote:Isn't DERBY-1019 the correct place for this?Or perhaps aseparate issuecreatedto autoload
derbyclient.jar withderbytools.jar.I certainly did not
28 matches
Mail list logo
