Re: [Pljava-dev] Retrying: RPMifying PL/Java

On 07/14/16 13:28, Chapman Flack wrote:
> On 07/14/2016 11:39 AM, Devrim Gündüz 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 <exec> elements should
be avoidable if the %build section just had

PATH=/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=/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(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev