Re: Maven Artifact JDK Suffix

Поиск
Список
Период
Сортировка
От Mikko Tiihonen
Тема Re: Maven Artifact JDK Suffix
Дата
Msg-id 569CB5C8.1040201@nitorcreations.com
обсуждение исходный текст
Ответ на Re: Maven Artifact JDK Suffix  (Sehrope Sarkuni <sehrope@jackdb.com>)
Ответы Re: Maven Artifact JDK Suffix  (Dave Cramer <pg@fastcrypt.com>)
Список pgsql-jdbc
On 01/16/2016 04:55 PM, Sehrope Sarkuni wrote:
On Fri, Jan 15, 2016 at 9:15 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>* jre07-9.4.1207
 
We'd probably better follow "plug&pray" development style and go ahead
with jre6/jre7/jre8 then.

Yes I guess we don't really have much other choice besides complicating things quite a bit with separate dependencies for the API itself (and/or separate artifacts per JDK).

We should add a note to the README about this as well. I'm sure someone will eventually run into the issue of a dependency specifying a newer driver version with a lower JDK. Would be nice to have it documented somewhere that the solution is to make sure the top level Maven project specifies the latest version for the desired JDK version.

I'd like to point that the latest java9 pre-release (jre9 build 100) contains support for Multi-Release jars http://openjdk.java.net/jeps/238. This means we can put both jre8 and jre9 specific classes to same jar file. So we only need the jre6 and jre7 for legacy reasons. For users this is a good news since they no longer have to care about their jre version - the single jar just works for them, even after they update the jre.

So my proposal is to not add jre8 qualifier to the current jre8 jars. We just need to add support to the build for the multi-release jars before jre9 is released next year. I'm certain that a proper maven tooling to do that will materialize in time.

-Mikko

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [BUGS] BUG #13856: JDBC driver 1207 not picking up properties
Следующее
От: Pavel Kajaba
Дата:
Сообщение: Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)