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.
Related
Are there any libraries out there that can generate the JSON/YAML file by analysing static code and generating the JSON/YAML files off of that?
Right now we're producing the Swagger files once the project has finished building. We hit the url at /api/swagger.yaml and do what we need with the file (this adds quite a bit of complexity to our automated builds)
Yes so as you are sort of doing already you can stick that in your CI which would startup this dummy Spring app then make a HTTP request to download the JSON/YAML then shut it down and get the file, as far as I am aware there are no tools that do this at compile time for Java and that's as good as it gets.
The other way is if you do things in opposite where you first design your API interface in swagger and then you generate code (your interfaces) which you then implement yourself.
From the sounds of it you want to be designing your API first, this will allow you to put it in version control and this will make it easier to manage your API versions life cycle and track it's changes, otherwise it can be quite difficult to see how things have changed if you have to search through annotated methods in code, that is what swagger is designed for.
You don't necessarily need to do codegen from your swagger as I have found this to be very awkward at times and it is extremely dumb and generating code, it's just moustache templating and IMO the tool is fundamentally flawed for this reason, but as my most hated saying goes:
it's free so you can't complain
I am looking for a solution that can be run on a continuous integration server (TeamCity) which seems to rule out IDE specific solutions like the externalization that is built into eclipse.
I need to generate warnings when strings are found in the java source files, unless they have been somehow flagged (by comment or annotation) as not requiring internationalization, eg the // $NON-NLS-1$ comment for eclipse.
The code is built using maven in teamcity.
I have not been able to find existing solutions or any ideas on how a custom solution might be hooked into either maven or teamcity (note I am not hugely familiar with either so could be overlooking something fairly obvious).
It seems that you need some specifically crafted Static Code Analysis tool.
I am afraid that no such thing exists yet (or I should say no such thing is available for public use...). I am not sure if you would be able to create warnings from the tool though. I know it would be possible with Gradle, but integrating Gradle task with Java code is not an easiest thing to do (BTDT).
Maybe some simple HTML report would do? In this case, you can simply use Scanner with regular expressions that matches all the strings literals... That is unless you'll find exclusions (another RegExp) in the same line. That's pretty basic thing to do.
I have just started with annotation based programming in Java. I was using xml based setups (hibernate) for configurations.
In annotations we have to write annotations within the java files, right. So, if we need to change something, then we would have to edit the java file, compile it again? Is this the correct way that I am understanding?
I read this question regarding the advantages of annotation in hibernate. But my question is not limited to hibernate.
UDPATE (Should not have used write once run anywhere in question)
In case of xml based-config, we just make changes and restart the app that it right?
But in case of annotations, we would require to again re-compile, re-deploy and re-start the app. Isn't this a disadvantage?
No absolutely not!
To reflect the changes made in your source code you have to compile and run the code again and is true for all programming languages. Only use of annotations or xml configuration files is to ease the project setup, debug and running.Even if you have xml/annotation for your project(Ex Spring or Hibernate) you have to recompile the project to reflect your changes.
"write once run anywhere" paradigm is that when we compile any java code it gets converted into bytes code which can run on any OS/Platform. All you need is the JVM installed which actually understand and runs the java code.
Updated Question Answer : Again the answer is no! It is not at all a disadvantage. In face it is a feature to prevent writing more code(So that you can concentrate more on your business logic). You have to choose the right combination for your project. For example recently i worked on Spring and I used both xml configs and annotations. xml config has the configurations that are user configurable where as annotations are mostly used more for flow control. For example annotation in my case dictated what to be executed before a bean is create or after. Same is the case with most of the annotations based code. It is used to tell JVM that specified functionality is for specified condition but the data required for processing is obtained from xml configs.
I don't know much about Hibernate, but needing to recompile after changing the source doesn't break "write once, run anywhere", which is intended only to refer to the (theoretical) platform independence of a compiled Java application.
write once run anywhere: means you can run in it on any platform without having to redo anything for a particular platform.
It does not mean that you write once, and if you have to change something, it will work without recompiling your classes.
This question came to me when developing using Eclipse.
I use JBoss Application Server and use hot code replacement. But this option requires that the 'build automatically' option to be enabled. This makes Eclipse build the workspace automatically (periodically or when a file is saved?) and for a large code base this takes too much time and processing which makes the machine freeze for a while. Also sometimes an error message is shown saying that hot code replacement failed.
The question that I have is: is there a better way to see the result of a code change?
Currently I have the following two suggestions:
Have unit tests - this will allow to run a single test and see the result of a code change. ( But for a JavaEE application that uses EJBs is it easy to setup unit tests?)
Use OSGi - which allows to add jars to the running system without bringing down the JVM.
Any ideas on above suggestions or any other suggestion or a framework that allows to do this is welcome.
Did you take a look at http://zeroturnaround.com/jrebel/?
I tell you how I work. I hope it is useful. First of all, I disable "Build Automatically". Maybe it is better if you do a simple ANT script to compile and see errors/exceptions. Also, I make jar file with the same script. Afterwards, I use OSGi to check the application. Yo do not need to stop server, only you need to change versions in deployed bundles. Intead of JBoss Server I use Equinox which includes Jetty Web Server.
May you have a nice day!
With JRebel, you wouldn't have to build your project (skip the build totally). Plus, only the changed resources will be reloaded so the update happens instantly. Plus, session is preserved so you do not have re-login to the application after the update was performed.
Even though the question I asked was quite specific to Java, I thought that mentioning using an interpreted programming language that avoids the compilation step is anther way of seeing result of a code change faster.
I'm working on a couple of web services that use JAXB bindings for the messages (in JAX-WS or spring-ws). When using these bindings there's always some code that is automatically generated from the WSDL to bind the message objects. I'm struggling to figure out the best way I can make this work so that it's easy to work with, hard to break and integrates nicely with IDEs (mostly using eclipse).
I think there are a couple of ways to go about this. The three main options I see right now are:
Generate code, keep the source artifacts and check them into the repository. Pros: integrates easily with IDEs (source highlighting etc), works within the build system. Cons: generated code changes each time you regenerate it, possibly creating noisy commits. It's also redundant since the WSDL file is already checked in, usually.
Generate code as part of the build process. Don't keep source artifacts or only keep them in output directories. Pros: fixes all the cons from the previous one. Cons: harder to integrate with IDE, though maybe this build step can be run automatically? I currently use this on one of my projects but the first time I checkout the project it appears broken, which is a minor nuisance.
Keep generated bindings in separate libraries (jars) included with maven or manually updated jars, depending on your build process. I got the idea from a thread on java.net. This seems more stable and uses explicit versioning but seems a bit heavyweight.
Which one of these options would you implement and how? We're currently using maven and eclipse, so any ideas in that regard would be great. I think this problem generalises to most other build systems and IDE combinations though, even other languages perhaps.
I went for option 3. If you already host your own repository (and optionally CI), it's not that heavyweight. All it takes is a simple POM. It's even possible to include some utility/wrapper/builder classes (that often make life easier with generated classes) and use them in several projects.
I'd go for option 2 and generate code in the "standard" ${project.build.directory}/generated-sources/<toolname> location as part of the build process. Using generated sources is well supported by m2eclipse (use Maven > Update Project Configuration once sources have been generated) and, if I remember well, by the maven eclipse plugin as well (i.e. the folder will be added to the Java Build Path). Actually, I think NetBeans also handle this fine. Not sure for Idea.
For the generation itself, you may need the maven-jaxb2-plugin if I understood correctly.