You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Osma Suominen <os...@helsinki.fi> on 2016/01/18 13:37:26 UTC

VERSION and BUILD_DATE for jena-sdb commands

Hi,

I've recently reenabled building of the jena-sdb distribution (see 
JENA-1118). After building the packages, I noticed that the --version 
flag gives the versions of Jena, ARQ and RIOT, but the version and build 
date information for SDB itself is missing:

$ sdbinfo --version
Jena:       VERSION: 3.1.0-SNAPSHOT
Jena:       BUILD_DATE: 2016-01-14T09:48:43+0000
ARQ:        VERSION: 3.1.0-SNAPSHOT
ARQ:        BUILD_DATE: 2016-01-17T18:26:28+0000
RIOT:       VERSION: 3.1.0-SNAPSHOT
RIOT:       BUILD_DATE: 2016-01-17T18:26:28+0000
SDB:        VERSION: unknown
SDB:        BUILD_DATE: unset


Forgive my ignorance, but how is this determined/stored and where can I 
fix it? To my eyes, the jena-sdb pom.xml looks similar to the other 
modules and has version information among other things, but somewhere 
along the way it gets lost apparently.

Older versions of SDB distributions did show this correctly.

-Osma


-- 
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi

Re: VERSION and BUILD_DATE for jena-sdb commands

Posted by Andy Seaborne <an...@apache.org>.
On 19/01/16 12:15, Osma Suominen wrote:
> 18.01.2016, 16:21, Andy Seaborne wrote:
>
>> Should be fixed now. I must have left some maven-generated files around.
>
> Thanks Andy, it works for me now!
>
>> PS What I don't understand is why the SDB command line tools are so slow
>> to start up.
>
> #define slow?
>
> For me, sdbinfo is about 1.5 seconds:
>
> $ time bin/sdbinfo --version
> Jena:       VERSION: 3.1.0-SNAPSHOT
> Jena:       BUILD_DATE: 2016-01-18T22:45:03+0000
> ARQ:        VERSION: 3.1.0-SNAPSHOT
> ARQ:        BUILD_DATE: 2016-01-18T22:45:03+0000
> RIOT:       VERSION: 3.1.0-SNAPSHOT
> RIOT:       BUILD_DATE: 2016-01-18T22:45:03+0000
> SDB:        VERSION: 3.1.0-SNAPSHOT
> SDB:        BUILD_DATE: 2016-01-19T14:05:40+0200
>
> real    0m0.989s
> user    0m1.560s
> sys    0m0.096s
>
>
> My guess is that this is because sdbinfo (and others) calls sdb_init,
> which in turn calls sdb_path, which calls make_classpath (or
> make_classpath_mvn). All those bash startups add up.
>
> I can live with a couple of seconds startup delay, but refactoring the
> scripts is an option.

Ping - light bulb moment.  I have scripts of greater complexity and they 
fly.

It's the  make_classpath_mvn when using dev classes which calls maven to 
make the classpath.  And maven can go out to the web ...

It's an old way of doing it - Jena's newer scripts are much more slick 
and my "set dev" one is similarly much newer.  They do "<last 
version>/lib/*" to get the dependencies then prepend target/classes for 
most of -Pdev modules.

And can run different versions which helps for questions.

I'll put them ("it"; one script, many names) somewhere if people would 
find it useful.  And can improve them - I'm not claiming its great bash 
scripting.  Maybe there are better ways people are doing it.

	Andy
>
> -Osma
>



Re: VERSION and BUILD_DATE for jena-sdb commands

Posted by Osma Suominen <os...@helsinki.fi>.
18.01.2016, 16:21, Andy Seaborne wrote:

> Should be fixed now. I must have left some maven-generated files around.

Thanks Andy, it works for me now!

> PS What I don't understand is why the SDB command line tools are so slow
> to start up.

#define slow?

For me, sdbinfo is about 1.5 seconds:

$ time bin/sdbinfo --version
Jena:       VERSION: 3.1.0-SNAPSHOT
Jena:       BUILD_DATE: 2016-01-18T22:45:03+0000
ARQ:        VERSION: 3.1.0-SNAPSHOT
ARQ:        BUILD_DATE: 2016-01-18T22:45:03+0000
RIOT:       VERSION: 3.1.0-SNAPSHOT
RIOT:       BUILD_DATE: 2016-01-18T22:45:03+0000
SDB:        VERSION: 3.1.0-SNAPSHOT
SDB:        BUILD_DATE: 2016-01-19T14:05:40+0200

real	0m0.989s
user	0m1.560s
sys	0m0.096s


My guess is that this is because sdbinfo (and others) calls sdb_init, 
which in turn calls sdb_path, which calls make_classpath (or 
make_classpath_mvn). All those bash startups add up.

I can live with a couple of seconds startup delay, but refactoring the 
scripts is an option.

-Osma

-- 
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi

Re: VERSION and BUILD_DATE for jena-sdb commands

Posted by Andy Seaborne <an...@apache.org>.
On 18/01/16 12:37, Osma Suominen wrote:
> Hi,
>
> I've recently reenabled building of the jena-sdb distribution (see
> JENA-1118). After building the packages, I noticed that the --version
> flag gives the versions of Jena, ARQ and RIOT, but the version and build
> date information for SDB itself is missing:
>
> $ sdbinfo --version
> Jena:       VERSION: 3.1.0-SNAPSHOT
> Jena:       BUILD_DATE: 2016-01-14T09:48:43+0000
> ARQ:        VERSION: 3.1.0-SNAPSHOT
> ARQ:        BUILD_DATE: 2016-01-17T18:26:28+0000
> RIOT:       VERSION: 3.1.0-SNAPSHOT
> RIOT:       BUILD_DATE: 2016-01-17T18:26:28+0000
> SDB:        VERSION: unknown
> SDB:        BUILD_DATE: unset
>
>
> Forgive my ignorance, but how is this determined/stored and where can I
> fix it? To my eyes, the jena-sdb pom.xml looks similar to the other
> modules and has version information among other things, but somewhere
> along the way it gets lost apparently.
>
> Older versions of SDB distributions did show this correctly.
>
> -Osma
>

There is a file
src/main/resources/org/apache/jena/sdb/sdb-properties.xml
that gets maven-processed to hard wire the
build details. (So under Eclipse it is wrong - it's a filtered maven 
resource).

But the resource path name to it in the java was wrong.

I was fixing up initialization as the init code wasn't firing 
automatically (useful in Fuseki) and moved the properties file but 
mistyped the resource name in SDB.java.

Should be fixed now. I must have left some maven-generated files around.

	Andy

PS What I don't understand is why the SDB command line tools are so slow 
to start up.