I'm working on very old system, we have ant 1.5.3 running and we need to add unit tests to the environment. As far as i have researched, there is no available ant-junit 1.5.3 jar version. did it had a different name before ant-junit-1.7.0? My application says that JUnitTask is not available when compiling. (because ant and ant-junit.jar should be of same version)
for Ant 1.5.x the classes for optional tasks, such as <junit> were contained in optional.jar, in the following directory: org/apache/tools/ant/taskdefs/optional/junit to be precise.
from Ant 1.6.x onwards, optional.jar was split into multiple jars, one of them being ant-junit-1.6.*.jar.
so, i doubt ant-junit-1.5.3.jar ever existed.
read delegating-classloader-1.6, for more of this.
Related
I am in a bit of a jam.
I am working on upgrading our software to have Kettle 6.1. Specifically, we need the feature of S3FileOutput. Meanwhile, our application was already using the aws-sdk for other things.
So I am running into a problem: Pentaho Kettle requires version 1.0.something of aws-sdk. Our application, on the otherhand needs 1.9.6 of the aws-sdk.
To give more details, the feature of Kettle we require is in the pentaho-big-data-legacy plugin. Even if I upgrade to the latest version of Kettle, pentaho-big-data-legacy still uses the old version of the aws-sdk.
I've read a bit about plugins having special classloaders, so one option I was considering is that maybe I am not downloading the right dependency. However, when I tried downloading pentaho-big-data-plugin instead of pentaho-big-data-legacy, I got weird errors, so I stopped going down this path.
I was wondering if there is any way I could put the Kettle Libs in one folder, and my application libs in another folder, and then set some sort of a PENTAHO environment variable to pick up the libraries from the alternative folder.
Another option is if I could somehow set the pentaho classloader, but I don't know if this is possible.
What are my options for having 2 versions of the aws-sdk in my application, with regards to Kettle?
Maven can do much more than download dependencies.
The Maven Shade plugin can help with your current predicament. During a build, it can rename packages.
You would make a project that builds a "fat jar" (or "uber jar") with Pentaho Kettle and its version of the aws-sdk re-packaged as appropriate. That dependency would be handled before your project is built, so you are free to use whatever version of aws-sdk you like since there is no longer a conflict on package names.
We wrote a javaagent to help developers debugging. But, before releasing this tool, we still have some questions about the deployment of java-agent.
User may use the agent with some tomcat applications. The agent uses Premain method to transform classes. We use javassist 3.18.2-GA to insert codes. We currently add javassist.jar into Boot-Class-Path in MANIFEST.MF. And We put both the agent and javassist.jar into tomcat's lib directory.
The questions are:
Well, as least, it works. But is that the correct way to deploy agents and dependencies for tomcat applications?
Because most tomcat applications using hibernate which also using javassist 3.18.2-GA, so it's ok right now. But as my understanding, 3.20 is not completely compatible with 3.18.2. Suggest someone had update the javassist to a higher version, will the agent or the application crash due to the conflict between the 2 different javassist's.
A javaagent is added and run on the VM's class path. Therefore, you have the following options:
Add the dependencies to the classpath when starting up the VM such as you would when deploying a normal application. For an application container like Tomcat, this would be the appropriate directory for such dependencies.
Bundle the dependencies with the agent using a tool like fatjar. Doing so, you can also use the Maven Shade plugin to transfer dependencies into a different namespace to avoid version conflicts.
Use the Instrumentation API to manually append the dependencies before running your actual agent application.
I was looking for examples on how to create an XML File in ANT for Java project using Apache POI library. I encountered this statement:
POI 3.5 and later requires the JDK version 1.5 or later. Versions prior to 3.5 require JDK 1.4+ here
I am using Apache 3.9 and set the JDK of my project to Java 1.4 and I didn't encounter any error when trying to run my program via eclipse. But my question is if I make build.xml in ANT and deploy the JAR file. Will my project still run(3)?
Extra info
I created a build.xml using the ANT plugin in eclipse then Run as --> Ant Build. I didn't encounter any error.
Also set the JRE to JDK1.4
I haven't tested this yet if it runs or not because I still don't know how to add a JAR configuration in build.xml... I am still learning how to use ANT.
If the project states that JDK 1.5 or higher is required it means that usually no testing is done with lower versions. It might still work (to some degree) as you found out, but likely will stop working with newer version of Apache POI.
I have a large Ivy project, and Ive noticed that my code, which run well in eclipse, cause a compile error when run in ant. I've narrowed the problem down to the following line :
FileUtils.write(...).
This line fails - during compilation --- the method is simply not found. Obviously, my code is dependant on apache's commons-io library. And its quite clear that the current commons-io has this method.
http://commons.apache.org/io/apidocs/org/apache/commons/io/FileUtils.html
So what gives ?
I am pretty sure this is related to my ivy.xml -> the eclipse compiler is luckily (or smartly) using the newest possible version of commons-io , whereas my ivy.xml is using an older version which lacks this method.
Most important of all to not here is that ant is clearly using a different version of this jar.
So - my question is :
1) How can I tell ant / ivy to preferentially compile my code with the latest versions of libraries i specify ? I'm assuming that some of the dependencies in my lib/ may depend on older versions of commons-io .....
Also :
2) In this context, any hints about what to worry about regarding the how the classloader deals with duplicates in a multi-jar-dependent project would also be helpful to me ...
Dependency Reporting
I would suggest that you first add the generation of an ivy dependency report into your build, using the report task.
An example of this task is included in the following answer:
What is the Ivy equivalent of Maven's versions:display-dependency-updates?
This will tell you what versions of what jars are being used. Normally, ivy will use the version you specify in the ivy.xml file, however, another module might depend on a more recent version. Ivy's default behaviour is to always favour the most recent version of a Maven module.
Retrieve the latest dependency
If you want ivy to always prefer the latest version of a particular library then declare the dependency as follows:
<dependency org="commons-io" name="commons-io" rev="latest.release"/>
Ivy has a feature called Fixed and Dynamic Revisions.
You can set the version/revision of any artifact to latest-status like
rev="latest.integration" --> for development released
rev="latest.release" --> for released versions
Ivy takes the version with the highest version(you have specified) and omits all libraries with lower versions, so that you only have one lib in the ivy classpath (have a look at the resolution report, run ant -v (verbose mode))., which avoids having duplicate jars with conflicting versions.
This might be worth checking out, maybe you just have an old version defined in one of your ivy files.
As to the second point:
The classloader takes the class, that happens to be first in the classpath(or the jar that is first in the classpath). So mixed versions of the same lib, could behave differently on any system, depending on how the classpath is constructed.
My main project is using java 1.6 and I need to provide an client jar to an system that can only run on java 1.5. The client jar is an separate module so I am able to specify the java version in the maven-compiler-plugin. However, the client jar is dependent on an core jar, which is on 1.6. One way to
I have used "test-jar" goal in maven-jar-plugin to generate an test jar for other module to use. I am hoping to do something similar and use it in my client module with the following dependency:
<dependency>
<groupId>org.mygroup</groupId>
<artifactId>module-core</artifactId>
<classifier>java1_5</classifier>
</dependency>
Why do your client projects depends on core?
If it uses the code from the core, you apparently need to compile core JAR for 1.5 as well. You have several options here:
Set the the target globally to 1.5 and make sure you are not using 1.6 JDK stuff in your code (at least, in the part of the code invoked by the client on JDK 1.5).
Use the profiles + classifiers to generate artifacts for different JDKs (see this question). You have to run the built multiple times, though. Actually, each build will compile everything using the same -target version, so this approach is only a little improvement of 1), allowing you to publish your artifact for multiple JDK versions.
If client code actually does not use core (for example, it uses only WSDLs from the core or some other non-Java stuff), you can remove this dependency by moving stuff to separate "shared" module.