Re: How other package pgjdbc - Mailing list pgsql-jdbc

On Tuesday 26 of January 2016 03:34:00 Vitalii Tymchyshyn wrote:
> Well, first of all you dont need to package osgi classes. Those are the
> apis and as soon as you run in the osgi container, they are provided by
> container. But you need those to build the driver. And af far as I
> understand, there are certain licensing problems to do this, ain't they? I
> dont think it's pure packaging problem, e.g. see
> https://lists.fedoraproject.org/pipermail/legal/2012-July/001930.html.

Thanks, I was not aware of that.  This makes clear why people probably
want OSGi enterprise, but it can not live in open source distribution.

I'm not sure, is it safe to depend on it in upstream?

Pavel

> Thats why alternative sources of API were proposed.
>
> Best regards, Vitalii Tymchyshyn
>
> Пн, 25 січ. 2016 20:58 Álvaro Hernández Tortosa <aht@8kdata.com> пише:
>
> >
> >      Hi everybody. Top-posting here to avoid getting into finer detail,
> > providing more general opinion here.
> >
> >      To me the value of having pgjdbc packaged for Fedora/Red Hat, and
> > having it up to date, is undeniable. So let's find the ways to get it
> > done :)
> >
> >      Now I don't see productive analyzing one by one whether the
> > dependencies should be individually packaged or not. This is a very
> > common problem (or feature, as you may see it) of Java development, and
> > resolving it on a use-by-use case won't help. This kind of requires a
> > more general solution.
> >
> >      It is a good question why there are not packages like OSGI in rpm
> > already packaged. I understand the database team does not want to
> > maintain such package. What I see here is that there's a significant
> > "impedance mismatch" between distro packaging and Java. I strongly
> > believe this is the main reason there are few Java packages in the
> > distros, not that few users need it. Most Java users that use most Java
> > programs, in my experience, either download compiled, "fat" JARs (all
> > dependencies included) or use Maven. Few use pre-packaged distro
> > software (usually because it's unavailable).
> >
> >      And again, the reason for this is that Java development tends to
> > include one or several dependencies, and the ecosystem of dependencies
> > is huge (in my POV greater than any other language ecosystem, and by
> > far). So we have to consider one of the following two alternatives:
> >
> > - Take every dependency on any Java software to package (pgjdbc in this
> > case) and also package it as a separate package. This IMHO might get
> > crazy with other projects with more dependencies, since that may split
> > the process into even dozens of packages.
> > - Take the source of those dependencies, install it locally prior to
> > package building, and provide all as a single unit.
> >
> >      The first method might be a burden on the packagers and might not
> > be convenient in many senses. The second one is thus probably the best
> > one. It might sound terrible if several packages will end up packaging
> > the same code and not reusing it; but in Java (different apps) this is
> > hardly a problem (as it is in C with shared libraries).
> >
> >      So I'd suggest to focus on this second approach. Whether we like
> > OSGI or not, it is a feature of the current driver, and should not be
> > removed lightly. It diminishes its value. However, I understand that it
> > may not be packaged individually (more packages to maintain). So mi big
> > question is:
> >
> > Can OSGI dependency be pulled -as source, of course- into build
> > preparation phase, compile locally (mvn install or any alternative mean)
> > and ship it integrated with the pgjdbc package?
> >
> >      Cheers,
> >
> >      Álvaro
> >
> >
> >
> > On 25/01/16 16:33, Pavel Raiskup wrote:
> > > On Monday 25 of January 2016 15:33:18 Pavel Raiskup wrote:
> > >> On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
> > >>> Well like it or not, spring is arguably the largest enterprise java
> > >>> dependency and it has hundreds if not thousands of dependencies which
> > >>> enterprise users happily download.
> > >> I can concur with you, Dave.  There are people who are OK with that.
> > >>
> > >>> So I'm not sure how your argument holds water.
> > >> Sure.  You may choose to force users to use maven everywhere, via not
> > >> allowing us to build from source.  But I'm here please you not to do
> > that.
> > >>
> > >>> I would imagine from a redhat perspective redhat is the only trusted
> > >>> source.  However this is 2016 and the sheer volume of dependencies
> > >>> modern software requires makes this presumption untenable.
> > >> Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
> > >> All of those are used and trusted.  At least nowadays -- making this
> > >> totally off-topic is not worth;  I'm just trying to build from source.
> > >>
> > >> Believe it or not -- there are people who do not trust maven
> > repositories
> > >> -- and I'm not sure whether PostgreSQL project should encourage people
> > to
> > >> use maven repositories everywhere.  PostgreSQL should be re-distribuable
> > >> everywhere, if possible.
> > >>
> > >>> This argument is not constructive but an attempt to show another point
> > >>> of view.
> > >> Ack.
> > >>
> > >>> I have asked to join the osgi-dev list and will ask them how to deal
> > >>> with this issue
> > >> Right, but our mission is to distribute pgjdbc, not OSGi (which is
> > >> something osgi-dev will tell you probably).  If we could opt-out it, it
> > >> would be fine.
> > > Just a quick observation while trying to convince you that GNU/Linux
> > > distributions do care about pgjdbc package-ability:
> > >
> > > Gentoo build scripts:
> > >
> > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/jdbc-postgresql/jdbc-postgresql-9.4_p1206.ebuild
> > > Which is something I'm trying to avoid, but yes -- they were able to
> > > rebase to 1206 thanks to those hacks.
> > >
> > > Arch linux has pgjdbc in AUR repository.  It means that there is no
> > > support -- the reason is because they do not build from source;  they
> > > download the binary from upstream repository.
> > > https://aur.archlinux.org/packages/postgresql-jdbc/
> > >
> > > Debian has already been discussed.  Way too old packages.
> > >
> > > OpenSUSE (9.4.1201):
> > >
> > https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/postgresql-jdbc/postgresql-jdbc.spec?expand=1
> > >
> > > Pavel
> > >
> >
> >