I've started working with jHipster on a recent project which is a tool you can use to autogenerate the full stack of a REST api application using a Spring Boot back end. Which should save a great deal of time writing boilerplate code...
Unfortunately, at my work we have coding standards to adhere to in the form of a set of CheckStyle rules. Any code that does not adhere to these rules causes the build to fail. What I am experiencing at the moment is that this autogenerated code is failing the CheckStyle rules in a large number of places. Currently I am handling this by manually trawling through the code fixing each of the issues.
I can't help feeling in the back of my mind there must be a better way of doing this e.g.:
Configuring the IDE (intelliJ) to ensure the generated code matches the CheckStyle rules. This is certainly possible when coding directly into the IDE.
Configuring jHipster to be aware of the CheckStyle rules before autogenerating the code.
Running a script afterwards which can automatically fix any CheckStyle failures. (I'm sure this must be doable!)
It would be good to hear if anyone knows what the best way to address this issue might be and if anyone has done something similar in the past.
Suppress violations on all auto-generated files as it is out of your control.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter
If you have auto-generated code inside a file with non-generated code that you maintain manually, use comment suppressions.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionCommentFilter
You shouldn't be styling code you don't write for this exact purpose, you aren't writing it and some utility is and it wasn't built to your style specifications. If you generate the files again, it will undo any manual changes you made.
I'm creating some rules to SonarQube where it will analyze a Android Project and raise some Security vulnerabilityes points on code.
I've already created a custom rule by Sonar Tutorial to create my own rules following the same structure, but I had some complications. For instance, when I tryed to run the test classes, I've found some problems to identify Android Classes and validate my rule, and after some research, I solved the problem, but seems like when I put my plugin on SonarQube and run it, the problem remains with the tool not identifying Android Classes (I coudn't comprove this because coudn't find a way to debug the web tool and see why the Rule is not checking).
By this, I need to know if I'm really doing this of the right way. Analyze with custom rules a Android Project directly by SonarQube can be done just following the Sonar Tutorial? Do I need of custom configurations inside my template or any other step to do it?
If beyond the answer or the instruction, someone could provide some documentation to help me, I would be deeply grateful.
Since now, thanks for your attention!
How can I skip scalac compile errors like one can with Java?
This causes the compiler to skip the erroneous file, compiling the rest, and leave the crash to run-time.
I use SBT but since it uses scalac, I think it would be a command line parameter for scalac that passes through from SBT.
Update:
My goal is to run the program, and have it fail at run-time when the error is reached.
For example, there can be a main GUI that has no errors with a button to start a server that does.
In Java the GUI will run and fail during run-time when the button to start server is clicked.
In Scala the program won't even run because the GUI file could not compile before the server file does.
Your request is against Scala's principles (don't do it, please)
This should not be possible in Scala, because it is against one of the design principles in Scala: When a program compiles, there won't be runtime errors. Of course this principle doesn't hold in all extreme cases. But people are working hard to cover all the common cases.
If the Scala compiler would provide what you are requesting, I would consider it a bug in the compiler.
How to make it work (if you still want to do it)
Of course, no one is hindering you to run programs with compile errors. It is possible up to a certain degree.
Split your program into several modules (e.g. one core and several plugins)
Compile the parts independently. When there is an error in one of the modules, Scala will not compile it)
Copy the results (where Scala produced some) together
Run the result
You could some kind of dependency injection (e.g. Guice) or some plugin infrastructure (e.g. Apache Felix) to handle the plugins better.
A personal anecdote (why you should not do it)
For one customer my team and I developed a custom programming language, complete with a runtime and an IDE (based on Eclipse xText). In an early version we had a compiler that would compile files with syntax errors. It just added additional tokens (closing brackets, keywords, missing strings or numbers) when needed until the syntax was OK again. Such a tool is very useful for syntax highlighting and completion in files that have compile errors (e.g. because the file is currently work in progress and some parts are missing). But when you run what that compiler produces, the results are hilarious at best and disastrous at worst. We quickly changed the compiler, so it will not emit runable code any more when there are any errors in the source code.
Sorry if this question is kind of vague. Let me know if I can provide any additional relevant details.
Basically, every so often (at least once every few weeks), when I open my Eclipse workspace I am greeted with a large number of errors. It often says that almost every single one of my projects have errors even though they were working just the day before. I understand that something is getting messed up in the build-path because it gives me errors such as The type java.lang.Object cannot be resolved. However, I don't understand why restarting Eclipse would cause this build-path to get messed up. It also seems fairly common for me to get errors on imports for various Android classes even though I have included the Android SDK in the project.
I guess what I am asking is twofold:
1) Why is this happening and is there anything that I can do to stop this from happening?
2) When this does happen, is there an easy way that I can resolve it? I know that I can go into the Preferences for an individual project and add libraries to the build-path but I can't figure out how to easily do this for all of my projects at once, and I feel like I'm just trying things until they work, so it would be good to have a more defined procedure for dealing with these sorts of problems.
EDIT:
Does anyone have any ideas?
You might need a valid JRE or JDK defined in the Java Build Path of your project.
This question is related to, but not a duplicate of, this question.
My issue is slightly different; I have a "utility module", shared between the client and server code, and it contains no GWT-specific code.
I understand that normally, all the sources are pulled into one specific project, where everything is compiled together. But there is one issue with that: I only get to know if my utility project is "GWT compatible", when I compile the main project. This is way too late; I haven't even got around to start on the main project, but I want to know before I make a "commit" to my SCM, that my utility project is "GWT compatible".
In other words, I want to validate the utility project for GWT compatibility, independently from it's use in a separate project (module).
There's a large part of the JRE that is not covered by GWT, and it is particularly likely in a utility module that non-GWT-compatible classes or method be used. That is what I want to validate against.
EDIT: I could add a "dummy entry point", I suppose, but that makes the project depend on GWT, which I don't want to, since it is "general" code, also to be used by people that don't use GWT. If it matters, I use Maven as build system.
EDIT2: No matter what I do, I will only get real compilation/validation with an entry point (does NOT need to reference any of the classes). Neither <force>true</force>, nor <failOnError>true</failOnError> will do. Is there a way I can define that entry point, for the shared project, such that only gwt-maven-plugin sees it, but not javac (so as not to add an unneeded dependency in the Java code)?
The compiler actually always visits all code on the source path (note: not quite the same as the classpath), by starting at the requested module with any <source> tags, and then checking each <inherits> along the way. If it finds something that isn't compatible or isn't compilable, it will mark it as broken, and move on - as long as nothing actually depends on it (i.e. an EntryPoint, or something that an EntryPoint depends on) you'll just see this message:
Validating newly compiled units
Ignored 1 unit with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
If you include that -strict flag, the compile will actually fail when it hits something that can't be included correctly.
This work is done in the very early stages of the compile, while constructing the TypeOracle, which is used for Generators, long before any JS is built. That type oracle is passed to generators, which need to be able to ask questions like 'what interfaces on the sourcepath have a JSO implementation' and 'what are all possible subclasses of List'. Generators can do a huge number of things, including emit even more types which then need to be parsed, compiled, and the process continues until a full JProgram is created of all possible types, based on the current set of modules.
That JProgram then gets compiled down based on what can be reached from the roots - the entrypoint, as well as a few other details such as how to emulate Java details like casts, arrays, longs, exceptions, etc.
If -strict was not specified, and the compiler ends up needing to reach something which is unavailable due to earlier compilation problems, that is the time you find out. Using -strict to stop earlier will help ensure that you catch those issues sooner.
One more fun fact: By default, with com.google.gwt.user.User in your module (or any other <inherits> that depends on it), you already have an entrypoint, or several! These do some quick checking that your page is working correctly, such as using a strict doctype, or the browser actually matching the expected user.agent setting. This means that it is usually possible to compile a module even without an entrypoint (except with gwt-maven-plugin:compile, which will not consider a module for compilation just by those built-in ones).
EDIT: Okay, even one more: From http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html, combined with -strict, it looks like you can force the validation to run without actually compiling to JS:
-validateOnly Validate all source code, but do not compile
I don't think it's possible because the GWT compiler does not compile any unused code.
This means that your shared utility "module" may have code in it that is not compatible with GWT, but it will not cause any problems as long as GWT code never calls such incompatible classes or methods. Without an entry point GWT compiler won't know which code is used and which is not - it will assume that all of it is unused.