References: <1468510757.14072.40.camel@gunduz.org> <5787CBA3.60205@anastigmatix.net> From: Chapman Flack Message-ID: <578A9D48.7050900@anastigmatix.net> Date: Sat, 16 Jul 2016 16:47:04 -0400 MIME-Version: 1.0 In-Reply-To: <5787CBA3.60205@anastigmatix.net> Subject: Re: [Pljava-dev] Retrying: RPMifying PL/Java Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable On 07/14/16 13:28, Chapman Flack wrote: > On 07/14/2016 11:39 AM, Devrim G=FCnd=FCz wrote: >> >> # java -jar /usr/share/java/pljava-95.jar = >> META-INF/ = >> org/ = >> org/gjt/ = >> org/gjt/cuspy/ = >> pljava/ = > ... > = > So I don't know if a new ant version changed the API so it now > silently adds parent entries ... or something else is happening > in your build process that is overriding things (maybe there is > some automated step in rpmifying that extracts-and-rebuilds jars > using a tool that silently adds parent directory entries?). Hi, I've looked a little more at this, and remembered that this was the same issue we were puzzled by in February. From what I see *directly* in your spec and patch, and so far I have more questions than answers. I think it would be helpful to pin down _at what point_ the pljava-pg9.5-amd64-Linux-gpp.jar file turns out to have intermediate directory entries in it. For example, you could temporarily add a third line in the %build section right after the mvn clean install: jar tf ./%{sname}-packaging/target/%{sname}-pg9.5-amd64-Linux-gpp.jar and check the output. In the universe I inhabit, there should *not* be any intermediate directories listed ... only the paths that end in a file. If that's what you see, then the build is happening normally, and something is going wrong later. If I understand the rpm building process right, it looks like you are building an rpm that just contains the jar file (placed there with a simplified name by the 'install' command), and later, when someone deploys the rpm, that is when %post runs and extracts the jar. So I would be interested in the output of 'jar tf' on that jar file as it is stored in the rpm, compared to the same output immediately after mvn generated the file. I sort of wonder if the 'install' command has some sort of magic built in if it is installing a .jar file, and it extracts/rebuilds/ compresses/rearranges the jar somehow, and in that process it is adding intermediate directory levels for the originally contained paths. If that's what happens, then the next question is whether there is a way to make it not do that. If, on the other hand, you see the extra entries in the jar immediately after 'mvn clean install' before anything else has happened, then (a) I'll be extremely surprised, and (b) it will be a puzzle to figure out why, but because of (a) I'll wait to work on (b) until the evidence actually points that way. Cheers, -Chap incidentally, there might be easier ways to accomplish what the patch currently does. All the changes to the elements should be avoidable if the %build section just had PATH=3D/usr/pgsql-9.5/bin:$PATH mvn clean install and the one change in the javascript would be unnecessary if the %post section said java -jar %{_javadir}/%{name}.jar -Dpgconfig=3D/usr/pgsql-9.5/bin/pg_config ... then it looks like there'd be no need for a patch at all, and adjustments for new versions would be simpler. _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev