I am trying to prevent dependency checking in java compiler, I use command line compilation,is there any way to tell javac compiler not to check dependency while compiling a java file ?
... is there any way to tell javac compiler not to check dependencies while compiling a java file ?
The simple answer is No.
Suppose you have some class A that wants to call some method m defined by class B. In order to successfully compile A, the compiler needs to know that B is a real class, that it defines the method m, that it has the expected number and type of arguments, what checked exceptions it throws, and what type of value it returns. Without this information about B, the compiler cannot compile A.
And this propagates to the project level. If a class in project P depends on a class in project Q, the compiler must have that class (at least) in order to compile the class in P.
In short, no such compiler option exists, and it is hard to see how it could be implemented it it did.
If you're two projects are dependent on each other then they are really one project and must be built together. If the relationship is a one-way relationship then you will still need to build the dependent project first and then have the results of the project on the classpath when building the second project.
Most IDEs have capabilities to manage this. In Eclipse you can mark that one project depends on another project and the dependent project's output files will be added to the classpath of the other. Typically all dependencies are built and packaged as jars and those jar files are placed onto the classpath when compiling parent projects.
Building code without having access to the dependencies is very difficult and not recommended. In some cases it can be possible. Eclipse has built their own incremental Java compiler so that they do not have to recompile the entire project each time a single file is modified. You can read more about it here but in order to use such a compiler you will likely have to do a lot of work.
UPDATE to reflect your new edit:
In order to build a common library that common library must not depend on any classes in your platform-specific sections. As Peter Rader has mentioned the typical way of doing that is by using interfaces. For example, your common library can have an EventListener interface which receives events. In your platform specific libraries you can implement that interface and process the events according to the specific platform. Since your common library only depends on the EventListener class and not the specific implementations it does not need those specific classes when it compiles.
If you have dependencies, they will always be checked and give warnings, but your classes will be compiled anyway.
Often frameworks offer an api.jar that contains interfaces and enums.
Related
I have a lib module planned to be used across projects. It will depend on many other modules.
But not all the projects will use functions provided by lib. I'm wondering if a project only depends on b/func B provided by lib, will it pack all the unused modules during project's build?
I understand go's smallest build unit is a pkg. In such case will ext-depency A module and ext-depency N module pack it into my project module binary?
How can I test this?
But not all the projects will use functions provided by lib. I'm wondering if a project only depends on b/func B provided by lib, will it pack all the unused modules during project's build?
No.
I understand go's smallest build unit is a pkg. In such case will ext-depency A module and ext-depency N module pack it into my project module binary?
No idea what you are asking.
How can I test this?
Inspect the generated binary. (No, don't do that).
Honestly, this is a 100% non problem. Nothing to see or worry here. Forget all this. The generated binary contains what is necessary and nothing else. Unused stuff is stripped during linking.
Having hard time to describe this and I bet this is something very simple, but I just can't google sollution.
I am using many modules in my project. For simple argument let's say I have modules A and B.
B depends on A.
When I add dependency to external library (using implementation keyword) in module A to use some of it's code in the module, I cannot access library's code in project B. How can I achieve that? I would like A to be my "base" project with all dependencies in that place rather than having to repeat myself in other modules, that depend on it.
The implementation configuration means the dependencies are internal (implementation specific) for the project and should not be exposed on the compilation classpath of other dependent projects. This helps encapsulate dependencies and speeds up the build as you don't need to recompile dependent projects if you only change internal dependencies.
If you want to expose them, you need to use the api configuration instead, along with the java-library plugin.
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 have a project called 'talktome', with no runtime dependencies.
Also I have project 'talktome-tools', which depends on 'talktome'.
No problems, until I realize that the unit-tests in 'talktome' depends on 'talktome-tools'.
What solutions are there?
If talktome is a general project where other (e.g talktome-tools) depends on, it should not be depend on the more specific projects. Then, it would be wise to get rid of dependency from talktome to talktome-tools.
Otherwise, you would create a more higher level project (e.g parent) and put necessary interfaces, classes that can be used by both talktome and talktome-tools to the new project.
You may move the tests to another maven module like talktome-tests that will do the integration testing. It makes sense especially it seems that talktome shouldn't depend on specific project like talktome-tools.
And, test dependencies like talktome-tools should be included with test scope.
I'm having a problem reconciling building a project for use within an application server and for use as a stand-alone application.
To give an overall simplified context, say I have three Projects A, B, C.
Project A depends on Project B which depends on Project C.
Project C has a dependency X which is marked as provided since it was expected that it would be available as a JEE library within say an application server. i.e. jms.jar.
So if I perform an assembly build of Project A, I get all the transitive dependencies save for those marked as provided as expected.
Now I have a new deployment scenario where Project A needs to be used in a standalone environment i.e. outside an application server.
So now I need the jms jar to be a compile dependency. Does this mean that I should explicitly add a compile dependency for X in Project A? Doesn't this violate the Law of Demeter, i.e. don't talk to strangers, in the sense Project A shouldn't explicitly know about Project C but only about Project B?
This is a simple example but in reality I have multiple dependencies which have been marked as provided but are now need to be compile or runtime dependencies so they end up in the artifact produced by the maven assembly plugin.
Is this a fundamental problem with Maven or am I not using the tools correctly?
Thanks in advance for any guidance.
If you need your build to have variations in it for different scenarios, you need to use profiles and keep certain things (such as some of the dependencies) in the various profiles.
http://maven.apache.org/pom.html#Profiles
Different dependencies for different build profiles in maven
answers a similar question - but you can swap in the "release" and "debug" for "Project A" and "Project C"
Provided dependencies are a difficult subject. First of all: Provided dependencies are not transitive in the following sense: If your project C has a provided dependency on X, then A will not get the dependency. It is silently ignored. This fits with the following meaning of "provided" which I propose:
Only the artifacts that are actually deployed should mark dependencies as "provided". Libraries or other jars that are not individually deployed to a specific server should not have provided dependencies. Instead, they should declare their dependencies as compile dependencies. In your example: Project C should have a compile dependency on X. If project A knows that X is provided, it sets X to provided in "dependencyManagement". As project A should know the environment in which it runs it should decide what is provided and what is not. And "dependenyManagement" is the right place to declare this.
If your project A should be able to run within and without a given server, you probably need to make a lot of adjustments, even change the type from ear to jar. So you either use build profiles for this, which then have different dependencyManagement entries, or you split A into two projects which depend on some other project that contains the common elements.
If some given project C already has a provided dependency on X and you cannot change that, this is effectively the same as a missing dependency in C. This has to be repaired at some point, and this could be project A itself.