Dependencies

[Niclas Hedhman <ni...@hedhman.org>]

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?



Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Dependencies

[Niclas Hedhman <ni...@hedhman.org>]

Ok, thanks for the explanation. I am also leaving the keyboard for now, but
will take up the java-library plugin as you suggest. Probably other
mysteries tomorrow.

Btw, I am also adding that the tools/model-detail is applied in the
BootstrapTest, added toJson() for that, to get the model out in text form
more or less automatically, and always. Also adding 'envisage' as a feature
in the generator.


Cheers
Niclas

On Sat, May 27, 2017 at 9:50 PM, Paul Merlin <pa...@apache.org> wrote:

> 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
> https://docs.gradle.org/current/userguide/java_library_plugin.html
>
> 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 :)
>
> HTH
>
> Cheers
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Dependencies

[Paul Merlin <pa...@apache.org>]

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
https://docs.gradle.org/current/userguide/java_library_plugin.html

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 :)

HTH

Cheers