Обсуждение: Versioned vs unversioned jarfile names?
I have a request filed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145744 to supply version-less symlinks for the JDBC jarfiles that are distributed in the Postgres RPMs. Does anyone have a comment on whether this is a good or bad idea? I personally thought that it would be better to use names that aren't totally versionless, but include some sort of major version number that indicates API level, or something like that. But I don't know what would be appropriate. Thoughts welcome. regards, tom lane
We could certainly provide symlinks with specific information. We do have an interesting problem that most others don't ie API versions. How about publishing them to jpackage.org ? Dave Tom Lane wrote: >I have a request filed here: >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145744 >to supply version-less symlinks for the JDBC jarfiles that are >distributed in the Postgres RPMs. Does anyone have a comment >on whether this is a good or bad idea? > >I personally thought that it would be better to use names that aren't >totally versionless, but include some sort of major version number that >indicates API level, or something like that. But I don't know what >would be appropriate. Thoughts welcome. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 8: explain analyze is your friend > > > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
On Mon, 24 Jan 2005, Tom Lane wrote: > I have a request filed here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145744 > to supply version-less symlinks for the JDBC jarfiles that are > distributed in the Postgres RPMs. Does anyone have a comment > on whether this is a good or bad idea? > It's tough to say, not knowing what happens currently for the jar files or the server. If an upgrade is going to change the server major version without renaming say versioning binaries (psql-74 -> psql-80) then it doesn't seem any more dangerous to swap out the jar files. Do the jar files now get installed as postgresql-80-jdbc3 or postgresql-80-309-jdbc3? If it's the second case that would be a real pain to adjust your application to point to the new one every time it changed. What about multiple versions installed at the same time? Is that allowed? Who gets the generic symlink, the highest version, the last installed, user choice? Those might be tough questions, but in general the idea seems alright, because if they want to specify what specific major version to use they can still do that. Kris Jurka
Kris Jurka <books@ejurka.com> writes:
> Do the jar files now get installed as postgresql-80-jdbc3 or
> postgresql-80-309-jdbc3?
Currently they are installed under the same names they have on the FTP
server, viz
postgresql-8.0.309.jdbc2.jar
postgresql-8.0.309.jdbc2ee.jar
postgresql-8.0.309.jdbc3.jar
This is good for identifying the upstream source, but it does seem like
an awfully specific name to put into an application's classpath.
Another issue is that the prior release still had a jdbc1 jar:
pg74.215.jdbc1.jar
pg74.215.jdbc2.jar
pg74.215.jdbc2ee.jar
pg74.215.jdbc3.jar
> What about multiple versions installed at the same time? Is that allowed?
Yeah. We already have these same concepts in place for shared
libraries, where it's customary to provide (eg)
/usr/lib/libpq.so.3.2*
/usr/lib/libpq.so.3@ -> libpq.so.3.2
/usr/lib/libpq.so@ -> libpq.so.3.2
Basically I'm wondering whether there's an equivalent concept to
libraries' major version number.
regards, tom lane
Tom Lane wrote:
Agreed, I think we can drop the version number out of the linked file nameKris Jurka <books@ejurka.com> writes:Do the jar files now get installed as postgresql-80-jdbc3 or postgresql-80-309-jdbc3?Currently they are installed under the same names they have on the FTP server, viz postgresql-8.0.309.jdbc2.jar postgresql-8.0.309.jdbc2ee.jar postgresql-8.0.309.jdbc3.jar This is good for identifying the upstream source, but it does seem like an awfully specific name to put into an application's classpath.
We've dropped support for jdk 1 and subsequently jdbc1Another issue is that the prior release still had a jdbc1 jar: pg74.215.jdbc1.jar pg74.215.jdbc2.jar pg74.215.jdbc2ee.jar pg74.215.jdbc3.jar
I don't think this works with java, there is more information in the class file besides the signature of the class. The jar needs to be compiled by the same version of java that it will run under.What about multiple versions installed at the same time? Is that allowed?Yeah. We already have these same concepts in place for shared libraries, where it's customary to provide (eg) /usr/lib/libpq.so.3.2* /usr/lib/libpq.so.3@ -> libpq.so.3.2 /usr/lib/libpq.so@ -> libpq.so.3.2 Basically I'm wondering whether there's an equivalent concept to libraries' major version number.
regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
-- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561