I want to set the time stamp of the classes and resource in a maven module, just before it's built into the jar.
I guess I can use the maven-antrun-plugin, but I'd like to see if there are better ideas.
Does anyone have an idea?
Let me add more details for the reason I need this capability.
When we build a new version for the product, we also build a patch install which compares all artifacts of previous build to current, and packages only the ones which differ.
Jars (and any zip based archive) might have the same content, but time stamp of classes and resources are part of the metadata, and cause the diff to show jars differ (when in fact, the content is identical). I want to hack the jar packing and set all classes times tamp to be constant (like 1/1/2000 00:00).
I hope this explains my need.
Well, the best solution is to adapt your tool that compute the diff to go have a look deeper in the jar ;)
I am afraid there is no other way than using the a ant file with the touch task to reset the file date. There is no existing plugin that sets the file date.
You could also write your own maven plugin and contribute it to the community but it is probably a bit overkill...
HIH
M.
I just want to share what I decided to do.
I will not touch the maven build, and let it build the jars as before.
What I did is implement a script in my build to compare the jars. The logic of this script is simple:
Check arguments (jars exist)
Extract jars to a temp folder (with a unique name)
Run a diff on both folders
Cleanup
Exit with the relevant exit code (0 if same. 1 if differ)
I hope this is useful.
Related
I've inherited a few maven projects which have added a /dependencies directory to capture Java jar libraries that aren't part of the project war and must be installed by a DevOps into a Tomcat installation.
The libraries in this directory seem to fall into four categories:
"provided" scope libraries,
downstream dependencies of those provided libraries, and
discoverable implementations of api jars
"mystery" libraries, i.e., not available in an external repository, and maybe unsure where they ever came from.
Is there a strategy to get Maven to help manage these dependencies and perhaps fetch them for external install?
There are probably several strategies to choose from.
Number one: leave it as it is. If it works and the build is reproducible (on different environments) that seems one valid solution.
The "mystery" part of the build might not be more of an issue for new people working with it.
I think it is valid to create an own maven module to be delivered to the infrastructure team. This module can contain the jars in the /dependencies folder.
What you would need to do is create a pom.xml and add all dependencies currently in that directory (of course not the transitive ones). The magic ones would need to go in a repository proxy (nexus, artifactory, ...). If you don't have a maven repository yet: you want one! (its easy to setup and it does help a lot!)
I would then use the assembly plugin or some ant task to build the zip do be delivered. So the infrastructure team is able to just unzip / copy the files where they need to be. This step can then even be scripted (so the upload / unzip is done through SSH or something like that).
This is probably only one way to do it. I would assume to resolve the jar's in the /dependencies directory may be a bit of a pain.
The advantage is obviously that you document and simplify the management of those libraries. I would also assume if you update some of them it is easier across branches to merge since there are no binary files around. So it may be worth the effort.
In an effort to speed up my maven build time, I want to run mvn install and not mvn clean install.
If I do this, and a source file was removed (in VCS and I got this change after updating my copy), maven will still pack the old file (since it's still under the target folder).
I'm aware of this thread and others similar, but I'm not satisfied with the end result.
I assumed that maven is "smart" enough to pick up only changes and do a real incremental build, but this behavior breaks this assumption...
Does anyone have an idea on how to enjoy a true incremental build with maven without using the clean life-cycle?
Maven runs through it's lifecycle, running external tools through plugins at various points in the process. You can choose where this process begins, and the recommended starting point is clean. We recommend this because maven knows nothing about your source-code -- it doesn't even know whether it's java or C++ -- and it doesn't have to. It just knows that it should invoke the configured compiler (javac for example) on the configured source directory as soon as it reaches the compile step of the lifecycle.
Your compiler knows about source, so if something is to blame here, blame the compiler. However, most compilers will not delete a compiled artifact just because a source file has been removed, because it doesn't know that this artifact isn't going to be linked (referenced) later -- as far as the compiler is concerned, it's only interested in artifacts relating to source files. This is probably the only tool that looks at your source (except maybe some static code analysis tools and perhaps some documentation tools such as site and javadoc).
Maven will proceed after compilation to run your tests, and if they pass it'll enter into the packaging step. Packaging is again an external tool (jar for example), configured through a plugin. In the case of jars or wars, this takes the contents of the target directory and zips them up into a jar or war according to the configured instructions. Again, there is no part of this that needs to know if a file was removed from the source or not -- in fact, it doesn't even look at the source at this point, so how would it know that a file was removed.
My point is, you're assuming too much of your development environment. It has no way of knowing that a file in a target directory is unneeded, unless you go to great lengths to tell it that this is so. That's why there is a clean step in the first place.
As an aside, clean shouldn't be taking a lot of time. If it is, perhaps you should refactor your project into more modules.
I apologize that this is surely basic maven/war plugin stuff, but I'm totally not a maven user. I just have to hack this one thing into a project that is maven based.
What I need to do is to copy an (essentially arbitrary) directory and files into the root of my war. I need them to appear as resources available via HTTP when the war deploys.
I cannot simply put them in the "right place" in the source tree. This is because the files in question are actually the source files of my project. I realize this is a bit odd, but this is a documentation project, and I need to show the source and the effect all in the same war.
So, in the general case, how would I configure the maven war plugin to copy a given directory, along with it's contents, to the root of my war? (BTW, I have tried to make sense of the documentation of this tool, but it seems to be predicated on so much understanding of maven that it feels like I'll never understand it without learning maven first, and I'm a bit too pressed for time to do that just now!)
Many TIA
Toby.
You could try:
use the copy-resources plugin. Use the plugin to copy your source files under target prior to when the war is packaged.
or, configure the maven-war-plugin to include additional resources.
Thanks Drew, that got me where I needed to go. Bottom line, I added the sample pom fragment from the link you gave for copy-resources to my pom.xml with the following changes:
<outputDirectory>target/${project.name}-${project.version}/sources ...
<directory>src/main/java ...
I copied this from the link you gave, then edited the element to point at src/main/java, which picked up my files, and the outputDirectory to the aggregate target/${project.name}-${project.version}/sources . I found that ${project.name} mapped to the project, and the version came from ${project.version}, which seemed to resolve the last little bits of issue.
Thanks again.
Toby
We are using maven for building the project. It's legacy and huge one.
We newly added few .keystore files to it's resources folder.
The problem is, once the build is done, the .keystore files are getting tampered [may be maven is trying to replace/search for some placeholders]. Since it's legacy one, the project structure is so much messed up and we don't have separate distributions or no other choice but to go with plain build.
What I want is, tell maven to copy these sort of files without touching them and keeping the build as usual like before.
Between, there's no explicit is mentioned in pom.xml, tried to doing with that as per this http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html but it's messing up the project build.
I don't want to tamper the build, since it's legacy and huge one. We are using Ant plugin
Just switch off filtering for the respective <resource/> or add an <exclude/> for it.
After going through lot of sources, Found the solution http://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html
Thanks :)
I am completely new to Maven and come from an ant world. I am having lots of trouble something that might be really trivial.
I want to have a maven project that is made out of non-code items that I want to ship along my jars. These items are DDL scripts, installer scripts a couple of utility scripts, readmes etc.
I do not want to use "resources" in the corresponding java projects since I do not want them living in the actual product jars. I want them shipped as separate artifacts that just like any other jar.
It is acceptable to bundle them up in a jar or zip, etc.
Is there a way to do this?
Thanks!
Use the build helper plug-in to add additional artifacts to the Maven module.
Check out the answer to the following question
Ok, I found it and it was pretty simple. Just created a project added a simple pom with no plugin pacakging jar and I create the proper dir structure
src/main/resources/...
This builds it into a jar