Re: Pre-processing during build
От | Kevin Carr |
---|---|
Тема | Re: Pre-processing during build |
Дата | |
Msg-id | CAC92xspTSeNEwmHCH8mpFhioLMghjxQb6FtBGbkKuwRStu6uww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pre-processing during build (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
In hikaricp they have a java6 version for 1.6 and 1.7 and the main version has for 1.8. This has worked really well for our osgi installations.
On Thu, Jun 18, 2015, 3:09 PM Dave Cramer <pg@fastcrypt.com> wrote:
OK, I have access logs, They only go back as far as April 12 2015. A very cursory look shows many downloads of jars I would not have expected. Do we have any tools to summarize them ? Preferably command lineDaveOn 18 June 2015 at 15:33, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:John> and that stuff NEVER gets updated until the equipment is replaced.
That is cool. However, that means you don't care if pgjdbc drops
updates for JDK6, do you?
My theory is as follows: if there is a nice "decay of download rate",
then we might have a bit more educated guess on "the number of
supported JDKs"
Dave> I provide professional services to companies that do
Ok, let's try supporting JDK6.
So, the next step is to start from
https://github.com/pgjdbc/pgjdbc/pull/322 and try to split it into
several maven submodules.
The interesting question is if we want to those submodules (jdbc4,
jdbc41, jdbc42) to be public (in other words, allow users depend on
them) or if we consider them a pure implementation detail.
In the latter case, we might want to have some fixed name of the
module that includes the latest driver.
I would prefer to have a single artifact in the "public API" that
includes all the jdbc versions.
Vladimir
В списке pgsql-jdbc по дате отправления: