polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: Dependencies
Date Sat, 27 May 2017 13:50:17 GMT
Hey Niclas,

Niclas Hedhman a écrit :
> Paul,
> I think you are probably the only one who can answers this. This surfaces
> in the Yeoman generator with BootstrapTest, and most tests fail because of
> this (maybe other things).
> In a generated project, I have a dependency on, say entitystore-leveldb.
>     compile "org.apache.polygene.extensions:org.apache.polygene.extension.entitystore-leveldb:$polygeneVersion"
> In the generated project, the above is on the 'bootstrap' module, and the
> 'app' module has a dependency on 'bootstrap;
>     compile project( ":bootstrap" )
> Compiles alright, BUT when that project is RUN, the runtime dependency in
> entitystore-leveldb of;
>     runtimeOnly libraries.leveldb_java
>     runtimeOnly libraries.leveldb_jni_all
> seems to get lost in translation somewhere and not part of the classpath.
> So, the generated project is using "vanilla Gradle" without our fancy way
> of doing stuff, but the runtime dependencies of Polygene extension is not
> there, even though I think it should be.
> However, the dependencies of this configuration,
>     implementation libraries.leveldb_api
> are included transitively.
> IF this is the case, then that would seem to suggest that we have a serious
> problem somewhere.
> Any comment on what could possibly be going on here?

That's expected.

You need to choose your LevelDB implementation between pure-java or JNI.
For the JNI flavour you may want to only embedd the native libraries for
some platforms, not all of them.

The LevelDB EntityStore lack some documentation in this regard. It's
very much like JDBC drivers. `o.a.p.e:o.a.p.e.entitystore-sql` does not
depend on all supported JDBC drivers, one must add the dependency to the
choosen one. It's also the same as for polygene-runtime.

For the LevelDB EntityStore we could question this, and add the jni-all
dependency to it's `implementation` configuration. Consumers would then
have to exclude the dependency and add the one they want if need be.
Basically providing jni-all as a default.

We don't do much fancy stuff with dependencies in the Polygene build.
But we use the `java-library` plugin instead of the `java` plugin. See

I'd say the generated builds should use the `java-library` plugin too.
And not use the deprecated `compile`, `runtime`, `testCompile` and
`testRuntime` configurations but only `compileOnly`, `api`,
`implementation`, `runtimeOnly`, `testCompileOnly`, `testImplementation`
and `testRuntimeOnly`.

BTW, I just saw that the `app` project in generated builds puts the
servlet API in the `compile` configuration, that should go to
`compileOnly` instead.

I wanted to make some changes but the LevelDB generated project assembly
still fails for me on yeoman-work. I'll leave the keyboard and go
gardening instead :)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message