Are there any tools available that allow the cleanup of a ant script?
I especially need to remove unecessary jar files... The Ant script I have to clean has more than 500 entries and has grown uncrontrolled over time.
There's no automated way of cleaning up jar files. You can look at the various include statements in your Java code, but they merely mention classes to include and not the jar themselves. Even if you can determine that a particular class is served by jarA.jar, it could be that jarA.jar is dependent upon jarB.jar.
You can even start removing jar files one at a time to see what breaks your build. That can be somewhat automated, especially if you specify your classpath via fileset instead of each specific jar. However, what if you actually need a jar for runtime, and not for the build?
My suggestion is to use Ant with Ivy. Ivy gives you the same Maven jar dependency capabilities without converting your project to Maven.
Take a look at Ivy and see how it works with Ant. Then, if possible, ask your developers to determine exactly what jars they need and what versions of those jars they need. You will have to help them. You might have to go through the jars in your repository and attempt to figure out what versions of the jars are in your repository.
You don't have to worry about jars that other jars depend upon. Ivy will take care of that for you. What you simply need are the jars that your developers depend upon, and they should know because they're the ones who use the include statements in their programs to specify a particular dependency.
Once you've determined the primary jars (and revisions) you need, you can easily convert your build.xml files to take advantage of Ivy's jar dependency system. Once you've done that, you can remove all the jars from your source repository since Ant with Ivy will download the required ones from the Internet based Maven repository system.
Related
I have a clojure project that depends on a Java library, that does not work, when it gets included in an uberjar. (It needs different XML descriptors using the same filename in different JAR files.)
Everything I find on using Docker with leiningen depends on building and packaging a uberjar. That's also how I built all clojure Docker images so far.
Is there any leiningen plugin out there, that understands to package a Docker image using several jar files like io.fabric8/docker-maven-plugin does?
Whenever packaging (uberjar, war) the big file that is created contains .class files and a directory structure. Where are these XML files supposed to be (class)loaded from? You can experiment with packing manually. After all it (whether uberjar, war or jar) is just a zip file.
When you know exactly the layout you need SBT is flexible enough to insure you can package from the many input jar files. Unfortunately lein plugins will do things like always overwrite duplicates, and you can't control the packaging behaviour. I can't remember exactly the inflexibilities, but I couldn't control how the packaging process went, what decisions were made.
For doing it manually I use a Linux something called Archive Manager, which I found to be much better than what I used when on Windows. Doing it manually may be all you need. The downside of SBT of course being that you have to learn it, which includes a bit of Scala.
It needs different XML descriptors using the same filename in different JAR files.
Just thinking about this, is it that you need to append the contents of each file that is in a different jar into the one file that is in the uberjar? You can try it out. If it works and you need to package up often enough that manually creating and renaming a zip file every time becomes a pain, then I believe that SBT will be your best bet.
I have to package my container with the original jar file and then reference this jar in the classpath when starting the application
The classloader loads classes rather than jars. It is the container's job to unpackage all the things you give it, such as .class files, (uber)jars, wars. Any program that dynamically loads from the classpath is loading either classes or resources (things like .xml files). I suppose a .jar file could be a resource, in which case you would put the jar file in the uberjar. So it is still possible to package it up.
I recently saw a project with quite a few sub-projects, each of them with a build.xml and an ivy.xml.
When building these sub-projects apparently all 3rd-party libraries declared as dependencies are copied to a /lib directory in each of the sub-projects. Coming from Maven this looks really strange.
Is this a limitation of Ant/Ivy not being able to build a classpath from the local ~/.ivy2/cache?
Or is it a lack of Ant/Ivy knowledge at those who created the respective xmls?
Or is there a good reason to do this exactly like this with Ant/Ivy?
Hard to comment without seeing the ANT build files, but your description would suggest that the ivy cachepath task is not being used.
Hopefully the following answers will help explain how ivy configurations (similar to Maven scopes) can be used to manage classpaths exactly like Maven:
Ivy, what is the master configuration and why is it not pulling jvyaml?
How to avoid copying dependencies with Ivy
I'm trying to re-write our build to Gradle, but we want to keep the dependency management in Ivy, for internal reasons.
So while trying to do that, I'm having several questions regarding the way gradle handles its dependencies:
When does gradle resolve dependencies (without Ivy or anything)?
When adding IvySettings and ivy.xml, do I need to call something similar to ant's ivy:resolve or ivy:configure, or does Gradle take care of that? If so, when and how?
Gradle resolves dependencies (more precisely configurations) on first use (typically by a task). Gradle doesn't read ivysettings or ivy.xml. (It does read ivy.xml files in the repository.) All information about dependency resolution is configured in Gradle build script(s).
In regards to (2), I managed to get gradle to read an ivy.xml file, and resolve the dependencies from there.
Gradle doesn't take care of that naturally, but using code from this issue, with a few tweaks, managed to get dependencies with gradle.
further more, there is a IvyXML plugin for gradle, with claims it can take care of most of this stuff.
I am working on an existing application that uses ivy to manage dependencies, and the source comes with ivy.xml and ivysettings.xml files. I am trying to add my own jar to the build. What would be the easiest way to do this?
I tried adding a dependency to ivy.xml and I am not sure how to configure the repository directories. Maybe there are easy ways to do this? Any quick and dirty way will do.
The filesystem resolver in conjunction with the chain resolver should help you, assuming that you can modify the ivysettings.xml that you just inherited.
You can store your jars locally on your machine under your Local Ivy cache or your Shared Ivy cache. I believe it's $HOME/.ivy2/local and $HOME/.ivy2/shared and its in the same format as the $HOME/.ivy2/cache directory. If you use <ivy:publish/> Ant task to push your local jars to your local repository, they'll be accessible to all of your projects.
However, I recommend biting the bullet and doing things ...what's the technical term? oh yeah... The correct way.
Go ahead and setup a project wide Ivy/Maven repository where you can fetch your local jars the same way you fetch your third party jars. This way, there is no difference between your local jars, and the third party jars you're using. No one has to think where a particular Jar is located or adjust their Ivy configuration to get one jar or another.
Download either Nexus or Artifactory. You can set these repositories up so that all the third-party jars and your local jars are available as if they're all stored in the same server. You can even add in other jar repositories that are not centrally located.
I recommend Loughran's book Ant in Action. It has an excellent chapter on using Ivy. You can also look at my ivy.dir to see how I configure Ivy, so it's easily accessible to all of our projects.
What approach has worked well for you combining IVY + msbuild?
Our goal is to integrate IVY into the C#/C++ build process for dependency resolution and publishing. We have tried adding it to custom tasks at the beginning and end of the build and we have tried wrapping the msbuild calls with ant+ apache-ant-dotnet.
Other options might be gradle, buildr, rake.
What do you use?
Thanks
Peter
Most build technologies can use libraries found in a local directory. I'd suggest using the command-line ivy program to populate this, at the start of your build:
java -jar ivy.jar -ivy ivy.xml -settings ivysettings.xml -retrieve "lib/[conf]/[artifact].[ext]"
Your dependencies are listed in a standard ivy file called ivy.xml. The protocol, location and layout of your remote repository is described in ivysettings.xml
The advantage of this approach (as opposed to switching to Gradle, etc) is that you're not trying to replace your existing build tool. Ivy is solely concerned with managing dependencies.
My team has been using Ivy for .NET for a couple of years very successfully. I know several more that give it a vote of confidence.
Use it standalone. Wrap calls into msbuild tasks. No need to use Ant integration.