Using classes from /target - java

I am using JOOQ. JOOQ generates meta classes, using with database requests. It's recommended to generate classes into /target/generated-sources/jooq. But when I try to call these meta classes in code, they are not accessible.
Please, tell me what to do.

This is the default output location because the assumption is that most people are using Maven, and Maven will automatically include that path.
You can generate your classes anywhere you want including your own src directory, or whatever your IDE is defaulting to. For that, use the target configuration. Example from the manual:
<configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-3.14.0.xsd">
<generator>
<target>
<packageName>org.jooq.your.packagename</packageName>
<directory>/path/to/your/dir</directory>
</target>
</generator>
</configuration>

Related

Swagger : Multiple locations for API not being picked up

In my project there are different packages containing Rest APIs
e.g.
com.mypackage.rest
com.mypackage2.rest
com.mypackage3.rest
I want to document all those.
I have a maven project having swagger plugin where in locations I am trying to specify multiple locations for Rest API as following
<locations>
com.mypackage.rest;
com.mypackage2.rest;
com.mypackage3.rest
</locations>
But when I do mvn clean install, it is not generating swagger json file.
PS. If I am using only one location, json file is being generated properly. Also if I try to put it as following, only last package json file is getting generated.
<locations>com</locations>
Need help!
<locations>com.mypackage.rest;com.mypackage2.rest;com.mypackage3.rest</locations> should do the trick, at least it works for me (version 3.1.x)
In the future (not yet released) the syntax will be:
<locations>
<location>com.mypackage.rest</location>
<location>com.mypackage2.rest</location>
<location>com.mypackage3.rest</location>
</locations>
See https://github.com/kongchen/swagger-maven-plugin/issues/328

How to get name of Maven dependency JAR (not full path) as a pom.xml variable

It looks like it is possible to get the path/to/a/dependency.jar as an expandable variable within a Maven pom.xml: see Can I use the path to a Maven dependency as a property? You can expand, e.g., an expression into a string like /home/pascal/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar.
What I want instead of the full path to the dependency JAR within my local Maven repository is just the bare name of the JAR, for example junit-3.8.1.jar.
So for example, within my pom.xml, I would like to be able to use a value like ${maven.dependency.junit.junit.jar.name} to expand to junit-3.8.1.jar.
Can I do this, and how?
You can use the maven-antrun-plugin to get the file name of a dependency. Ant has a <basename> task which extracts the file name from a path. As described in Can I use the path to a Maven dependency as a property? the full path name of a dependency is available in ant as ${maven.dependency.groupid.artifactid.type.path}. This enables us to extract the file name with the ant task like this:
<basename file="${maven.dependency.groupid.artifactid.type.path}" property="dependencyFileName" />
This stores the file name in a property named dependencyFileName.
In order to make this property availbable in the pom, the exportAntProperties configuration option of the maven-antrun-plugin needs to be enabled. This option is only available as of version 1.8 of the plugin.
This example shows the plugin configuration for retrieving the artifact file name of the junit dependency:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<exportAntProperties>true</exportAntProperties>
<tasks>
<basename file="${maven.dependency.junit.junit.jar.path}"
property="junitArtifactFile"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
No, I'm sorry to say that it isn't possible. So, you have two options before you.
1) modify the maven source code and contribute the modification.
2) write your own plug-in.
I recommend the second option. Writing plug-ins is not that hard. As a philosophical principal, select a frequently-used plug-in which has functionality close to what you want to accomplish. Read and understand the code, and then modify it to do what you desire.
So for your example, you might look at the filter plugin. There's also some interesting syntax going on in the Ant plugin. It allows you to name dependencies and get those jar filenames into the embedded Ant script.
Good luck. :-)
As a more practical alternative, you might just break down and manually code the property value with the exact version number you're using. You're not going to switch the version number that often, right? And this is only one jar you're dealing with, right?

Using jaxws-maven-plugin with -clientjar option

I'm using jaxws-maven-plugin to execute wsimport for a web service consumer app. I'm using the -clientjar option on wsimport which was introduced with JAX-WS 2.2.2 RI in 2010. I do this because I want to bundle the WSDL within the jar.
I don't have a problem crafting the pom. For plugin configuration I do something like:
<configuration>
...
<args>
<arg>-clientjar</arg>
<arg>bundled-wsdl.jar</arg>
</args>
</configuration>
When I execute a build my created jar, lets call it myapp.jar, has file bundled-wsdl.jar within it. Inside the bundled-wsdl.jar's META-INF directory I find the wsdl and xsd just as I like them. I'm also quite happy with the generated java code that come as a result of using the -clientjar option. So far so good.
But this stuff should be in myapp.jar's META-INF, right?
The fact that it sits within bundled-wsdl.jar's META-INF doesn't help me a lot.
The funny thing is that I do in fact get a wsdl file in myapp.jar's META-INF which makes the application actually work. How it gets there I don't know. Also the xsd file isn't there, only in bundled-wsdl.jar's META-INF.
The basic question is how to correctly use wsimport -clientjar option in a Maven project ?
Java 1.7.0_45.
The -clientjar option is really poorly documented, IMHO.
Here's how I believe it works:
When the -clientjar <jarfile> option is used three things are happening:
You'll get a <jarfile> generated in the directory pointed to by
the -d argument to the wsimport tool. This will contain within
it both WSDL and any relevant XSD files as well. This little bundle will not be used for anything at all. If you want to make use of it it would be entirely up to you. But before you do see (2) below. I'm not sure what to use this jarfile for other than as a form of documentation.
You'll get a copy of the WSDL put into a file called
META-INF/wsdl/<svcname>.wsdl. The generated classes will use this
file in the no-arg proxy constructor. So this is what will actually
be used if you request a bundled WSDL file with the -clientjar
option.
The generated code will change so that wsdlLocation, if you are using the default no-arg constructor on the #WebServiceClient class, will be that of the bundled WSDL (from (2)), rather than the remote WSDL. Indeed if you use -wsdllocation on your command line together with -clientjar then whatever you specify with -wsdllocation will have no effect as -clientjar will take precedence.
So we must focus on (2) and (3) because that's the only one being actually used ... at least if you use the generated code as-is.
It is interesting to note that the result of (2) is only a WSDL file. This file may have embedded links to XSD files but as far as I can tell such link will never be followed. The reason is that when we say a web service consumer needs the WSDL at runtime it really only needs the WSDL itself, at not the schema. The schema is "hardcoded" into the consumer and there's no way of changing it at runtime. Hence there's no reason to read schema information at runtime. (THIS IS FROM MY UNDERSTANDING)
Second thing to note about the WSDL that's included with (2): It is really just a copy of the original WSDL so it may not have endpoint you want. Actually in most cases it won't. This means that in this situation you'll need to set the endpoint yourself :
// Use no-arg constructor. Means it uses the WSDL bundled into the
// META-INF/wsdl directory rather than trying to retrieve WSDL over the
// network.
service = new HelloSvc_Service();
hello = service.getHelloSvcPort();
// Since we're using a bundled WSDL the web service URL cannot
// be derived from that (it would be wrong!). So we have to set
// it explicitly.
((BindingProvider) hello).getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://myhellowebservice-address");
The documentation for this plugin is a joke. A workaround is to manually extract the contents from the client jar after it is created like follows:
<build>
<plugins>
<plugin>
<!--
Generates JAXWS classes for all of the WSDL files in $[project.base.dir}/src/wsdl.
-->
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<args>
<arg>-clientjar</arg>
<arg>${project.build.directory}/wsimport-client.jar</arg>
</args>
<wsdlUrls>
<wsdlUrl>https://webservice.com/service.wsdl</wsdlUrl>
</wsdlUrls>
</configuration>
</execution>
</executions>
<configuration>
<target>2.1</target>
<verbose>true</verbose>
</configuration>
</plugin>
<plugin>
<!--
Unjar the wsimport-client.jar created in the jaxws-maven-plugin to the WAR's classes folder
-->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>process-resources</phase>
<configuration>
<target>
<unzip src="${project.build.directory}/wsimport-client.jar" dest="${project.build.directory}/classes" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
taken from here: https://gist.github.com/mpellegrini/5439304
I had the same issue, and I had to unzip the created jars and re-zip in one single jar (so, putting the wsdl file from the inner jar in the final jar).
Thanks to peterh comment, I think I understood the "trick": in Maven output I can see a log like
jaxws:wsimport args: [..., -Xnocompile, -clientjar wsdl.jar, ...]
so the wsimport command is launched without compiling che code, and in fact a wsdl.jar is created in the target/classes folder.
I think wsimport is just generating the sources and the jar with the wsdl, then the compilation and the packaging is done in the following steps.

How do I use a template code generator (eg freemarker) in Maven?

How would you structure Freemarker (or an alternative) as a templating code generator into a Maven project? I'm pretty new to Maven and would appreciate some help.
I want to generate some code from templates in my project. [a]
Rather than write my own, googling found freemarker which appears to be used by Spring which is a good enough reference for me, though as I haven't started with it yet, any other suggestions that work well with Maven would be appreciated too.
This website tells me how to add it as a dependency to my pom.xml.
This SO question tells me where the generated sources should go. What I can't work out is how to tie it all together, so I get my generated sources generated from the templates, and then my generated sources used like regular sources for compile, test, jar, javadoc etc. Has anyone else used a template code generator for java within maven and could help?
[a] I know Generics would be the usual solution, and in fact I'm using them, but I have to use templates to cope with the primitive cases, without introducing copy/paste errors. Please trust me on this :-)
I had written a maven plugin for this purpose. It uses the FreeMarker Pre Processor.
Heres the fragment from pom.xml highlighting its usage:
<plugins>
<plugin>
<configuration>
<cfgFile>src/test/resources/freemarker/config.fmpp</cfgFile>
<outputDirectory>target/test/generated-sources/fmpp/</outputDirectory>
<templateDirectory>src/test/resources/fmpp/</templateDirectory>
</configuration>
<groupId>com.googlecode.fmpp-maven-plugin</groupId>
<artifactId>fmpp-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Here the cfgFile is the path where you keep the config file for FMPP. (if you are not using any special data passing in FreeMarker then an empty file will be enough)
templateDirectory is where you keep the FreeMarker templates.
outputDirectory is where you want the output files to be generated.
I am in process of writing a detailed documentation highlighting the plugins usage and will update the project website accordingly.
Here is another plugin for the job:
https://code.google.com/p/maven-replacer-plugin/
From the original description of the problem it sounds like you should consider creating a Maven Archetype (aka Project Template):
http://maven.apache.org/archetype/maven-archetype-plugin/
And it sounds like you might want to add some properties into the equation:
http://maven.apache.org/archetype/maven-archetype-plugin/examples/create-with-property-file.html
Maven Archetype functionality also provides a means of doing substitution using Apache Velocity (near enough the same as Freemarker) ... but I haven't worked that bit out yet.

Custom Maven plugin for encryption

I'm translating an Ant script to Maven 2 and I have this problem: the Ant script use a pretty simple java class to encrypt files this way:
<target name="encrypt">
<java classname="DESEncrypter">
<classpath>
<pathelement path="...classpath for this thing..." />
</classpath>
<arg line="fileToEncrypt.properties fileEncrypted.properties" />
</java>
</target>
This DESEncrypter is a compiled class which source doesn't belong to the project I am converting but is used similarly in other projects. Probably I have to create a maven plugin for this to reuse, but I don't want to do it now. My question is: in which directory do i put the DESEncrypter class and how do i invoke it? Using the exec:java plugin, may be? I don't think the encrypter belong to src, test or resources directories.
Obviously, I don't want to include the encrypter class in the final product, just the encrypted files.
My question is: in which directory do i put the DESEncrypter class and how do i invoke it? Using the exec:java plugin, may be? I don't think the encrypter belong to src, test or resources directories.
A very straightforward solution would be to use the Maven AntRun Plugin. Regarding the location of your encrypter, you could either:
put it in a separate module that you could declare as dependency OF the plugin (see this example)
keep it in the current module, in the source tree, and configure the Maven JAR Plugin to exclude it using excludes.
The third obvious answer (apart from exec:java and antrun) is GMaven, which lets you execute Groovy code either from an external class or inline from your pom. So if you only need a one-liner, embedding it in your pom is a quick and easy way to implement things (otherwise you should use an external script). BTW: if you don't know groovy: it's basically java with some additional syntax sugaring.
Here's a sample configuration (of course you have to replace the artifact and class you use):
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<dependencies>
<dependency>
<groupId>your.library.com</groupId>
<artifactId>your-library</artifactId>
<version>1.2.3</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-classes</phase>
<!-- Or any other phase -->
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source><![CDATA[
import com.encryption.*;
new Encrypter().encrypt(
new File(project.build.outputDirectory,
'fileToEncrypt.properties'),
new File(project.build.outputDirectory,
'encryptedFile.properties')
)
]]></source>
</configuration>
</execution>
</executions>
</plugin>
(By making the encryption artifact a plugin dependency, you keep it out of your deployed dependencies, but this holds true for antrun and exec:java also)
You might want to just use the AntRun plugin, it should let you accomplish anything from Ant with a minimum amount of fuss.
You would need a dependency on the class/jar you were using, but by giving it a scope of test, or provided it won't package it in your final product.

Categories