External library load time weaving as library - maven

I have a jar with a main class.
I execute it with command java -jar my.jar
This main jar depends on another.jar (e.g. joda-time.jar).
Now I want to intercept a method of another.jar and say I want to print log.
By the way, I want to use my.jar as usual, I mean I'll call it as always: java -jar my.jar.
I have found a very nice example on github about external library weaving.
This example, intercepts a method of joda time library.
It has an aspect for toString() method of joda time.
However, it uses a unit test to intercept and demonstrate.
I've compiled and packed the given example as my_aspect.jar.
After that, I've moved my_aspect.jar to the execution directory, which contains my.jar, joda-time.jar.
Finally, I've also added aspectjrt.jar, and aspectjweaver.jar to the same directory.
When I call java -jar my.jar, intercepiton doesn't happen.
I think I have to tell the my_aspect.jar something to intercept but I don't know what to say.
Below is the main class of my.jar.
It simply makes a call to intercepted method.
package com.github.example;
import org.joda.time.DateTime;
public class Main {
public static void main(String[] args) {
System.out.println(new DateTime().toString());
}
}

Both aspectjrt.jar and my_aspect.jar need to be on the class path if you use compile time weaving or binary weaving.
For load-time weaving you need to use java -javaagent:/path/to/aspectjweaver.jar -cp my_aspect.jar -jar my.jar. The project you use as a template also does it like that, see here.
If you don't want to use the Java agent and also don't want any AspectJ reference on the Java command line, then your only option is binary weaving for another.jar, creating a new version of it, and then creating an uber JAR (fat JAR), zipping up your whole application including dependencies and AspectJ runtime using a tool like One-JAR (there is also a Maven plugin for it).
Your question is lacking detail, so I cannot answer more precisely.
Update: Because you said you prefer the OneJar solution, you can search for my related posts. The group ID in those posts org.dstovall is outdated, though. That version was out of maintenance long ago, so I switched to the com.jolira fork, using it e.g. like this for AspectJ-enabled applications, of course in combination with AspectJ Maven plugin:
<plugin>
<groupId>com.jolira</groupId>
<artifactId>onejar-maven-plugin</artifactId>
<version>1.4.4</version>
<executions>
<execution>
<goals>
<goal>one-jar</goal>
</goals>
</execution>
</executions>
<configuration>
<onejarVersion>0.96</onejarVersion>
<mainClass>de.scrum_master.app.FooBar</mainClass>
<attachToBuild>true</attachToBuild>
</configuration>
</plugin>

Related

autoweaving AspectJ fails during unit tests in IntelliJ

We have a series of unit tests and they were passing fine prior to me trying to add some aspects for dependency injection and logging duration of methods being called in our rest end points.
In the unit tests prior to the tests failing, we get two odd errors:
[AppClassLoader#14dad5dc] error aspect 'com.lutherconsulting.aphirm.log.DurationLoggingAspect' woven into 'com.lutherconsulting.aphirm.rest.ClientRest' must be defined to the weaver (placed on the aspectpath, or defined in an aop.xml file if using LTW).
and
[AppClassLoader#14dad5dc] error aspect 'com.lutherconsulting.aphirm.log.DurationLoggingAspect' woven into 'com.lutherconsulting.aphirm.log.DurationLoggingAspect' must be defined to the weaver (placed on the aspectpath, or defined in an aop.xml file if using LTW).
We are using the aspectj maven plugin to just let it autoweave the aspects into the web application. The configuration for that from our pom.xml for Maven is below.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.8</version>
<configuration>
<showWeaveInfo>true</showWeaveInfo>
<complianceLevel>1.8</complianceLevel>
<source>1.8</source>
<target>1.8</target>
<Xlint>ignore</Xlint>
<encoding>UTF-8</encoding>
<verbose>true</verbose>
</configuration>
<executions>
<execution>
<goals>
<goal>test-compile</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
The strange thing is that this all works perfectly fine if I build the war file and deploy it to a Tomcat instance, or if I run all of our cucumber feature tests. When I do either of those, The aspect weaves fine and I get data on the duration of the rest methods I annotated logged to a database correctly. If I run a specific test package from intelliJ or try to run all junit tests in intellij, it fails with those two errors
Is this something I'm just missing in Intellij as a run/debug configuration in the way it executes unit tests? I didn't think our structure of our app was different than any normal web app
- src
| - main
| - java
| - packages
| - resources
| - test
| - java
| - packages
| - resources
- pom.xml
I appreciate any ideas on
In the end, what turned out to fix this was to go into the project structure in IntelliJ, on the AspectJ settings there is a check box for Post-Compile Weave Mode. Checking this made sure weaving occurred in Intellij prior to the tests executing.
As far as I understand you are running your tests from IntelliJ using its own runner and not maven.
Therefore you have configured the weaver to be run using maven through the aspectj-maven-plugin. The problem is that your IntelliJ runner is not running maven, hence its weaver plugin is not being run either.
I can come up with an idea and you could run your maven test goal within IntelliJ to run all your tests with the maven configuration, so it will detect aspectj-maven-plugin and run the weaver too. Here you can check how to run maven goals:
https://www.jetbrains.com/idea/help/executing-maven-goal.html
On the other hand, according to this link you have to enable Load Time Weaving in IntelliJ
http://www.aspectprogrammer.org/blogs/adrian/2006/02/a_practical_gui_2.html
Quoting the link it says:
Open the "Run/Debug Configurations" dialog using the drop-down in the
toolbar. Click the "+" icon to create a new configuration and name it
e.g. "tests".
For this project, I've selected "All in package" and search for tests
"In whole project".
Now all you have to do is add the VM startup parameter that brings in
the AspectJ LTW agent:
-javaagent:lib/aspectjweaver.jar
The part after the ":" should be the path to your copy of aspectjweaver.jar. In this case, I've copied the
aspectjweaver.jar from the Spring distribution into the lib directory
of my project (it doesnt' need to be on the project's classpath). You
can use the jar from AspectJ 5 final release too if you want to.
Also, you can check to configure AspectJ facet, check this link to read about it
https://www.jetbrains.com/idea/help/aspectj.html

JAR file not visible in Java Request sampler of Jmeter

I am using JAVA Request sample in Jmeter to do performance testing of my Selenium TestNG script.
I have created JAR file of my selenium project using maven plugin :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
Kept JAR file under Jmeter/lib/ext folder.
Create Java request sample in Jmeter and check JAR files in Java request Class name but JAR file not reflected.
Also added Selenium Java JAR & Selenium standalone JAR files in Jmeter/lib folder.
Please guide me to resolve this issue.
Thanks..
I run into the same problem when i compiled the jar with a newer version of java. JVM is 1.7 (jmeter.JMeter: java.version=1.7.0_75) and jar made with 1.8 for example. Try using your java -version level for compileing the jar.
If you intent to use Java Request Sampler your class should inherit from AbstractJavaSamplerClient class and override runTest method. Something like:
import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
public class Mytest extends AbstractJavaSamplerClient {
#Override
public SampleResult runTest(JavaSamplerContext context) {
//your Selenium code here
return null;
}
If your tests are in JUnit format you can use JUnit Request Sampler instead. Just put your jars under /lib/junit folder of your JMeter installation and JMeter should pick them up. See How to Use JUnit With JMeter guide for comprehensive information on the integration
Are you aware of the WebDriver Sampler which provides Selenium integration almost out of the box?
Remember that you need to restart JMeter after adding or updating any .jar in its classpath or installing a plugin.

Maven dependency:analyze thinks my JDBC JARs are "unused"

I'm using a MySQL connector JAR to make JDBC connections. My understanding is that I just have this JAR in the classpath, and it'll be dynamically loaded when I specify mysql: in the connection string.
I declare this dependency in my POM using <scope>runtime</scope>. When I run mvn dependency:analyze, it reports this artifact as "unused". I guess it can't determine that I'll need it through simple static analysis, fine, but surely that's going to be true of just about any runtime-scoped artifact, right? How can I convince Maven that this artifact really needs to be there?
dependency:tree will list all artifacts that are referenced by your pom files if that is what you are looking for. Otherwise you are likely out of luck. Maven openly declares that their dependency analyzer works at the bytecode level and will falsely report dependencies as unused in some scenarios.
A runtime-scoped dependency may or may not be used, it is impossible to tell with bytecode analysis (in fact, impossible to tell with most analysis I could think of). Maven has to decide to either assume they are used or assume they are unused and they went with the latter figuring the user could figure it out.
There is no option to tell Maven to treat runtime-scoped dependencies as used but you can manually add specific artifacts to the usedDependencies array in the configuration. Maven will simply assume those dependencies are used. You could also write your own dependency analyzer or find a 3rd party dependency analyzer that can handle this scenario.
==Update for comments==
You're right, it is quite new. The issue was fixed in version 2.6 which was released Nov, 25, 2012. It isn't yet in many of the public mirror repositories. You can find it here.
Since it is so new there are no examples of its usage however Maven follows some conventions. I would expect it to be declared as:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<configuration>
<usedDependencies>
<usedDependency>org.foo.bar:baz-tron</usedDependency>
<usedDependency>org.foo:whatsit</usedDependency>
</usedDependencies>
</configuration>
</plugin>
</plugins>
</build>

What is the difference in Maven between dependency and plugin tags in pom.xml?

Created project with Spring, Hibernate & Maven. My question is what is the logic behind plugin versus dependency ?
Both plugins and dependencies are Jar files.
But the difference between them is, most of the work in maven is done using plugins; whereas dependency is just a Jar file which will be added to the classpath while executing the tasks.
For example, you use a compiler-plugin to compile the java files. You can't use compiler-plugin as a dependency since that will only add the plugin to the classpath, and will not trigger any compilation. The Jar files to be added to the classpath while compiling the file, will be specified as a dependency.
Same goes with your scenario. You have to use spring-plugin to execute some spring executables [ I'm not sure what spring-plugins are used for. I'm just taking a guess here ]. But you need dependencies to execute those executables. And Junit is tagged under dependency since it is used by surefire-plugin for executing unit-tests.
So, we can say, plugin is a Jar file which executes the task, and dependency is a Jar which provides the class files to execute the task.
Hope that answers your question!
Maven itself can be described as food processor which has many different units that can be used to accomplish different tasks. Those units are called plugins. For example, to compile your project maven uses maven-compiler-plugin, to run tests - maven-surefire-plugin and so on.
Dependency in terms of maven is a packaged piece of classes that your project depends on. It can be jar, war etc. For example, if you want to be able to write JUnit test, you'll have to use JUnit annotations and classes thus you have to declare that your project depends on JUnit.
Plugins and dependencies are very different things and these are complementary.
What plugins are ?
Plugins perform tasks for a Maven build. These are not packaged in the application.
These are the heart of Maven.
Any task executed by Maven is performed by plugins.
There are two categories of plugins : the build and the reporting plugins :
Build plugins will be executed during the build and they should be configured in the <build/> element from the POM.
Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element from the POM.
According to the maven goal specified in the command line (for example mvn clean, mvn clean package or mvn site) , a specific lifecyle will be used and a specific set of plugins goals will be executed.
There are three built-in build lifecycles: default, clean and site. The default lifecycle handles your project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles the creation of your project's site documentation.
A plugin goal may be bound to a specific phase of a specific lifecyle.
For example the maven-compiler-plugin binds by default the compile goal to the lifecycle phase: compile.
Most of maven plugins (both core plugins and third party plugins) favor convention over configuration. So these generally bound a plugin goal to a specific phase to make their usage simpler.
That is neater and less error prone :
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
</plugin>
than :
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
What dependencies are ?
Dependencies are Maven artifacts/components required for the project.
Concretely most of dependencies are jar (that is libraries) but these may also be other kinds of archives : war, ear, test-jar, ejb-client ... or still POM or BOM.
In a pom.xml, dependencies may be specified at multiple places : the <build><dependencies> part , the dependencies management part or still in a plugin declaration ! Indeed some plugins may need to have some dependencies in the classpath during their execution. That is not common but that may happen.
Here is an example from the documentation that shows that plugin and dependency may work together :
For instance, the Maven Antrun Plugin version 1.2 uses Ant version
1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <dependencies> element like the following:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
...
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
<version>1.7.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
</project>
In Maven, dependencies are referenced in a specific format :
groupId:artifactId:packaging:classifier:version.
The classifier (that is optional) and the packaging (JAR by default) are not commonly specified. So the common format in the dependency declaration is rather : groupId:artifactId:version.
Here is an example of dependency declared in the <build><dependencies> part :
<build>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.14.Final</version>
</dependency>
<dependencies>
</build>
Dependency doesn't have a phase binding as plugins to address the "when" question.
But it has a counterpart : the scope.
Indeed declared dependencies are usable by the application at a specific time according to the scope we defined for these.
The scope is a central concept about how a dependency will be visible for the project.
The default scope is compile. That is the most commonly needed scope (convention over configuration again).
The compile scope means that the dependency is available in all classpaths of a project.
The scope defines in which classpaths the dependency should be added.
For example do we need it at compile and runtime, or only for tests compilation and execution ?
For example we previously defined Hibernate as a compile dependency as we need it everywhere : source compilation, test compilation, runtime and so for....
But we don't want that testing libraries may be packaged in the application or referenced in the source code. So we specify the test scope for them :
<build>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.1.0</version>
<scope>test</scope>
</dependency>
<dependencies>
</build>
One line answer - basic understanding
Plugin is a tool you use at the execution of your maven build
Dependency means kind of any library which you will use in your code
If you're coming from a front-end background like me, and are familiar with Grunt and npm, think of it like this:
First you would run, say, npm install grunt-contrib-copy --save-dev. This is like maven's <dependency></dependency>. It downloads the files needed to execute a build task.
Then you would configure the task in Gruntfile.js
copy: {
main: {
src: 'src/*',
dest: 'dest/',
},
}
This is like maven's <plugin>/<plugin>. You are telling the build tool what to do with the code downloaded by npm/<dependency></dependency>.
Of course this is not an exact analogy, but close enough to help wrap your head around it.
Plug-ins are used for adding functionalities to Maven itself (like adding eclipse support or SpringBoot support to Maven etc.). Dependencies are needed by your source code to pass any Maven phase (compile or test for example). In case of JUnit since the test code is basically part of your code base and you call JUnit specific commands inside test suites and those commands are not provided by Java SDK therefore JUnit must be present at the time Maven is in the test phase and this is handled by mentioning JUnit as a dependency in your pom.xml file.
In simple words:
Plugins are used to add some additonal features to the software/tools(like Maven). Maven will use the added plugins at the time of building when we use the build command.
Dependecies are used to add some addtional code to your source code, so a dependency will make some extra code (like Classes in Java) in the form of library available for your source code.
Maven at its heart is a plugin execution framework -- as per formal and standard compact definition. To make it more clear, the commands you use like maven-install/clean/compile/build etc for creating/executing jars, which we sometimes manually run too. So, the things which you want to run (or configure or execute) you basically put them in dependency tag of mavens pom and the answer so as to who will run these dependencies (required for environment setup) be the plugins.
javac (compiler) dependency.java (dependency)
A plugin is an extension to Maven, something used to produce your artifact (maven-jar-plugin for an example, is used to, you guess it, make a jar out of your compiled classes and resources).
A dependency is a library that is needed by the application you are building, at compile and/or test and/or runtime time.

Providng maven build output as a plugin dependency

I have a custom factory implementation I'd like to provide to wro4j maven plugin through a string parameter. Trouble is the factory is built in the same project as the plugin so the plugin doesn't get passed the output from the build and i get a nice ClassNotFoundException.
I'm aware that there is an annotation I could attach to the wro4j mojo to make it aware of the build output but that would require patching and building wro4j from source which doesn't sound smart. I'm also not keen on creating a whole different artifact just to contain my 5 line factory implementation. It feels like there should be an easier way, so the question is
Is there a way to pass build artifacts to a plugin in the same pom WITHOUT editing the mojo?
Have to guess what the issue is without an actual plugin configuration. But generally, if you need to add dependency (or class) to some of your plugins, you will have to wrap that class into its own artifact, i.e. move it into a separate project.
Fundamentally Maven does plugin dependency resolution before kicking in the rest of build cycle, so your classes may haven't been compiled yet at that point.
Try instructing the wro4j plugin to execute in the process-classes phase instead of the compile phase, when your factory class is compiled (process-classes happens right after compile):
<plugin>
<groupId>ro.isdc.wro4j</groupId>
<artifactId>wro4j-maven-plugin</artifactId>
<version>${wro4j.version}</version>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
<configuration>
<wroManagerFactory>...</wroManagerFactory>
</configuration>
</plugin>

Resources