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

On Wednesday 20 of January 2016 14:58:02 Vladimir Sitnikov wrote:
> >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.

I was told that osgi sources are mine field for open-source world, no
clear licencing, source code, etc.  Each dependency needs to be taken with
*serious carefulness* -- case-by-case, is this documented somewhere in
pgjdbc code (licence implications)?

INAL, but this sounds like osgi support is something which can make newer
jdbc plugin GNU/Linux incompatible.  But also, because PostgreSQL license
is not against bundling with proprietary software -- you may expect that
two proprietary licenses will beat each other.

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

This is usual case, we are used to deal with similar issues, don't worry.

> 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.

Vladimir, I guess you've missed the fact that we are talking on upstream
mailing list.

> >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".

We may use maven as build tool, but third-party binary software blobs
*cannot be used at all*, it does not matter where those come from (maven
repositories or other RPM repositories).

> 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.

Do you have documentation for such approach, please?  We will be happy to
work on that.  And I don't think preprocessing in Java is an answer.

> 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.

This is very poor argument, to call this "issue", please say how much
slower it is and why.  If that is really issue, lets discuss how we can
make sure we'll fix the performance issues.

> 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..."

Be concrete Vladimir.  Who is going to merge this and who is going to
revert that later.  Will that be after serious discussion?  I wouldn't be
that much offensive..  let's make sure that we *all* advocate open source
principles, please.

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

That's what we work towards.

Pavel