enhance packaging of h2 distribution for easier version switching

[GoogleCodeExporter]

What steps will reproduce the problem?
(simple SQL scripts or simple standalone applications are preferred)
1. download h2 distribution zip from
http://code.google.com/p/h2database/downloads/list
2. unpack it
3. find the h2.jar as h2/bin/h2-1.1.115.jar

What is the expected output? What do you see instead?
expected: h2-1.1.115/bin/h2.jar or h2-1.1.115-<date_of_packaging>/bin/h2.jar

What version of the product are you using? On what operating system, file
system, and virtual machine?
1.1.115

Do you know a workaround?
Renaming the path and the jar file every time

How important/urgent is the problem for you?
Whenever I download a new version of h2database I have to "correct" the
references to the new h2.jar (from h2-1.1.114.jar to h2-1.1.115.jar, etc.)

In your view, is this a defect or a feature request?
enhancement

Please provide any additional information below.

Original issue reported on code.google.com by frank.sc...@gmail.com on 14 Jul 2009 at 7:25

[GoogleCodeExporter]

The majority seems to prefer the current directory and jar file names,
so I will currently not change it.

Original comment by thomas.t...@gmail.com on 17 Jul 2009 at 4:54

• Changed state: WontFix

[GoogleCodeExporter]

Just for the record: The "majority" seems to be using maven. They are not 
effected by
this suggestion. They opposed for no practical reason (see:
http://groups.google.com/group/h2-database/browse_thread/thread/3de603a636189558
)

Original comment by frank.sc...@gmail.com on 18 Jul 2009 at 6:52

[GoogleCodeExporter]

Hi,

Yes, many are using Maven. And in Maven, the jar file name _needs_ to include 
the
version, so h2.jar is not possible. And I don't want to distribute two jar 
files with
the same content but a different name.

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 18 Jul 2009 at 7:42

[GoogleCodeExporter]

"mvn install:install-file ..." or "mvn deploy:deploy-file..." will install an
existing "h2.jar" as "h2-1.1.115.jar" into the local or into the remote 
repository,
respectively. IMHO, the version number (as part of the maven-coordinates) has 
to be
defined over there anyway (-DgroupId=com.h2database -DartifactId=h2 
-Dversion=1.115)

Neither is there a compelling reason for a maven artifact to carry on the 
version
number on its file name. It can be changed into anything by
<project><build><finalName>${project.artifactId}</finalName>...</></>. And, it 
does
not affect how the artifact is installed into the repository.

See:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

Original comment by frank.sc...@gmail.com on 18 Jul 2009 at 8:21

[GoogleCodeExporter]

Hi,

Check your local .m2 directory and you will see the jar file names include the 
version.

It will stay like it is, case closed.

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 18 Jul 2009 at 9:29

[GoogleCodeExporter]

As I said: "And, it does
*not* affect how the artifact is installed into the repository." :-)

I am perfectly fine with the case being close. But I dislike lies and 
misconceptions.

Best,
Frank

Original comment by frank.sc...@gmail.com on 18 Jul 2009 at 9:57

[GoogleCodeExporter]

> it does *not* affect how the artifact is installed

I know that. But when I wrote "in Maven, the jar file name _needs_ to include 
the
version", I meant in the Maven repository (the .m2 directory).

> But I dislike lies and misconceptions.

I guess this was more a misunderstanding than a lie.

Original comment by thomas.t...@gmail.com on 18 Jul 2009 at 10:06