Develop Reference

Java Package doesnt not exist in intelliJ IDEA

I am new to Java and i have to execute a code snippet related to Kafka which is given below:
import java.util.*;
import org.apache.kafka.clients.producer.*;
public class Producer {
public static void main(String[] args) throws Exception
{
String topicName = "SimpleProducerTopic";
String key = "Key1";
String value = "Value-1";
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092,localhost:9093");
props.put("key.serializer","org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
Producer<String, String> producer = new KafkaProducer <>(props);
ProducerRecord<String, String> record = new ProducerRecord<>(topicName,key,value);
producer.send(record);
producer.close();
System.out.println("SimpleProducer Completed.");
}
}
I have downloaded IntelliJ Idea editor and running the above script there but it is giving me an error
Error:(2, 1) java: package org.apache.kafka.clients.producer does not
exist
I know that i apache kafka is missing so i downloaded a jar file of apache and add it to modules but the error still persist. What should i do? How do install the pacakge?

Simply adding the jar to the corresponding module does not give you access to it. Have you tried right click on the jar Add as Library... option?
Edit: you could perhaps explore other options for external library usage like maven, or gradle.

As being new to Java, you'll want to understand what is the classpath.
Putting JARs directly into your IDE isn't changing that
Even from the command line, you'd need to explicitly specify -cp kafka-clients.jar
There's multiple ways to modify the module classpath in Intellij, but manually downloading JARs should be avoided, and that problem is solved by dependency management tools such as Maven or Gradle (or sbt, etc)
Your profile mentions other languages, so think Nuget, npm, pip, etc. Apply that knowledge to Java

One way to install the package is to use Maven. If you want to configure Maven and IntelliJ, take a look at this tutorial. Eventually, once you are done, you should add this to the auto-generated pom.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>Whatever you put during setup</groupId>
<artifactId>Whatever you put during setup</artifactId>
<version>1.0-SNAPSHOT</version>
//Add this - copy and paste
<dependencies>
<!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients -->
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>2.1.0</version>
</dependency>
</dependencies>
</project>
You can add any additional packages/dependencies within the <dependencies></dependencies> tags. There are plenty of tutorials online on how to handle dependencies using Maven.

JDK11 Migration: Compilation error shown in Eclipse 2018-12 but code runs fine

While migrating from Oracle JDK 8 to Open JDK 11.0.1 using Eclipse 2018-12 I obviously found another JPMS-related bug making it hard to work with external non-modularized .jar's within a modular java project. I tracked my problem down to the full example below.
The example was derived from the migration process of a real project (using the still non-modularized javax.servlet.api) which caused some headaches. It consists of four maven projects M, N, Y and X making up one java module each, and another maven project that makes up a non-modular java project W. I use maven and the maven-compiler-plugin 3.8.0. My observations are:
Eclipse shows errors in M.java but running class M with default options runs without errors
if I include the artifact w as additional maven dependency in project M, the errors remain
if I rename project Y to project O along with artifact, package name and module-info, no errors are shown
if I remove the requires w in module m, no errors are shown
if I make project W modular by adding a module-info.java, no errors are shown
if I make project W modular by adding Automatic-Module-Name: w in MANIFEST.MF, the error remains
Obviously, re-declaring automated modules like module w in top-level projects seems to cause problems with the built-in Eclipse compiler and does not allow us to work properly with Eclipse (whereas running the project works well). In my opinion, this mismatch is another bug in Eclipse 2018-12 (along with the problems I described in Automatic modules not found in Eclipse 2018-12 when project is opened and Java module not found at runtime even with requires transitive).
My question is: Can someone confirm this as a bug, or is it already known? For us it is a complete show stopper since our project depends on different libraries that are neither modular nor have they the Automatic-Module-Name attribute. And as long the Eclipse bug described in this post exist we are not be able to migrate further to JDK 11.
Sidemark: We don’t want to configure our projects after checking out from SCM to get it running in Eclipse. For us, it was not necessary until now (and that's actually really great when working with Maven and Eclipse, thanks to everyone who made that possible so far!), and I hardly try to avoid to manually configure module paths of our eclipse projects or run configurations.
So, here is the complete and reproducable example:
Project M (modular)
// M.java
package m;
import com.example.n.N;
public class M {
public static void main(String[] args) {
System.out.println("M");
N.main(null);
}
}
// module-info.java
open module m {
requires n;
requires w;
}
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mavenexample2</groupId>
<artifactId>m</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.mavenexample2</groupId>
<artifactId>n</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.mavenexample2</groupId>
<artifactId>y</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
Project N (modular)
// N.java
package com.example.n;
public class N {
public static void main(String[] args) {
System.out.println("N");
}
}
// module-info.java
open module n {
exports com.example.n;
}
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mavenexample2</groupId>
<artifactId>n</artifactId>
<version>0.0.1-SNAPSHOT</version>
</project>
Project Y (modular)
// Y.java
package com.example.y;
public class Y {
public static void main(String[] args) {
System.out.println("Y");
}
}
// module-info.java
open module com.example.y {
exports com.example.y;
requires com.example.x;
}
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mavenexample2</groupId>
<artifactId>y</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.mavenexample2</groupId>
<artifactId>x</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
Project X (modular)
// X.java
package com.example.x;
public class X {
public static void main(String[] args) {
System.out.println("X");
}
}
// module-info.java
open module com.example.x {
exports com.example.x;
requires w;
}
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mavenexample2</groupId>
<artifactId>x</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.mavenexample2</groupId>
<artifactId>w</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
Project W (non-modular)
// W.java
package external;
public class W {
public static void main(String[] args) {
System.out.println("W");
}
}
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mavenexample2</groupId>
<artifactId>w</artifactId>
<version>0.0.1-SNAPSHOT</version>
</project>
Please do a Maven > Update Projects … > all to get everything in sync after defining the projects or changing your module dependencies. Also, please close also the non-modular project M after doing a mvn clean install since otherwise you would get the error described here: Automatic modules not found in Eclipse 2018-12 when project is opened.

Indeed Eclipse had a bug, which surfaced only when compilation was performed in a very specific order.
Background: In the era of JPMS a package has different content
depending on which module is asking. In the example different modules
see different configurations for package com.example: from some
p.o.v. it contains a child package n in other perspectives it
doesn't. For performance sake, each result of such lookup is cached,
which caused the order dependence: which module first looked up
package com.example decided what contributions to the package were
known.
Curiously, the same JPMS that makes split packages illegal, requires a compiler to treat each parent package with multiple contributing modules as a split package, causing a significant increase in implementation complexity.
(Edited:) The bug has been addressed as Eclipse bug 543765, the fix is available since release 2019-03.

How does nexus-staging-maven-plugin use <scm> information?

I have a single Git repository that contains several Maven modules, using Maven inheritance and Maven aggregation. That is, in the root directory, there is a parent POM, that defines some modules, each of which use that root POM as their parent.
<project>
…
<groupId>io.example</groupId>
<artifactId>parent</artifactId>
<version>1.2.3-SNAPSHOT</version>
<packaging>pom</packaging>
…
<scm>
<connection>scm:git:https://bitbucket.org/example/foobar.git</connection>
<developerConnection>scm:git:https://bitbucket.org/example/foobar.git</developerConnection>
<url>https://bitbucket.org/example/foobar</url>
</scm>
…
<modules>
<module>foo</module>
<module>bar</module>
</modules>
…
I recently found out that Maven will append the module path to the <scm><url> value for each module (foo and bar above). For example, the foo submodule would get an SCM URL of https://bitbucket.org/example/foobar/foo.
So should each of my modules redeclare the <scm> section, so that the submodule POMs have the same SCM URL as the parent POM? How does the Nexus Staging Maven Plugin use this SCM information, anyway?
I have also cross-posted this at Sonatype.

Regarding your initial question in the title: It does not use it given the code provided at github. When you search for 'scm' in all .java files you have zero hits. Of course they could do some weird tricks like building the String like "s" + "c" + "m" or it is hidden in some third party dependency or...
Still I think besides an offical answer, this is the best any outsider can tell.

how to properly translate maven to gradle

I'm trying to implement the example here
https://github.com/bytedeco/sample-projects/tree/master/opencv-stitching to my android project.
but I get all kinds of different errors...no luck at all.
I want to first make sure I'm referencing the correct lib. this example uses maven and its pom.xml can be found here. https://github.com/bytedeco/sample-projects/blob/master/opencv-stitching/pom.xml
this is a bit more complicated that what I can translate to gradle. I keep getting errors. Can someone please tell me what I should do to reference the same lib as the example? Thanks a lot!!

Since this project is so small, you try doing gradlew --init. It will convert a maven project to a gradle project if it detects it.
Lets take the pom.xml files:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.bytedeco.javacpp-presets.opencv</groupId>
<artifactId>opencv-stitching</artifactId>
<version>0.11</version>
<dependencies>
<dependency>
<groupId>org.bytedeco.javacpp-presets</groupId>
<artifactId>opencv</artifactId>
<version>2.4.11-0.11</version>
</dependency>
</dependencies>
</project>
This is the same as a basic build.gradle:
group = "org.bytedeco.javacpp-presets.opencv"
version = "0.11"
dependencies {
compile "org.bytedeco.javacpp-presets:opencv:2.4.11-0.11"
}

Can you inherit the version from the parent POM in Maven? [duplicate]

This question already has answers here:
Maven project version inheritance - do I have to specify the parent version?
(11 answers)
Closed 9 years ago.
I have a bunch of projects like:
project1
project2
project3
........
project111
Each project compiled in jar: project-1.1.1.1.jar, ....
Does it possible in parent folder add pom.xml so I can define version 1 time for all projects?

If you omit <version/> it inherits from the parent. However, the <parent/> element must contain a <version/> for the parent, so the version must occur in every single POM, but only once.

You can do this:
parent pom.xml:
<project>
...
<version>${my-project-version}</version>
...
<properties>
<my-project-version>1.1.1</my-project-version>
</properties>
</project>
child pom.xml:
<project>
...
<parent>
<relativePath>../parent/pom.xml</relativePath>
<version>${my-project-version}</version>
</parent>
...
</project>
At least, this works for me.

Using a property and referencing it works... unless you are using the release plugin to do releases in which case it removes "-SNAPSHOT" from the version and automatically replaces all instances with the real version number - which overwrites any replacement variables you've set. You may be better off just setting it in each POM and using the release plugin to tag, increment, and release your project.