I used simplejavamail in my maven project. The program can send out the email if I run it from Intellij IDE. But when I create a jar file, and run it from the jar file, then I got class not found for all the simplejavamail classes. And I open the jar, I find out that they are not included in the jar. But all the other dependency classes are there. Any one have meet this issue before?
parts of my pom.xml
<dependency>
<groupId>org.simplejavamail</groupId>
<artifactId>simple-java-mail</artifactId>
<version>6.4.3</version>
</dependency>
<build>
<finalName>my-project-name</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I'm having the same problem. It appears that the dependencies (Ex. Email, Mailer, EmailBuilder, etc) appear in the org.simplejavamail.api repository. I'll update you if I find a working solution with v6.4.3 but I have a feeling we may need to include additional dependencies.
Edit: To at least patch your problem,
<dependency>
<groupId>org.simplejavamail</groupId>
<artifactId>simple-java-mail</artifactId>
<version>5.5.1</version>
</dependency>
The 5.5.1 version still has the classes in the jar. You can reference this for yourself here:
https://www.javadoc.io/doc/org.simplejavamail/simple-java-mail/5.5.1/index.html
Then click on the different versions to see what classes exist.
I think something went wrong in their builds since v6.
Let me know if this helps!
Related
I'm trying to get a project up and running with Swagger codegen Maven plugin. I have the following plugin in my pom.xml.
<build>
<plugins>
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>3.0.0-rc1</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>${project.basedir}/src/main/resources/openapi.yaml</inputSpec>
<language>spring</language>
<configOptions>
<sourceFolder>src/gen/java/main</sourceFolder>
</configOptions>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
When I run mvn clean compile, I get a bunch of dependency errors. For example, fasterxml and threeten. I'm surprised that the dependencies wouldn't be automatically configured and that everything would work out of the box. Am I doing something wrong or do you really need to manually add the dependencies to pom.xml?
UPDATE
While digging through the code, I noticed there is a generated pom.xml (target/generated-sources/swagger with my config above) that seems to have the dependencies I need. Googling led to an issue thread concerning my problem. Looks like this is potentially a known issue.
The dependency copying worked when I used <language>jaxrs-resteasy</language> but I'm still working on other use cases (the spring I originally had and also jaxrs-jersey).
After years of working with Spring, I'm working on a Java EE 7 application with EJB 3.2 and Maven. One thing I would like is to deploy the EJB Jars separately from the web application so I can develop independently. Including the EJB Jars in the WAR causes the app server to redefine the EJBs in the context of the WAR, which I don't want to happen.
The prescribed method is to have maven create a client jar with this directive:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
</plugin>
I'm excluding any Impls from the Client JAR.
The issue I'm having is that maven isn't installing the client jar during the install phase.
I can install it manually by doing this:
mvn install:install-file -Dfile=foo-1.0-client.jar -DgroupId=com.awesome -DartifactId=foo -Dversion=1.0 -Dpackaging=jar -Dclassifier=client
I fiddled around a lot and came up with this
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<goals>
<goal>ejb</goal>
</goals>
</execution>
<execution>
<id>install</id>
<phase>install</phase>
</execution>
</executions>
</plugin>
</plugins>
However, this isn't proper. This installs the client as a new artifact, not as the same artifact with classifier client. When you include the client in another application, you are supposed to use ejb-client. This looks in your folder that contains the normal artifact, foo-1.0.jar, and looks for something with classifier client.
<dependency>
<groupId>com.awesome</groupId>
<artifactId>foo</artifactId>
<version>${com.awesome.version}</version>
<type>ejb-client</type>
</dependency>
Stumped here, any ideas?
I have a multimodule Maven project with several dependencies. I want to build a fat executable JAR containing them as well as my own compiled classes. I found maven-assembly-plugin to be just what I needed except one nasty problem.
Some of my dependencies are local and distributed with project sources. I use system scope for them. It looks something like this:
<dependency>
<groupId>com.intellij</groupId>
<artifactId>forms_rt</artifactId>
<version>1</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/forms_rt.jar</systemPath>
</dependency>
The problem is that for some reason these libraries aren't unpacked and bundled with the rest of dependencies in result JAR.
I know that usage of system scope is considered bad practice, and in fact I even can find some of them (though quite outdated) in Maven repositories, but anyway it puzzles me how it can be solved with maven-assembly-plugin.
Just in case my plugin configuration looks like this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>repoll.server.Repoll</mainClass>
</manifest>
</archive>
<finalName>${project.build.finalName}-full</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
As I understood I have to write custom descriptor, which e.g. includes and unpacks all JARs from ${project.basedir}/lib directory, but after several unsuccessful attempts I still don't know how to do so.
I've managed to find solution here. It's described in this question.
In short, the whole problem was in usage of system scope. It turned out, that such dependencies are filtered out by default, which I found out by running mvn package with debug output enabled (-X/--debug).
When local repository is defined for these JARs, distributed with project, they are unpacked by maven-assembly-plugin as exepected.
I have some external configuration (XML files) that are installed in Maven. I need to have them on my test classpath but they aren't appearing.
They must stay as XML, I cannot package them inside a Jar - but I am willing to try anything else for this, custom plugin etc.
(Please don't inform me that Maven is only for Jars - that's simply not true (and if you provide a reference refuting that I can assure you it's out-of-date/misinformation).
The dependencies are specified thus:
<dependency>
<groupId>some.group</groupId>
<artifactId>some.artifact</artifactId>
<version>${project.version}</version>
<scope>test</scope>
<type>xml</type>
<classifier>some.classifier</classifier>
</dependency>
These XML artifacts have been created by the build-helper plugin (so there's no 1-2-1 with their project's POM).
My only current hacky solution is to, check for the M2_HOME property and load the files from there (as they're defined as dependencies Maven does pull them down) - but I'm not happy with this.
EDIT: The next best hack is probably to use the maven-dependency-plugin to copy these to the output directory (target/classes). If my config is fine for Jars then this smells like a Maven bug.
EDIT 2: #khmarbaise asked for the build-helper-plugin config:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>target/classes/ddl-seed.xml</file>
<type>xml</type>
<classifier>ddl-seed</classifier>
</artifact>
<!-- ... more definitions -->
This generates the correct maven-metadata-local.xml data for all the XML artifacts.
Unfortunately I can find no way of forcing maven to add the test dependency specified to the test classpath, other than this stinky hack of copying it to a directory on the test classpath.
This seems the quickest way (it's for a test dependency), avoiding any JAR creation.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-test-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.acme.gid</groupId>
<artifactId>com.acme.aid</artifactId>
<version>${project.version}</version>
<classifier>ddl</classifier>
<type>xml</type>
<outputDirectory>${project.build.directory}/test-classes</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
I have a Maven-built web-app that uses JPA 2.0 at the back end. The JPA provider is EclipseLink 2.3.2.
When I build the project (and it deploys runs successfully) it builds the JPA meta-model in the directory
${basedir}/target/generated-sources/annotations/
Yet the IDE doesn't see the classes defined there. Little red dots with an exclamation point everywhere. Yet I can navigate to those files in the Projects window and open the generated source files.
Does this happen to anyone else and does anyone know of a way to fix it?
UPDATE:
As a work-around I have discovered that I can exit NetBeans, delete the NetBeans cache directory, then restart. This forces NetBeans to rebuild the cache and then the classes become visible again. Should I submit a bug to the NetBeans bug tracker? I can't come up with a test case to make it happen, but it does fairly often.
If you go to project properties/sources there is a note about this: you need to generate sources under
${basedir}/target/generated-sources/FOOBAR
where FOOBAR is the name of your plugin.
After reading #jeqo answer, I tested if, by manually renaming:
"${project.build.directory}/generated-sources/annotations" to ".../generated-sources/hibernate-jpamodelgen"
would make a difference to Nebeans (I'm using v8.2 on ubuntu 16.04).
Everything worked like a charm.
I then modified the pom file as follows:
1) removed the "org.hibernate: hibernate.jpamodelgen" dependency.
2) configured the maven-compiler-plugin as follows:
<plugin>
<groupId>>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
These two steps is to make sure that the hibernate-jpamodelgen does
not run on auto-pilot just by adding it in the project dependency
list. Please refer to JPA Static MetaModel Generator doc.
3) added the following plugin with configuration
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</processors>
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>5.2.9.Final</version>
</dependency>
</dependencies>
</plugin>
This config is directly from the Hibernate JPA Static Metamodel Generator documentation page except for the following line:
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
This line simply generates the metamodel in the directory named after the maven plugin name. From this point, I got all Netbeans references working at design time as if the generated classes were in the src directory subtree.
Hope this helps,
J
Sometimes Netbeans has troubles refreshing. Perhaps clean and rebuild the project and restart Netbeans?
Today I did more experiments on this topic because it is so annoying for me as well. Finally I have realized it is only a problem related how NetBeans deal with indexing classes. This is not a problem of the target directory name and not a problem of the project. It is only NetBeans' mistake. So I have created an issue as well hopefully NetBeans Team can bring the final solution soon. You can see my ticket here https://issues.apache.org/jira/browse/NETBEANS-4191
In my environment the NetBeans 11.3 (x64) with openJDK 1.8.0_242-b08 and apache-maven 3.6.3 version is used under Windows 10 (1607).
But until the final solution arrives here is what I did as a workaround solving the symbol not found problem.
I have added a profile section to my pom file:
<profile>
<id>nb-modelgen-fix</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>modelgen-touch-files</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<touch>
<fileset id="model.elements" dir="src/main/java" includes="**/*.java">
<containsregexp expression="(#Entity|#MappedSuperclass|#Embeddable)" casesensitive="yes" />
</fileset>
</touch>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
I am using the following simple solution to generate the metamodel classes in my project:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<annotationProcessors>
<annotationProcessor>
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor
</annotationProcessor>
</annotationProcessors>
<compilerArgs>
<arg>-Aeclipselink.persistenceunits=MY-PU</arg>
</compilerArgs>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
And of course a maven-build-helper adding the generated source folders to the project:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/annotations</source>
<source>${project.build.directory}/generated-sources/wsimport</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
And also I have created a file in the same place where the pom.xml is located called nbactions.xml with the following content (to activate this profile in NetBeans IDE only)
<?xml version="1.0" encoding="UTF-8"?>
<actions>
<action>
<actionName>rebuild</actionName>
<packagings>
<packaging>*</packaging>
</packagings>
<goals>
<goal>clean</goal>
<goal>install</goal>
</goals>
<activatedProfiles>
<activatedProfile>nb-modelgen-fix</activatedProfile>
</activatedProfiles>
</action>
</actions>
What it does? When you execute the "Clean and Build" action in NetBeans IDE it activates a task (implemented easily with maven-antrun-plugin) which just a simple touch on all JPA annotated with #Entity, #MappedSuperClass or #Embeddable theese are the sources for the metamodel generations. I have attached this task to the install phase but it worked as well in other phases as well. It lookes that this way NetBeans wake up and makes for the missing indexes for the metamodel classess.
You can read more on this in my NetBeans' issue ticket.
I hope this can save time for anybody else.
If you are using jaxws then make sure you add a <sourceDestDir> node to the <configuration> section of the jaxws plug-in "artifact" in the appropriate pom. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>dojaxws</goal>
</goals>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
....
</configuration>
</execution>
</executions>
<configuration>
<wsdlDirectory>src/main/resources/com/mystuff/ws</wsdlDirectory>
<bindingDirectory>src/jaxws/binding</bindingDirectory>
<target>2.0</target>
</configuration>
</plugin>
As explained above and as noted by netbeans, you must use the generate-sources path appended with the "plug-in" name. Hopefully the above clears up what "plug-in name" means and how exactly one is supposed to get jaxws to put the generated sources where netbeans need them to be. Clearly the "configuration" section will be different for each plugin... The node <sourceDestDir> is needed for jaxws, other plugins may use something else.
For me it worked after I added <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> to the <properties> of the pom.xml, e.g.:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jakartaee>8.0</jakartaee>
</properties>
But I have no explanation why.