Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
Related
When writing a contract for an API i found myself repeating the same things over and over. For example regex validations for complex json object need to be copy pasted.
Thats tedious and not very DRY.
I'm using Kotlin DSL and Maven
I tried to extract the common parts in another file to reuse it. (Kotlin extension functions ftw.)
After trying multiple things to reuse that file I gave up.
The common parts should be as close to the actual contracts as possible. I don't want to export them in another project, and build them seperat, as they are an vital part of the contracts.
I tried it the following ways:
just put the file in the same directory and importing the functions, hoping it would be resolved as it would in java - did not work at all (my expectations were low, was worth a shot)
putting it in another maven module, and add that as dependency to the spring-cloud-contract-maven-plugin. that worked, as long as the dependant module was built and installed in the local maven repo. if no built version was available maven could not resolve it.
experimenting with kotlin script #file:Import() and #file:DependOn to tackle my issue, no luck.
Is there another way, that I missed? Is there a prefered way doing this?
This must be a common issue, right?
I don't really understand what the point of having a package is. Every Class is kept in a different file, so what's the point of using different packages in a single project?
An Eclipse project has nothing to do with Java. It is a feature of Eclipse to organize and configure your different projects.
A Java package is a language feature of Java. You can use them to structure your project and control visibility between different classes. This becomes necessary even in relatively small projects, which already might have a few hundred classes. I suggest you look for a basic tutorial on what a Java package is and what it can do. To give you a headstart, here is what the official documentation has to say about the purpose of bundling related classes in a package:
You should bundle these classes and the interface in a package for several reasons, including the following:
You and other programmers can easily determine that these types are related.
You and other programmers know where to find types that can provide graphics-related functions.
The names of your types won't conflict with the type names in other packages because the package creates a new namespace.
You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package.
Packages are useful for many things. For example, you could store a set of files that do a given task TASK in a package named task.
Packages are a way for developers to find easily and quickly a file, knowing what the role of the file is.
Whenever your project starts growing, packages are essential.
See this lesson for basic understanding of packages utility.
I was reading about code-injection at run-time and there are many tools/APIs available like Javassist, GluonJ and AspectJ which provide features to inject code. However, I did not understand purpose for injecting code at run-time while we can do override behaviors by sub-classing in Java. With Javassist and GluonJ, I can create classes at run-time but why does anyone do that, in the first place? Can anyone please help me to understand the difference and purpose of code injection ?
Code injection is usually used into application that are used to modify/check/trace other software. In Java we usually reffer to this kind of library as Bytecode modification libraries so if you look on the internet you will probably find more information under this name.
Here I listed a couple of examples of big and famous projects that I now are using Bytecode modification into their cores:
Evosuite: this project takes an application in input and generates unit test for it. Code injection is used to explore the desired project and dependencies and traceability
JaCoCO: this project is a tool for Java project. It is supposed to be attached to your application and once you run your JUnit tests it is going to generate a report on the coverage achieved. Obviously here code injection is necessary to trace every method call made during test execution.
I would like to write JUnit test for my Eclipse RCP while I continue developing the code. When starting the application the different plugins initialize variables of various plugins/classes (mostly within their start methods) which are needed for the correct functionality.
If this initialization doesn't happen, it is impossible to test code because it depends on those values.
How do I solve this issue without creating a lot of dummy values?
What is the general approach to testing Eclipse RCPs?
You're facing a common problem: Too many dependencies. You need to cut them.
With Eclipse 3, this is going to be somewhat hard. Try to split the code into things that depend on the Eclipse platform running and everything else. Eclipse often uses interfaces, so you can test many things using mocks.
With e4, things got more simple since many services will be injected, making mocking and testing even easier.
But the goal must always be to have as much code as possible that doesn't depend on SWT or the platform. Create your own interfaces if you have to. The runtime imlementations just wrap Eclipse code. For tests, you can use mocks to simulate the Eclipse runtime.
You can run tests using JUnit plugintest, that will start up the plugin framework and will allow for testing of plugins. But this usually only solves some of the issues. The best suggestion is as Aaron suggests to separate functionality as much as possible to the point where all your actual code are just plain old java objects that you can test normally. All dependencies to Eclipse are in different classes and are kept as thin as possible so that they dont require testing.
This can be difficult to achieve, so mocking may be required. Another trick I've resorted to at times is to use Java reflection to change values of private fields, see this question
I am working on a project using GWT and Maven that I am including internationalization in. It seems to me that it takes longer to build and run the i18n generated files than it does to add new strings into my Constants interface manually.
My question is: Is it required that I include the i18n goal in the POM? Or is it just a tool intended to make it easier to create a Constants interface from a pre-existing properties file? I am new to Maven and believe the goal is just a tool, but am unable to confirm based on my research that it is not needed. Thanks for any help you can give.
Nope, not required - as you say, it is just there to make it easier. The same is true of the gwt:generateAsync goal, which builds the Async RPC interfaces for you, based on the RemoteService subtypes you've already defined.
I don't use either one - I prefer to build my own, and document where needed (or not). My poms include just a gwt:test for any unit tests I've devised, and a gwt:compile to actually compile to JavaScript.
Keep in mind that a significant percentage of GWT developers do not use Maven, and Constants/Messages and RPC still works just fine for them without these goals.
If you ask me, you should not use the i18n goal in your POM. It should only be used once in a while to synchronize your code (interface) with a properties file. On a day-to-day basis, you should rather work with your interfaces for the canonical locale and manually update the properties files for the translations.
There are way too much things you can do with a Constants or Messages interface that cannot be inferred from a properties file: non-string constants, plurals in messages, etc.