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

On Wed, 2016-01-20 at 14:58 +0300, 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.
>
> 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?
>
Ok, I try to present them:

1) all pgjdbc maven dependencies have in Fedora in form of RPMs.
  - we are missing osgi-enterpise and waffle-jna

2) If We are not able to get any dependency into Fedora repositories we
need to find a way how to resolve it without any time bombs/hacks.
  - basicaly we need to find way how to remove/disable waffle-jna and
osgi-enterpise.

That's pretty much all we require.

I would like to shed some light into way how we work with maven. There
is tool called XMvn [1]. It works like maven but it is getting jar
files from RPMs which are already installed.

> Vladimir
>
>

[1] https://mizdebsk.fedorapeople.org/xmvn/site/