Thread: advance notice - PL/Java 1.5.0 is in beta
Hi, As of Sunday, there is a beta for PL/Java 1.5.0, which will be the first formal numbered release since 1.4.3 back in 2011. Will it be possible to set up deb packaging for it when the final release is ready? What would you need from me? The preliminary release notes are here: https://tada.github.io/pljava/releasenotes.html Thanks, Chapman Flack
Re: Chapman Flack 2016-02-04 <56B2B5B8.6090800@anastigmatix.net> > As of Sunday, there is a beta for PL/Java 1.5.0, which will be > the first formal numbered release since 1.4.3 back in 2011. Hi Chapman, this is good news, to be honest I had given up on keeping to poke the list about new releases, and when pl/java wasn't compatible with the second PostgreSQL major release in a row, I even got the package removed from Debian. > Will it be possible to set up deb packaging for it when the final > release is ready? What would you need from me? Reading the release notes, a lot of weirdness got removed from the build/runtime system, so it should be feasible to get the package back up with modest effort. I'll give that a try later this week. Are there any gotchas about the OpenJDK version used? E.g. if I'm building the package with version 7, will it work at runtime with version 8? (Or the other way round?) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Re: To Chapman Flack 2016-02-04 <20160204094809.GA15172@msg.df7cb.de> > > Will it be possible to set up deb packaging for it when the final > > release is ready? What would you need from me? > > Reading the release notes, a lot of weirdness got removed from the > build/runtime system, so it should be feasible to get the package back > up with modest effort. I'll give that a try later this week. Hi again, unfortunately there's missing dependencies: $ mvn --offline clean build [INFO] Scanning for projects... [WARNING] The POM for com.github.maven-nar:nar-maven-plugin:jar:3.2.3 is missing, no dependency information available [ERROR] [ERROR] Some problems were encountered while processing the POMs: [ERROR] Unresolveable build extension: Plugin com.github.maven-nar:nar-maven-plugin:3.2.3 or one of its dependencies couldnot be resolved: The following artifacts could not be resolved: com.github.maven-nar:nar-maven-plugin:jar:3.2.3, org.codehaus.plexus:plexus-utils:jar:1.1:Cannot access central (https://repo.maven.apache.org/maven2) in offline mode andthe artifact com.github.maven-nar:nar-maven-plugin:jar:3.2.3 has not been downloaded from it before. @ [ERROR] Unknown packaging: nar @ org.postgresql:pljava-so:[unknown-version], /home/cbe/projects/postgresql/pljava/postgresql-pljava/pljava-so/pom.xml,line 14, column 13 @ [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project org.postgresql:pljava-so:1.5.0-BETA1 (/home/cbe/projects/postgresql/pljava/postgresql-pljava/pljava-so/pom.xml)has 2 errors [ERROR] Unresolveable build extension: Plugin com.github.maven-nar:nar-maven-plugin:3.2.3 or one of its dependenciescould not be resolved: The following artifacts could not be resolved: com.github.maven-nar:nar-maven-plugin:jar:3.2.3,org.codehaus.plexus:plexus-utils:jar:1.1: Cannot access central (https://repo.maven.apache.org/maven2)in offline mode and the artifact com.github.maven-nar:nar-maven-plugin:jar:3.2.3 hasnot been downloaded from it before. -> [Help 2] [ERROR] Unknown packaging: nar @ org.postgresql:pljava-so:[unknown-version], /home/cbe/projects/postgresql/pljava/postgresql-pljava/pljava-so/pom.xml,line 14, column 13 [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/PluginManagerException libplexus-utils-java is available in version 1:1.5.15-4: /usr/share/maven-repo/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.pom /usr/share/maven-repo/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar But it doesn't seem to like that version. There doesn't seem to be any "nar" in Debian. We can't build pl/java if any of the dependencies are missing in Debian. :( > Are there any gotchas about the OpenJDK version used? E.g. if I'm > building the package with version 7, will it work at runtime with > version 8? (Or the other way round?) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
On 02/04/16 06:27, Christoph Berg wrote: > [ERROR] Unresolveable build extension: Plugin > com.github.maven-nar:nar-maven-plugin:3.2.3 or one of its dependencies > could not be resolved: The following artifacts could not be resolved: > com.github.maven-nar:nar-maven-plugin:jar:3.2.3, > org.codehaus.plexus:plexus-utils:jar:1.1: > Cannot access central (https://repo.maven.apache.org/maven2) > in offline mode [????] > and the artifact com.github.maven-nar:nar-maven-plugin:jar:3.2.3 has not > been downloaded from it before. This puzzles me ... why is Maven running in offline mode? Does the build system here explicitly force it to offline, preventing it from doing exactly what Maven is intended to do? Maven builds work *because* Maven knows where to get and build all the mentioned dependencies. What I do if I don't want all the dependencies to end up on the system when it's done is, I mount a tmpfs somewhere and create a settings.xml that puts <localRepository> there. All the dependencies Maven downloads during the build go there, and when the build is done I unmount it and it's gone. -Chap
Re: Chapman Flack 2016-02-04 <56B3588A.6030901@anastigmatix.net> > On 02/04/16 06:27, Christoph Berg wrote: > > > [ERROR] Unresolveable build extension: Plugin > > com.github.maven-nar:nar-maven-plugin:3.2.3 or one of its dependencies > > could not be resolved: The following artifacts could not be resolved: > > com.github.maven-nar:nar-maven-plugin:jar:3.2.3, > > org.codehaus.plexus:plexus-utils:jar:1.1: > > > Cannot access central (https://repo.maven.apache.org/maven2) > > in offline mode > [????] > > and the artifact com.github.maven-nar:nar-maven-plugin:jar:3.2.3 has not > > been downloaded from it before. > > This puzzles me ... why is Maven running in offline mode? Does the > build system here explicitly force it to offline, preventing it from > doing exactly what Maven is intended to do? Hi Chap, Debian wants to be self-contained, which means we don't want to download stuff from external sources. At least for the plexus-utils dependency, it looks like pljava is trying to use something that is older than what we have packaged in Debian. Maybe you could relax that? (That still won't make the other dependencies appear, I didn't check if there's more besides this and "nar".) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Hi Christoph, On 02/04/16 09:04, Christoph Berg wrote: > Debian wants to be self-contained, which means we don't want to > download stuff from external sources. Hmm ... there's a puzzle here, this is a sensible enough policy on its face, but where it comes to maven-based builds and build-time- only dependencies, depending on how it's interpreted anyway, it seems on a direct collision course with the exact way maven is designed to operate. I am surprised if it has not seemed to cause trouble before PL/Java. > At least for the plexus-utils dependency, it looks like pljava is > trying to use something that is older than what we have packaged in > Debian. Maybe you could relax that? This is a good illustration of the problem. pljava does not have any direct dependency on plexus-utils. That's a transitive dependency from some build plugin pljava does use. In fact it's probably a transitive dependency from *several* plugins pljava uses (plexus-utils being a library plugins would frequently use). So you see there might be several different plugin authors I could approach and say "debian only packages plexus-utils 1.5.15-4 and they block maven from using the repo, so they'll never be able to build *my* project unless all of you can please update *your* projects simultaneously so that 1.5.15-4 is the exact version of plexus-utils that all of your projects depend on, and then everything will kind of work until the next time debian changes the one version they happen to provide, could you please do that for me thank you?" But the thing is--this is really important--*that is the exact problem maven's design purpose was to never have*. The author of every artifact and plugin is encouraged, as a best practice, to specify each dependency with the version number that he or she knows to work. Maybe some later version is all improved and also works, maybe it isn't, maybe it breaks something if Maven unexpectedly substitutes it. Some day each dependency author might evaluate a later version and decide that it works too, and then update that dependency version in their pom. There won't ever be a single day when the authors of all plugins get together and do that and agree on the same one dependency version that there happens to be a .deb for. If I run a PL/Java build here starting with an empty local repo, and collect the mvn -X output, I see that it downloaded the .pom files for 22 different plexus-utils versions from the central repo. Based on its own resolution analysis, it then downloaded 10 different plexus-utils-*.*.jar files. It wrote 54 plexus-utils related resolution tracking files. All of that is exactly what Maven normally does, to solve a complicated transitive dependency problem that we'd be insane to try to do by hand. That's what makes Maven Maven. To try to apply a policy that says "maven can't use the repo, we will solve all past/present/future dependency trees by thinking about them, then settle on the 'blessed' subset of repo artifacts that we will have .debs for and somehow things will work" is going to be like cutting William Tell's arms off and then wondering why he can't shoot straight. But can all this be looked at another way? What does "Debian wants to be self-contained" really mean? This is all _build-time_ dependency management we're talking about here, something that happens on a build server somewhere, none of it changes the self-contained experience of a debian installation where the generated .deb will be used. My suggested approach on the build server would be, make whatever container/ tmpfs arrangements you want, point there for an initially empty maven repository, sit back and watch maven go to town, then pluck the final pljava-*.jar file out of there and throw the container away. Make a .deb out of the jar file. It has exactly two dependencies as far as installation is concerned: it will need PostgreSQL, and it will need Java. :) I'm sure PL/Java will not be the last or only Maven-built artifact that might become available for debian. The build approach I've suggested here is really the only way I can see to approach it that seems at all promising.... Cheers, -Chap
Re: Chapman Flack 2016-02-06 <56B6565B.7070808@anastigmatix.net> > I'm sure PL/Java will not be the last or only Maven-built artifact > that might become available for debian. The build approach I've suggested > here is really the only way I can see to approach it that seems at all > promising.... Hi Chap, it's true that packaging of Java apps is problematic in Debian. I don't know enough about that part of Debian to say if that's because there's just not enough people working on it, or if the way the Java/Maven dependency resolution is designed to work just doesn't fit into the packaging policies that designed around shipping (C) libraries with SONAMEs. I'm investigating if the "contrib" archive section wouldn't allow relaxing this policy (it's still free software after all), or maybe simply shipping the .m2 in the source cache. There's also a "maven-debian-helper" which apparently mangles the source into a form that fits what's in the Debian archive, but I've never used it. Another question would be how we want to apply these policies to apt.postgresql.org. We don't have a "contrib" section there yet (neither "non-free"), but adding that wouldn't be much effort. I'll keep you updated. Christoph -- cb@df7cb.de | http://www.df7cb.de/