How to run TIkal under Intellij IDEA without logger error?

[krsk...@gmail.com]

Is anyone using IDEA ?

When I ran Tikal's Main class under Intellij, this error message is shown and the regular output isn't shown in the terminal pane:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

SLF4J: Defaulting to no-operation (NOP) logger implementation

SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Error: Unknown underlying logger, cannot capture it's output

This usually means the SLF4J's implementation class isn't in the class path.

But File > Project Structure > Libraries shows org.slf4j:slf4j-jdk14:1.7.30 is there.

What other settings do I need?

Kuro

[krsk...@gmail.com]

I was able to get rid of this by performing these steps:

File > Project Structure

Click on Modules in the side bar pf the popup window, then select okapi-application-tikal.

In the right side of the popup window, select the Dependencies tab.

Click the "+" symbol near the bottom of the dependency list, then choose Library from the list that pops up.

In the Choose Libraries popup, select Library and find and select Maven: org.slf4j:slf4j-jdk14, then click Add Selected.

In the Project Structure window, scroll down the list to find slf4j-jdk14. Change the scope to Runtime.

Click Apply.

[Alessandro Falappa]

Hi Kuro,

  I believe another way to do it would be to add to tikal module pom the following dependency:

<groupId>net.sf.okapi.logbind</groupId>

<artifactId>build-logback</artifactId>

<version>${project.version}</version>

And reload the project (Ctrl+Shift+O on Win/Linux, don't know on Mac).

That dependency is declared in the top level pom but as test scope dependency thus not included by Intellij IDEA in the run classpath of the module and its run configurations.

Hope it helps,

Alessandro Falappa

Senior Java Developer

--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/a0a549ed-88b5-4d88-a1af-b719276e85b4n%40googlegroups.com.

[krsk...@gmail.com]

Thank you, Alessandro!

Can't we have this dependency in the git repo? 

I understand we wouldn't want to do this if we were shading, but that doesn't seem to be the case for Tikal.

Kuro

[Mihai Nita]

I don't think we don't want it in the git repo, at least not as proposed.

At build time we use logback, for the official binaries we release we use jdk, and for artifacts published in maven we don't want to force anything on anyone.

Adding the proposed dependency in the pom would force logback everywhere.

But I 100% agree that running the applications in Eclipse / IntelliJ should log.

I'll dig into it.

Mihai

--

You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/c2e03be3-9987-4191-ac37-303a86b8edb3n%40googlegroups.com.

[Mihai Nita]

Please replace

    I don't think we don't want it in the git repo, at least not as proposed.

with

    I don't think we want it in the git repo, at least not as proposed.

Sorry, :-)

Mihai

[krsk...@gmail.com]

I pulled the latest dev, and tried to run a test in applications/integration-tests under Intellij Idea.

It complains that it cannot compile the test source because some of imports cannot be found:

import net.sf.okapi.common.FileCompare;

import net.sf.okapi.common.FileLocation;

import net.sf.okapi.common.StreamGobbler;

import net.sf.okapi.common.Util;

import net.sf.okapi.common.ZipFileCompare;

I see these classes were moved to the test dir in core. 

What is the right way to set up the module dependency? Changing the scope on okapi-core dependency to "test" didn't work.

(I marked applications/integration-tests/src/test/java as test source folder and ../src/test/resources as test resource folder.)

[jim]

Kuro,

Mihai has a PR reorganizing the integration tests into a single module. Comment on that PR if you are still finding problems. Hopefully the reorg will fix these issues.

Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/8668fbd9-5d12-41cf-bec9-3d4b2780c62fn%40googlegroups.com.

[krsk...@gmail.com]

Thank you. I added this as a comment to the PR.

[Mihai Nita]

OK, got it...

There are several things at play...

1.

Everything OKAPI (and a lot of 3rd party libraries used by Okapi) are doing the logging using slf4j

And we bind it to the jdk logger for the binaries we make available for the end-users,

we bind to logback for build time (and in general for development),

and we don't bind it to anything for the artifacts we publish to maven central (so that devs using Okapi are free to use whatever they want)

2.

Our applications (tikal, rainbow, etc) need a way to "intercept" the logging that goes to the bunded logger.

This is where the "Error: Unknown underlying logger, cannot capture it's output" message comes from (and just notices the grammar mistake :-)

We basically have to reach "below" slf4j (which does not have any way to "hook" in the logging), take all of those messages,

and show them nicely in the GUI (in the rainbow case) or enable / disable them (in the tikal case).

How you do that depends on the logging system used for binding.

Initially I've added "hooks" for log4j, logback, jdk, and jcl.

But that also included dependencies on all those loggers, which was not a good thing. So it was removed.

There is no good and quick option that I can think of.

I can think of a few decent ways, none of them quick to solve:

- move everything to logback, binaries & dev. that way we can just write the "hook" for logback

- rewrite the initial "hooks" the were aware of the various bindings, but in a way that does not introduce the maven dependencies

 (not sure what that way would be)

- write our own logging that binds to slf4j. Not necessarily simple (depending how fancy we want to get)

Creating our own logging API and migrate all of Okapi to use it does not help, as many of the libraries used by Okapi use slf4j, not our logger.

Mihai

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/6943e4cd-d96f-48ae-9d78-24ed93b108f4n%40googlegroups.com.

[jim]

For the applications I don't think it would be a bad thing to pick a
logger and embed it (of course for the lib we can't do that). We pick
the one that suites our needs (which imho would be the one that is
easiest to work with and has all the features we need).

I haven't looked over loggers in a while - not sure which one would be
the "best"

Jim

[krsk...@gmail.com]

If I take a look at superpom/pom.xml, it looks like we are standardized to the JDK14 logger. But that is not the case? I also see the JDK14 binding JAR in the lib directory of the Okapi application package, which tikal.sh is including in the class path.

  <dependencyManagement>

    <dependencies>

      ...

      <dependency>

        <groupId>org.slf4j</groupId>

        <artifactId>slf4j-jdk14</artifactId>

        <version>${org.slf4j.version}</version>

      </dependency>

I guess my question was why Intellij Idea isn't picking it up ?

[Alessandro Falappa]

Hello Kuro,

  I think I can answer that: it is how Maven works.

In a Maven POM the <dependencyManagement> section declares what version of dependencies you intend to use in the current module and all the descendants but does not add the dependency to the module classpath, to do that you have to declare the same dependency in the <dependencies> section.

You typically use a <dependenciesManagement> section in a parent POM to uniformly manage dependencies among all the child modules. In each child module POM you declare the actually used dependencies in their <dependencies> section and you can omit their version because it is inherited from the parent POM.That it is how it is used throughout Okapi too.

The addition of the JDK14 SLF4J binding to the tikal classpath in the shell script is OK because as Mihai said it is enough to compile against the SLF4J API (so you must have it as Maven dependency) and you can add a SLF4J implementation at runtime.

In my opinion the preferable approach here would be:

1. Bind to logback for development but let all the modules depend only on the SLF4J API
2. Use logback as SLF4J implementation for applications
3. Write only one logging interceptor facility assuming the logback implementation (the "hooks" mentioned by Mihai)

Although opinionated it is simple and maintainable.

Regards,

Alessandro Falappa

Senior Java Developer

--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/b312363b-b29b-4081-acf4-3db8d664ac5dn%40googlegroups.com.

[jim]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/CAE7HRi%2BUVBF7XiyhQF9xAcatduJ%2BS5wT9%2B71%2BEKOgcmZntjMxA%40mail.gmail.com.

[Mihai Nita]

Unifying to one single logger for both build and applications would be good, would simplify things a bit.

And loggback is absolutely fine.

When I messed with the logging it was a pretty strong support to not change the logger of the binaries from what it was before (jdk)

Mihai

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/d6947af7-77be-5887-8354-5490f2a352dd%40gmail.com.