Make updates object files if one or more of its dependencies is out-of-date.
However, it's really a pain to write down the right dependency tree.
You may simply forget to add a header file to dependencies when you put an extra #include.
What if one of the headers in the dependencies list included another header?
What if ...
So I am looking for automatic method to generate the 'correct' dependency tree for the makefile.
Thanks!
There are various methods. One is described in the GNU make manual.
A better one is the one used by the automake environment, but you don't need to use automake to use it. You can find it described here.
Alternative way were to use CMake. Just look through this tutorial. You just need to specify your sources and add them to the target. CMake will take care of dependencies itself.
Related
I am working on migrating multi module java project into maven. Now for most of them i migrated to maven.
Finally i am aware my project have lot of unnecessary jars included, and i want to clean them up.
I know maven has plugin command, mvn dependency:analyze. Which works very well.
dependency:analyze analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. based on static code analysis.
Now my question is that, how can i remove reported unused and declared dependency for cleanup purpose. It could be possible those jars were getting used at runtime and my code will compile perfectly fine after removing but blow up at runtime.
An example: mycode compile with one of opensource library antisamy.jar but it require batik.jar at runtime. And mvn dependency:analyze reports me to remove batik.jar.
IS my understanding correct or i need expert inputs here.
Your understanding seems to be correct.
But I'm not sure why you'd think that there is a tool that could cover all the bases.
Yes, if you use stuff by reflection, no tool can reliably detect the fact that you depend on this class or the other.
For example consider this snippet:
String myClassName = "com." + "example." + "SomeClass";
Class.forName(myClassName);
I don't think you can build a tool that can crawl through the code and extract all such references.
I'd use a try-and-fail approach instead, which would consist of:
remove all dependencies that dependency:analyze says are superfluous
whenever you find one that was actually used, you just add it back
This could work well because I expect that the number of dependencies that are actually used by reflection to be extremely small.
I am cleaning up dependencies from the build.gradle file for a big-sized Java project. How do I identify the usage of a certain dependency in the code-base ?
The solution that comes to my mind right away would be to remove the dependency and run compile to see if it was needed. You can of course skip checking the ones you are sure that are needed. If there's a lot of suspects you can comment out several at a time and if build fails and you don't know which one is a valid dependency, you can use binary search ;) to speed up the process.
What maven Excluded dependencies was invented for?
Should I care to exclude any dependencies other then for fixing libraries conflicts?
What would good maven project architecture look like:
tend to exclude as much as possible
or as minimum as needed?
I don't know the reasons for the design but I've seen it used in the following cases:
I had a library which had junit as a compile time dependency so JUnit code leaked into my production code.
I had a library which uses log4j. Since I'm using slf4j, I used dependency exclusion to get rid of the hardwired logging framework and used a slf4j-log4j bridge instead so I could ultimately log to logback.
In another case, I was using only some features of a framework and didn't need all the dependencies. Since they weren't optional in the first place, I used exclusions to keep my classpath lean and clean.
General rules:
Use it to get rid of things that break your build
Get rid of things that you're replacing with something else
Get rid of things that you know you don't need (optional)
If none of the rules apply, leave the dependency alone; chances are that the immediate dependency might change over time and suddenly, it will need some dependency that seemed superfluous before and you code will unexpectedly break.
In addition to Aaron's answer:
An exclusion is usually needed when the provider of the dependency did something wrong (i.e. did not make a dependency optional where he should have, included an actual logging backend - as opposed to api - or used the wrong scope).
The one exception is logging frameworks. See Aaron's answer for that.
So no, do only exclude dependencies if you have a specific reason to exclude them.
My project is depending on many ZIP resources.
With "maven-dependency-plugin" and its "unpack-dependencies", I kown how to unpack each dependency.
But (for different reasons I cannot explain here), I have to unpack the dependencies in a specific order (*).
Is it possible to unpack in a specific order, or is it possible to manage the dependencies order ?
Thanks,
Xavier
(*) there are some files with the same names, and I have to overwrite some files from one dependency with other from another dependency ....
[EDIT][SOLUTION]
Thanks for answers.
I found a solution with copy-maven-plugin.
Here is an example of solution for my problem :
https://gist.github.com/4164769
As in most cases with Maven, I think there are several ways to do this, and you'll have to find the most elegant way yourself. I'll give you an idea of how I'd get started.
First, you can use the dependency plugin's unpack mojo to unpack a specific set of artifact; you name the artifacts specifically in the configuration of the execution. It's possible that you can name more than one here and they will be processed in order. However, if that doesn't work, you can always configure as many executions of this mojo as necessary, and then order those executions in your pom itself, which DOES control ordering. Note, you can configure the unpack target on a per execution basis too, which may help you.
Another usefull tool that might apply here is the assembly plugin with a custom assembly descriptor. The assembly, like the unpack mojo discussed above, can be configured to handle specific artifacts, rather than just all of them, and the granularity and ordering of the processing is highly flexible.
Is it possible to run the maven-compiler-plugin in process-sources only for specific packages?
I know the correct way to do this is to extract the needed classes in a extra module but this seems to be a huge overhead for just two classes.
If one wants to know it is needed for the fornax-oaw-m2-plugin