modules/java build issues

[algernon]

When trying to compile syslog-ng with make -j4, I got the following results:

 GEN      modules/java/org/syslog_ng/LogTemplate.class
../modules/java/SyslogNgClassLoader.java:69: error: cannot find symbol
      InternalMessageSender.error("Exception: " + e.getMessage());
      ^
  symbol:   variable InternalMessageSender
  location: class SyslogNgClassLoader
../modules/java/SyslogNgClassLoader.java:73: error: cannot find symbol
      InternalMessageSender.error("Error: " + e.getMessage());
      ^
  symbol:   variable InternalMessageSender
  location: class SyslogNgClassLoader
../modules/java/SyslogNgClassLoader.java:77: error: cannot find symbol
      InternalMessageSender.error("Error while expanding path list: " + e.getMessage());
      ^
  symbol:   variable InternalMessageSender
  location: class SyslogNgClassLoader
../modules/java/SyslogNgClassLoader.java:129: error: cannot find symbol
        InternalMessageSender.debug("Add path to classpath: " + path);
        ^
  symbol:   variable InternalMessageSender
  location: class SyslogNgClassLoader
  CCLD     examples/amqp_producer
4 errors
Makefile:12044: recipe for target 'modules/java/org/syslog_ng/SyslogNgClassLoader.class' failed
make: *** [modules/java/org/syslog_ng/SyslogNgClassLoader.class] Error 1
make: *** Waiting for unfinished jobs....

Trying to track things down, I noticed a few more things:

• Unlike most (if not all) other modules, modules/java/Makefile.am adds libmod-java.la to module_LTLIBRARIES, instead of modules/java/libmod-java.la. It also doesn't have the mod-java and modules/java shortcut targets, which would have made it a minute faster to arrive to the next problem:

$ make libmod-java.la
  YACC     modules/java/native/java-grammar.c
  CC       modules/java/native/libmod_java_la-java-grammar.lo
  CC       modules/java/native/libmod_java_la-java-plugin.lo
  CC       modules/java/native/libmod_java_la-java-destination.lo
  CC       modules/java/proxies/libmod_java_la-java-destination-proxy.lo
In file included from ../modules/java/proxies/java-destination-proxy.c:26:0:
../modules/java/proxies/java-logmsg-proxy.h:28:24: fatal error: LogMessage.h: No such file or directory
 #include "LogMessage.h"
                        ^
compilation terminated.
Makefile:8082: recipe for target 'modules/java/proxies/libmod_java_la-java-destination-proxy.lo' failed

In short, I had trouble compiling the Java plugin alone, without having to go through the rest. So much so, that I gave up and just disabled java for the time being.

[faxm0dem]

I had that today too, trying to build master

[lbudai]

Hi,

main problem here is not that you mentioned above (however makefile should follow those rules what you suggested).

IMHO the problem is that make has its own dependency management and javac also has such a thing...

We can choose between two solutions:

• refactor makefile and handle dependencies between java files correctly
• using an external java build tool and delegate java building via makefile rules
  (maven, ant, whatever - as we will doing in java modules, such as ElasticSearch, HDFS and Kafka)

For compiling java files within core, I'd choose 1st one (it's not what I really like but I wouldn't add such a build-dependency to the core).

[algernon]

As long as make -j works, I don't care what goes on underneath. I don't mind a dependency on maven/ant/whatever, either, as long as you depend on a version that is in distros. In case of distros, build-deps don't matter for the end user, and for packaging, they aren't a big issue either, as long as the build-deps are already packaged too.

And the java module being optional, if the required tools aren't present, just don't build it. Those who work with java, are likely to have the tools anyway...

[faxm0dem]

👍

[lbudai]

make -j should work with my PR #500

(
Java support is not finished yet: adding a new build deps to syslog-ng is ok for me, but could be a pain for package builders.

If package maintainers will compile and package jar files, it could work.

If not... well in that case we should deliver those jars in an other way. That way could be a central maven repo. If someone just download a pre-built jar file then he/she doesn't need those tools(-> newest gradle which is not part of most of the distros) when compiling syslog-ng: in that case only java support is needed.

If those jar files could be downloaded from a central maven repo, then the user could use a maven which is part of her/his distro...
)

[algernon]

From the Debian PoV, we are required to compile the jar files, we're not going to ship pre-compiled jars. But our tools are sometimes old, and downloading from the network during build is prohibited.

[czanik]

+1
SyslogNg.jar should not come pre-built in the release tgz. It's also a recommendation in openSUSE and a requirement in Fedora to build all jar files during packaging and avoiding pre-built jar files.

[lbudai]

I think algernon's answer is not about SyslogNg.jar but a general approach they follow in Debian packaging. This means that my idea on delivering pre-compiled jar files (not SyslogNG.jar, but ElasticSearchDestination.jar, KafkaDestination.jar, etc..) is not viable.

@algernon : am I right? :-)

(however, including SyslogNG.jar within dist tarball is a bug : this is why I asked you to open a separate issue for that)

[algernon]

Yes, you're right. Debian doesn't care much if jars are included in the source tarball (but it makes things easier if they aren't, mind you). We'll rebuild them whether they're shipped pre-compiled or not.