Using MaterialFX in IntelliJ - intellij-idea

I've been trying to use MaterialFX (which is a JavaFX design library (like jFoenix)) in IntelliJ but I didn't succeed to do so. I've added the required dependency:
Also, I've added the requires org.glavo.materialfx.adapter; in module-info.java:
module org.example {
requires javafx.controls;
requires javafx.fxml;
requires com.jfoenix;
requires org.glavo.materialfx.adapter;
opens org.example to javafx.fxml;
exports org.example;
}
Does anyone have an idea how can I use this library because the author didn't really explain well how to do so. I would like to mention that it works perfectly in Scene Builder's latest version so I just wonder why it doesn't do so in IntelliJ.

Use Maven (or Gradle) for dependency management
You are using Maven (at least that is what the screenshot shows in Idea, though it could be Gradle making use of a Maven repository).
You should define the dependency as a maven dependency in your pom.xml (or build.gradle) then reimport the build file into Idea.
You should not manually set library dependencies in Idea.
Idea and Maven will recognize that you have a modular project and, when you have the dependency defined in Maven, they will automatically put the new dependent module on the modulepath for compilation and execution.
The maven artifact can be found by searching the maven repository:
https://search.maven.org/artifact/io.github.palexdev/materialfx/11.13.5/jar
The dependency info is:
<dependency>
<groupId>io.github.palexdev</groupId>
<artifactId>materialfx</artifactId>
<version>11.13.5</version>
</dependency>
The module-info for MaterialsFX requires VirtualizedFX. The VirtualizedFX module also needs to be on your module path. The pom.xml file for MaterialsFX has a includes a dependency on io.github.palexdev:virtualizedfx:11.2.6. So the dependent module will be accessible for your build and runtime automatically via Mavan and Idea's inbuilt integration with the Java Platform Module System.
Require the correct module name
The module name for the library is not org.glavo.materialfx.adapter, it is MaterialFX, so you should use:
requires MaterialFX;
NOT:
requires org.glavo.materialfx.adapter;
I recommend that you spend some time studying tutorials for your build tool and the Java Platform Module System.
Example app
Example was created by running the idea new JavaFX project wizard, then modifying the resultant project.
pom.xml
In addition to having a dependency for the MaterialFX library, you also need to have dependencies for both javafx-controls and javafx-fxml.
MaterialFX requires both of these transitively at build and runtime (even if you don't use fxml in your application).
The MaterialFX pom.xml does not have an explicit dependency configuration for JavaFX, so you need to define those dependencies in your project pom.xml (which you would want to do in any case to ensure that your application is using a specific JavaFX version).
<?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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>material</artifactId>
<version>1.0-SNAPSHOT</version>
<name>material</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>18</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>18</version>
</dependency>
<dependency>
<groupId>io.github.palexdev</groupId>
<artifactId>materialfx</artifactId>
<version>11.13.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.9.0</version>
<configuration>
<source>18</source>
<target>18</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
module-info.java
module com.example.material {
requires MaterialFX;
exports com.example.material;
}
MaterialApplication.java
package com.example.material;
import io.github.palexdev.materialfx.controls.MFXButton;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.stage.Stage;
public class MaterialApplication extends Application {
#Override
public void start(Stage stage) {
stage.setScene(new Scene(new MFXButton("mfx")));
stage.show();
}
public static void main(String[] args) {
launch();
}
}

Related

How to open auto generated file level class

I am working on a project where I have some Kotlin-Java interoperability issue.
What I discovered is that in Kotlin all class level functions are wrapped in an auto generated class which names are the same as fileName+kt. I want this class to be open. What decompiled bytecode shows is:
public final class ExampleAppKt
Is there a way to get rid of the final keyword?
According to kotlinlang (Actually all the information is from there. I recommend to read it for more detailed info):
Kotlin has classes and their members final by default, which makes it inconvenient to use frameworks and libraries such as Spring AOP that require classes to be open. The all-open compiler plugin adapts Kotlin to the requirements of those frameworks and makes classes annotated with a specific annotation and their members open without the explicit open keyword.
You can enable all-open plugin via Gradle:
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-allopen:$kotlin_version"
}
}
apply plugin: "kotlin-allopen"
You can specify the annotation for classes to be compiled as open:
allOpen {
annotation("com.my.Annotation")
// annotations("com.another.Annotation", "com.third.Annotation")
}
If you use Maven, you can configure all-open as following:
<plugin>
<artifactId>kotlin-maven-plugin</artifactId>
<groupId>org.jetbrains.kotlin</groupId>
<version>${kotlin.version}</version>
<configuration>
<compilerPlugins>
<!-- Or "spring" for the Spring support -->
<plugin>all-open</plugin>
</compilerPlugins>
<pluginOptions>
<!-- Each annotation is placed on its own line -->
<option>all-open:annotation=com.my.Annotation</option>
<option>all-open:annotation=com.their.AnotherAnnotation</option>
</pluginOptions>
</configuration>
<dependencies>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-maven-allopen</artifactId>
<version>${kotlin.version}</version>
</dependency>
</dependencies>
</plugin>

CDI error: Ambiguous dependencies trying to inject EntityManager

I'm facing a strange error while trying to deploy my EJB 3.1 application in a JBoss 7.1.1 application server: WELD-001409 Ambiguous dependencies for type [EntityManager] with qualifiers [#Default] at injection point [[parameter 1] of [constructor] #Inject public br.com.sigga.siot.dao.masterdata.impl.ProfileDAOImpl(EntityManager)]. Possible dependencies [[Resource Producer Field [EntityManager] with qualifiers [#Any #Default] declared as [[field] #PersistenceContext #Produces private br.com.sigga.siot.cdi.JPAProducer.entityManager], Resource Producer Field [EntityManager] with qualifiers [#Any #Default] declared as [[field] #PersistenceContext #Produces private br.com.sigga.siot.cdi.JPAProducer.entityManager]]]
As you can see, the "possible dependencies" points twice to the same EntityManager producer: br.com.sigga.siot.cdi.JPAProducer.entityManager. This field is declared as follows:
#PersistenceContext(unitName = "siotMobility")
#Produces
private EntityManager entityManager;
A similar case was related in WELD-001409 Ambiguous dependencies but I cannot change my application server to Glassfish 4.1. :-)
My development environment: Eclipse Luna, Java 7, Maven 3.x (eclipse's embedded version). I have one Maven project (siot-mobility) with 3 modules (siot-mobility-[ear|ejb|web]).
The EAR module's POM declares the following dependencies:
<dependencies>
<dependency>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-web</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-ejb</artifactId>
<version>${project.version}</version>
<type>ejb</type>
</dependency>
</dependencies>
Maven EAR plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<version>6</version>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<modules>
<webModule>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-web</artifactId>
</webModule>
<ejbModule>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-ejb</artifactId>
</ejbModule>
</modules>
</configuration>
</plugin>
Feel free to ask me about any more info that could help you help me. :-) Thanks in advance.
Error found: the EJB module was present twice in the generated EAR, once on the root path of the EAR file and a second time in the WEB-INF/lib folder of the WAR file.
I changed the dependency declaration in the WAR project's POM file from:
<dependency>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-ejb</artifactId>
</dependency>
to:
<dependency>
<groupId>br.com.sigga</groupId>
<artifactId>siot-mobility-ejb</artifactId>
<scope>provided</scope>
</dependency>
This way, the EJB module is not copied to the WEB-INF/lib folder of the WAR file and I have only one EntityManager producer in the generated EAR file.

Deploying a war with a MANIFEST.MF - Dependencies get ignored

I am deploying a war into JBoss 7.x using Arquillian for testing and it has a dependency on Apache Commons Collections. However, it just doesn't seem to pick up the module dependency.
MANIFEST.MF
Dependencies: org.apache.commons.collectionss export
Arquillian Deployment
#Deployment
public static Archive<?> createDeployment() {
WebArchive archive = ShrinkWrap.create(WebArchive.class);
archive
.addPackages(true, "com.example.package")
.addAsResource("META-INF/MANIFEST.MF", "META-INF/MANIFEST.MF")
// * Tried the following two options with no luck
//.AddAsManifestResource("META-INF/MANIFEST.MF", "MANIFEST.MF")
//.AddAsWebInfResource("META-INF/MANIFEST.MF", "META-INF/MANIFEST.MF")
// * If I enable the following, it works fine. getLibrary just picks
// * up the lib through maven.
//.addAsLibraries(
// getLibrary("commons-collections:commons-collections:3.2.1"))
;
return archive;
}
I don't want to use jboss-deployment-structure.xml since it feels like using a sledgehammer to crack a nut.
Any ideas?
In my case I added a MANIFEST.MF within src/test/resources and .addAsManifestResource("MANIFEST.MF") for Arquillian
MANIFEST.MF
Manifest-Version: 1.0
Built-By: me
Build-Jdk: 1.6.0_45
Created-By: Maven Integration for Eclipse
Dependencies: org.infinispan export
Arquillian
#Deployment(testable = false)
public static WebArchive createDeployment() {
MavenDependencyResolver mvnResolver = DependencyResolvers.use(MavenDependencyResolver.class).loadMetadataFromPom("pom.xml").goOffline();
return ShrinkWrap
.create(WebArchive.class, "example.war")
.addPackages(true, Filters.exclude(".*Test.*"), "com/comapany/")
.addAsManifestResource("MANIFEST.MF")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
}
}
As it turned out, I asked this same question again (this time about Jar Files) since I forgot all about this question.
The solution has also since been discovered: (Same as from the other question)
The whole thing turned out to be a lot simpler.
Even with .addAsManifestResource OR .setManifest, the MANIFEST.MF was autogenerated by Maven.
This was resolved with the following section in pom.xml instead of using a custom MANIFEST.MF and using .setManifest("META-INF/MANIFEST.MF"); The MANIFEST.MF is auto-generated and there is no customised copy in the resources folder (to avoid confusion more than anything since it was ignored anyway)
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Dependencies>
org.infinispan,
org.infinispan.infinispan-tree export,
</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>

Maven: Including jar not found in public repository

If I was to use a 3rd party library that was not in the maven public repository, what is the best way to include it as dependency for my project so that when someone else checks out my code it will still be able to build?
i.e.
My Application "A" depends on jar "B" which does not exist in the public repository. I, however, wish to add "B" as a dependency to "A" such that when a person on the other side of the world could check out the code and still be able to build "A"
You can install the project yourself.
Or you can use the system scope like the following:
<dependency>
<groupId>org.group.project</groupId>
<artifactId>Project</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/project-1.0.0.jar</systemPath>
</dependency>
systemPath requires the absolute path of the project. To make it easier, if the jar file is within the repository/project, you can use ${basedir} property, which is bound to the root of the project.
If you have a parent project with a module that is in this situation (requires a dependency not in a repository) you can setup your parent project to use the exec-maven-plugin plugin to auto-install your dependent file. For example, I had to do this with the authorize.net jar file since it is not publicly available.
Parent POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<inherited>false</inherited>
<executions>
<execution>
<id>install-anet</id>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>mvn</executable>
<arguments>
<argument>install:install-file</argument>
<argument>-Dfile=service/lib/anet-java-sdk-1.4.6.jar</argument>
<argument>-DgroupId=net.authorize</argument>
<argument>-DartifactId=anet-java-sdk</argument>
<argument>-Dversion=1.4.6</argument>
<argument>-Dpackaging=jar</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
In the above example, the location of the jar is in the lib folder of the "service" module.
By the time the service module enters the validate phase, the jar will be available in the local repository. Simply reference it in the way you set up the groupid, artifact, etc in the parent pom. For example:
<dependency>
<groupId>net.authorize</groupId>
<artifactId>anet-java-sdk</artifactId>
<version>1.4.6</version>
</dependency>
Using system scope may work but it is not recommended even in the Maven specification.
it is not portable.
from Maven book:
system- The system scope is similar to provided except that you
have to provide an
explicit path to the JAR on the local file system. This is intended to allow compilation
against native objects that may be part of the system libraries. The artifact is assumed
to always be available and is not looked up in a repository. If you declare the scope to
be system, you must also provide the systemPath element. Note that this scope is not
recommended (you should always try to reference dependencies in a public or custom Maven
repository).
The best approach is to install to your local repository or to your enterprise repository to be accessible to all your peers.
this is very easy if you are using a repository manager such as Nexus.
This solution worked for me;
1. Created a local-maven-repo in my project's root directory and copied all my jars in the
2. Executed the following command to generate the necessary pom files and metadata etc for each and every jar that I needed to use;
mvn deploy:deploy-file -DgroupId=<somegroupid> -DartifactId=<someartifact> -Dversion=1.0.0 -Durl=file:./local-maven-repo/ -DrepositoryId=local-maven-repo -DupdateReleaseInfo=true -Dfile=<path to jar file>
This generated a new jar file with a pom file inside the local-maven-repo and I was able to include into my project as a dependency like this;
<dependency>
<groupId>somegroupid</groupId>
<artifactId>someartifact</artifactId>
<version>1.0.0</version>
</dependency>
Then mvn package ensured that my project dependencies are resolved and packaged with my war file.
If you are using groovy/grail tool suite (GGTS) then you can directly import that third party dependency (but be sure you have that third party dependency in your local repository) using below steps :
Go to the Project Explorer and right click on project.
Click on import option.
Expend the maven option and select Install or deploy an
artifact to a maven repository and click next.
Brows and select that third party dependency using Artifact File
option and enter the detail of Group Id, Artifact Id and Version
using POM.xml file and click on finish
Wait some moment and possibly error would have gone for that problem.
Generally speaking, you should first put the 3rd party jar into your local repository. After that you can use it by adding the dependency into pom.xml.
For example.
1.put the jar into your local repository first:
mvn install:install-file -Dfile=<path-to-file>
Note: this command requires maven-install-plugin version 2.5 or later. If not, You can refer to Here
2.use the jar by adding the dependency into you project's pom.xml.
just add this into the pom.xml of your project:
<dependency>
<groupId>${the groupId in the jar's pom.xml}</groupId>
<artifactId>${the artifactId in the jar's pom.xml}</artifactId>
<version>${the version in the jar's pom.xml}</version>
</dependency>
3.you can then package or deploy your project by running mvn package or mvn deploy
The 3rd party jar will also be included in the package.

Maven reuse in poms

In our Maven project, we are trying the following directory structure (with about 80 projects total, only a few are shown so that you get the idea):
myappli (pom)
-- module1 (pom)
--|-- utils (pom)
--|-- ejb (pom)
--|--|-- myappli-module1-a-ejb (jar)
--|--|-- myappli-module1-b-ejb (jar)
--|-- war (pom)
--|-- applet (pom)
...
-- module6 (pom)
--|-- utils (pom)
--|-- ejb (pom)
--|--|-- myappli-module6-c-ejb (jar)
--|-- war (pom)
--|-- applet (pom)
Note: This is a flat structure for Maven, as all non-leaf projects have a packaging value of "pom". (cf BetterBuildsWithMaven book).
We define the dependency versions in "dependencyManagement", in the "myappli" pom. This works fine.
Our problem is with the reuse of the dependencies themselves.
For example, the ejb dependencies are common to all ejb projects (by design).
We don't want to cut'n-paste, and maintain all that with each change!
We were thinking to use some "import notion" for the ejb dependencies, and define our ejb dependencies once at the application level. Our unsuccessful attempts were:
The Maven "parent pom" notion would be fine, but it is already used by the modules, so it is not available for our requirement.
No import facility found in Maven (except for dependencyManagement)
XML entity definition is not recognized. We tried a pom like the following, and got the error
"Reason: Parse error reading POM. Reason: could not resolve entity named 'ejbDependencies'":
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project [
<!ENTITY ejbDependencies SYSTEM "./ejbDependencies.txt">
]>
<project ...
...
&ejbDependencies;
...
Edited : I am trying the solution suggested by Robert, but something is wrong.
When I compile my ejb project, it doesn't find the dependencies themselves. I get an error when compiling (mvn compile), saying the javax.ejb package is missing.
Note: I did run "mvn install" on the dependencies project before.
This is my configuration :
<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.company</groupId>
<artifactId>myproj-maven</artifactId>
<version>3.1-SNAPSHOT</version>
</parent>
<groupId>com.company</groupId>
<artifactId>myproj-maven-ejb</artifactId>
<version>${myproj-version}</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>javax.ejb</groupId>
<artifactId>ejb</artifactId>
</dependency>
<dependency>
<groupId>ojdbc</groupId>
<artifactId>ojdbc</artifactId>
</dependency>
</dependencies>
</project>
---------------------------------
<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.company</groupId>
<artifactId>myproj-identite-ejb</artifactId>
<version>3.1-SNAPSHOT</version>
</parent>
<groupId>com.company</groupId>
<artifactId>myproj-identite-metier</artifactId>
<name>SNR IDENTITE METIER</name>
<version>2.0.1</version>
<packaging>ejb</packaging>
<dependencies>
<dependency>
<groupId>com.company</groupId>
<artifactId>myproj-maven-ejb</artifactId>
<version>${myproj-version}</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
I don't know if it changes something, but we have a hierarchy that relates the two poms.
We have a strict Maven structure, where each directory declares all subdirectories as maven modules, and each subdirectory declares the parent as a maven parent.
And the common parent directory is part of this structure.
+---maven
| \---ejb
+---identite
| +---ejb
| | \---SNR_IDENTITE_METIER
Edited:
The answer given by reef seem correct. It is impossible to do with Maven, because our dependency are provided, and therefore not transitive :-(
We really have many problems with setup up Maven. So many little things just don't work. Today I found out that the site target cannot handle properties, that we are using for version numbers!
You can use pom dependencies to import dependencies into arbitrary projects.
A pom project can look similar to:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernateVersion}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>${hibernateAnnotationsVersion}</version>
</dependency>
</dependencies>
</project>
And is imported as:
<dependency>
<groupId>com.example</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
See Maven, the definitive guide - Grouping Dependencies for details.
Do your imported dependencies have a provided scope?
Indeed this scope is not transitive (see Maven Dependency Scopes).
This could be the reason of the non-replacement.