Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)

>Why do you think it's a time bomb?
> it won't build because osgi end up somewhere else.

It is a time bomb because it does not ensure it achieves "exclude all
osgi classes" goal.
For instance, suppose in a week I add a *test* class to validate that
OSGi does work in pgjdbc as designed?
That would add some new files to ".../src/test/java/...".
You would miss to delete them, thus your build will fail.

Once again: if you delete/add/modify random files from source
distribution, you are building on sand.
Expect random failures in that case.

If current pgsql's build procedure somehow does not suit you, go ahead
and raise the discussion on mailing list and/or GitHub's issue.

>Can you think about better solution?

A proper solution starts from "gathering the requirements".
I have not seen your requirements on the build procedure except "no internet".
Well, at some point there was a statement like "maven cannot be used at all".

I perfectly understand, that distribution of "waffle" in linux world
makes little sense.
So, I could understand the requirement of "there should be a build
parameter that excludes waffle from dependencies".
It is easy to test, so we setup just another Travis job that builds
"no waffle" variant and it will ensure the build would not get
corrupted by some random accident here or there.

On the other hand, you go right into the implementation details and
claim that if you change some "direct call" to "reflective call", then
it would magically solve the problem for you.
That does not work.
Even if that fix somehow gets merged in, I expect a pull request in a
day or two with exactly reverse change set: "improve performance of
waffle calls..."

That is why I strongly advice you to present your requirements in a
clear & testable way.
Does that make sense?

Vladimir