I'd like to have some tools in my maven project which I can run from inside my IDE (IntelliJ in my case) but which are not packaged with the application. Pretty much just java classes with a main method, similar to the "test" source root but not meant for testing.
Is there any good lightweight method/best practice for achieving this?
An example for such a task would be to reset some test databases, regenerate certain files based on some 3rd party systems etc, so more like scripting tasks having access to the classpath/data model of the module.
Thanks in advance!
For those internal utility programs that I don't plan to distribute, I put them under test (a folder parallel to src) with its own class hierarchy that parallels the one under src. And then in my pom.xml, I just name src as the sourceDirectory. Would this work for your case?
<build>
<sourceDirectory>src</sourceDirectory>
<resources>
<resource>
<directory>src</directory>
<includes>
<include>*.xml</include>
<include>*.properties</include>
</includes>
</resource>
</resources>
...
</build>
P.S. My artifact is a war file. And I use Eclipse not Intellj-idea but for this question I think it does not matter.
Related
TL; DR
Maven's Resources plugin doesn't seem to respect excludes elements in the resource configuration.
Setting
I have a large Java/Dart project where I need to deploy a WAR file that has both my UI and my backend in separate JARs. I want to cut down on the size of the deployed file, and I want to drop certain folders from the WAR. Based on the plugin documentation, I thought I could simply set excludes in my plugin configuration, and it won't copy over the unnecessary folders. However, it seems the Resources plugin is outright ignoring these, despite, the Maven model package including a setExcludes function.
Current Attempts
So far, I've tried two main approaches. My configuration is as follows:
<configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
<resources>
<resource>
<directory>src/main/webapp</directory>
<excludes>
<exclude>web.xml</exclude>
<exclude>appengine-web.xml</exclude>
<exclude>**/web/_el/*</exclude>
<exclude>WEB-INF/pages/frontend/**</exclude>
<exclude>**/_el/js/frontend/**</exclude>
<exclude>**/_el/dart/app/dashboard/lib/**</exclude>
<exclude>**/_el/dart/app/dashboard/.dart_tool/**</exclude>
</excludes>
</resource>
</resources>
</configuration>
I tried to use this config inside the execution element, as well as outside from directly under the plugin element, but both times it was ignored, and everything in the webapp directory was copied over mindlessly.
On a hunch, I did try setting filtering to true, but that just ate up all the memory in my computer, and it didn't even work - what it did process was copied over.
I also tried using the Shade plugin, but gave up on that pretty quickly, as the DontIncludeResourceTransformer only permits suffix-filtering, which is not adequate for my use case.
Question
So what am I doing wrong? Based on the docs, I believe the plugin should respect my excludes list and skip the vast majority of files, but it's evidently not doing that.
You need to use apache **maven war plugin**.
The WAR Plugin is responsible for collecting all artifact dependencies, classes and resources of the web application and packaging them into a web application archive.
It is possible to include or exclude certain files from the WAR file, by using the and configuration parameters. They each take a comma-separated list of Ant file set patterns. You can use wildcards such as ** to indicate multiple directories and * to indicate an optional part of a file or directory name.
Here is an example where we exclude all JAR files from WEB-INF/lib:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.1</version>
<configuration>
<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
https://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html
My pom.xml has <systemPropertyVariables> and <profiles>. Right now if I want to run it as a maven build i am using -DXXX for system property variables and -PXXX for profiles in the goal.
Now I would like to run this as JUnit test in eclipse. I found that system property variables can be given in VMArguments.
Now the problem is how to access this profile. Here is how my profile looks like
<profile>
<id>devqa</id>
<build>
<resources>
<resource>
<directory>src/main/resources/devqa</directory>
</resource>
</resources>
</build>
</profile>
I have a file in the resource location and im accessing it in my test
File testfile = new File(this.getClass().getResource("/config.properties").toURI());
I tried to give this in Active Maven Profiles but it didn't work. How to make this work
Add the resource path src/main/resources/devqa to junit run configuration class path using add projects widget. It may work.
According to the Spring boot documentation, it's possible to define additional command when using a remote shell based on Crash.
Default locations for these commands are classpath*:/commands/,classpath*:/crash/commands/
A property can be used to override the default locations but in the provided example, the custom command is located in resources.
In my opinion, custom commands (at least java commands) shouldn't be located in resources but in src/main/java.
It works fine when defining a custom path in resources but how can I define a custom path in src/main/java? Didn't find a way to do it for now!
If they're under src/main/java, they'll be compiled automatically which is not what you need. My solution was to simulate that directory as a resources folder, which in short translates to:
configure the compiler plugin to ignore that particular folder
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<excludes>
<exclude>crash/commands/*</exclude>
</excludes>
</configuration>
</plugin>
copy the files just like any regular resources in the target directory
<resource>
<directory>src/main/java/crash/commands</directory>
<targetPath>crash/commands</targetPath>
<filtering>false</filtering>
</resource>
Minor update & disclaimer:
As you may already know, there are a couple of closures which are executed on login/logout. At least with v1.3.1, which is what I'm blindly inheriting from spring-boot, it will pick the first login.groovy it finds in the classpath. My project's artifact is packaged in an RPM along with all the other dependencies. Since its name begins with r, it comes after crash.shell-1.3.1.jar which is where the defaults reside, so I had to do the following small hack to make it pick up my own scripts instead of the default ones:
<!-- hack to make CRaSH pick up login.groovy from our jar instead of the default one -->
<finalName>0_${project.artifactId}-${project.version}</finalName>
You can try to put your command at src/main/resources/commands/
I have added a node in my pom.xml:
<properties>
<getdownload-webapp.version>1.5</getdownload-webapp.version>
</properties>
how could I get this 1.5 value in code?
String version = System.getProperty("getdownload-webapp.version"); // output version = null
This code gave me null while running(
ps: there is no settings.xml in this project
So you have a property like this.
<properties>
<getdownload-webapp.version>1.5</getdownload-webapp.version>
</properties>
Create a file as follows in your Maven project.
src/main/resources/project.properties
Or as follows if it is for tests only.
src/test/resources/project.properties
Add this line inside the new file. Please note that you should not prefix with "properties" (e.g. don't write "properties.getdownload-webapp.version").
version=${getdownload-webapp.version}
Note that you can also add flags like this to the file.
debug=false
If not already done, you have to enable Maven filtering for your project. It is the feature that will look for placeholders inside the files of your project to be replaced by values from the pom. In order to proceed, you need add these lines inside the <build> tag of your pom.xml file. This is how to do with src/main:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
...
And here is how to do for src/test:
<build>
<testResources>
<testResource>
<directory>src/test/resources</directory>
<filtering>true</filtering>
</testResource>
</testResources>
...
Finally, in your source code (MyClassName.java), add a block like
Properties props = new Properties();
props.load(MyClassName.class.getClassLoader().getResourceAsStream("project.properties"));
String version = props.getProperty("version");
You can add as many variables as you want to the project.properties file and load each one using this method.
The mechanism chiefly in charge to transfer Maven properties to Java application is provided by the Maven Resource Plugin
The plugin is part of the Maven Super Pom and executed during the process-resources phase of the Jar Default Lifecyle. The only thing you have to do is to active filtering.
This will replace any placeholders, e.g. ${my.property} in any of the files in src/main/resources with the corresponding property from your pom, e.g. <property><my.property>test</my.property></property>
How you make this property then available to your Java application is up to you - reading it from the classpath would work.
I assume you want to get it in the code to check something right? You can use filtering from maven that will inject the value in the source code, similar to the filtering option
http://mojo.codehaus.org/templating-maven-plugin/
String version = project.getProperties().getProperty("getdownload-webapp.version");
Where project is of type MavenProject
Here is the back ground.
I was working on a project which was using ant build. When we use to create a new Class, we use to write the junit test in same class as ant supported it.The Class Name doesn't have 'Test' naming convention. There are more then 800 Junit tests.
Now we need to move to Maven build structure. Problem is that maven only runs junit where the class name has naming convention 'Test'.
How do i run the junit test which are in in src/main/java/* ?
Also, Is there a way where i can pull all methods that has '#Test' annotations?
Please let me know if you need any further info.
Just because you used to do it like that with Ant, doesn't make it right to keep using it now. Now that you've moved to Maven, you must comply with its way of doing things and follow its conventions. One of them is to keep your production code separate from your tests. A mixture does not make sense, as you are in fact littering your code with useless (for clients of your code) methods. While you can keep doing this and find workarounds, this is not the high-standard route to choose.
What you really need to do as a next step is schedule some refactoring time and carry out the following tasks:
Create src/test/java (and respectively -- src/test/resources).
Create a *Test class for each class that contains #Test annotated methods and place them under src/test/java.
Move those methods to the respective new classes.
Move all your resources that are only used by tests to your src/test/resources directory.
You have to change the configuration of the Surefire plugin, which runs the tests. I have not tested it, but you can try this configuration:
<build>
<testSourceDirectory>src/main/java</testSourceDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<configuration>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
I assume since you are using ant, you have a test suite? If so, the easiest way is to change the configuration to use the given test suite:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
<configuration>
<includes>
<include>AllTest.class</include>
</includes>
</configuration>
</plugin>
However, I'm not sure if it will look in the src folder too so you may have to move the test suite to the test directory.
As for pulling all methods that have the #Test annotation (I assume without a suite?) you will have to do that yourself if you aren't following the sure-fire test class naming conventions. It isn't too hard to make your own test runner implementation that searches through all your classes in your class path or a sub-folder and finds all classes that meet your criteria and pass that to Junit to run.
If you are using eclipse, you can still execute it as Junit test.
In fact, if your "test classes" didn't put in the test folder, it means that you do not intend to run them as "test" at the maven build action.