Is there a Maven Plugin that will automatically generate setters and getters with the corresponding JavaDocs?
I am aware that Eclipse/Netbeans will do this when you tell it to; however, it would be nice for the source to simply contain the skeleton and have Maven or another tool generate the repetitive stuff.
I would want to modify the source code so that a source jar can be compiled and used when debugging.
Thanks,
Walter
This isn't necessarily something that you want maven to do for you. It will make working with the code in the IDE harder, as the IDE won't necessarily know about the generated code unless it has a plugin that understands Lombok's notation. IntelliJ has such a plugin available.
That said, project lombok aims to do this properly through the use of an #Data annotation. It looks like it works well, but I haven't tried it. It supports a number of environments and IDEs through plugins, including Maven, Eclipse, IntelliJ and Netbeans. There are a few caveats with Netbeans currently, see the project documentation.
You could try Modello, it allows you to specify a model and let the java be generated during the build by the modello-maven-plugin.
I know you asked for a Maven plugin but there is annotation based project that takes care of many boilerplate code issues in Java:
http://projectlombok.org
There is a use case that doesn't work with Eclipse and the mouse.
Sometimes you need accessors in generated Java files, say, from an IDL specification.
One example would be if the classes are further processed by an ORM framework.
Now, how can this easily be done with Maven?
Of course, it's possible to script it or use the replacer plugin; but is there any off-the-shelf solution?
Related
I'm working on a Spring Boot project for university. The deadline is in a week and I'm 99% done with everything. Now, my instructor has reached out to me and asked me to remove Lombok from my project because (from how I understand it) he has a personal issue with it.
While I can't fathom why anyone would give such a requirement and really don't want to remove Lombok, I have to obey.
So now my question is: Is there a way to quickly replace all my Lombok annotations with its generated methods? If there is no way, I guess I'll have to resort to refactoring everything manually...
Thanks for any help.
The Lombok .jar file provides a 'delombok' tool, which will process all of the Java files in a given directory and output the generated code to another directory.
The usage looks like this:
java -jar lombok.jar delombok src -d src-delomboked
There is also a Maven plugin for this.
Alternatively, if you're using IntelliJ, the Lombok plugin also provides this functionality, under 'Refactor' -> 'Delombok'.
I have just tested this out on one of my own projects, and the resulting code does not have any references to Lombok, so hopefully it will be enough to make your instructor happy :)
What is the IDE you're using? Most IDEs have shotcuts for this. For instance, in Eclipse, you could generate Getters and Setters with "Right click" --> "Source" --> "Generate Getters and Setters"
I am trying to compile a Maven Java/Scala mixed project that has a Scala class that depends on a Java bean with lombok annotations. I tried adding the lombok jar file to the boot classpath of the Scala compiler as well as the lombok agent, but the compiler still failed to find the generated getters. Is there a way for the Scala compiler to recognize the lombok annotations? If not, what would be a good workaround?
Pease note that I am trying to avoid introducing another maven project just for compiling this bean first as the bean logically belongs to the same project. Also I cannot rewrite the bean in Scala as it is later used in a GWT project.
Thank you,
I think you'll not be able to avoid it. Normal Scala/Java integration works like this:
Scala goes first, since Java doesn't know anything about Scala.
Scalac parsers Java files and learns about visible elements.
Scalac reads Scala files and generate class files.
Java goes last, and reads Java files plus the class files generated by Scala.
The obvious problem is that Scala doesn't know anything about Lombok annotations, so it can't figure out the elements generated by it.
If you don't have any dependency from Java to Scala, you can simply invert the order: let Java go first, and have Scala include the output classfiles of javac on its classpath.
Otherwise, I suppose you'll need to break it up.
I'm new to Android and wanted to use AspectJ with it.
I had searched couple articles online and follow the instruction to have it working:
http://blog.punegtug.org/2010/11/adding-aspect-to-android.html
But I wanted to know whether if it's possible to separate the aspects away from the Android project. In the tutorial link above, it has both the Android App and the aspects inside the same project, but in many cases, we wanted to leave the Android Project untouched in its isolating spaces.
Let said I have AndroidProject in my Eclipse workspace, I would like to create a separate projects for my aspects called something like "AndroidAspectProject" which only contains the aspects for it.
I'm not sure whether this would work because it seems we need to let AspectJ compiler inject point cuts and advices to the .class files before creating the .dex files. In this sense, I may not able to do it in a separate project.
Does anyone try with this?
Another related question would be:
Is it possible to have Ant build the AndroidProject with AND without aspects on it? Can this be done outside of Eclipse?
I'm looking for a way to build different flavours as I'm only injecting pointcuts into the AndroidProject on dev/debug build, but will leave it untouched on release build.
Whether or not to do the compile-time aspects is a matter of whether or not you run the aspectj ant tasks. Have separate targets or properties for the AOP- and non-AOP-builds and either build one based on a target name or property, or build them both and change the artifact name.
IIRC Eclipse allows you to specify an Ant target to run on a build.
Inside of Eclipse, this is simple. Just add AndroidAspectProject to the aspect path of AndroidProject.
Inside of ant, there are several ways of doing this. But, the simplest is to define 2 targets. One that uses iajc and the other that uses javac to compile your sources. You then need to use a little ant magic switch between targets depending on whether you are compiling for dev or for production.
I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.
Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.
As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.
There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.
There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...
I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.
Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.
I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.
What is the best way to allow a team of programmers to use Netbeans, Eclipse and IntelliJ on the same project, thus eliminating the "which IDE is better" question.
Which files should or should not be checked into source code control?
I think the best way is to make the build process independent of IDE. This means that your project should not rely on any IDE-specific files to build, but rather use an external build system, like Apache Maven, Apache Ant, or even make or custom scripts. Maven is supported by most popular Java IDEs, either directly or via plug-ins.
If you don't want to use an external build systems, you should at least make the project as easy to set up as possible (i.e. by having standard folders for shared libraries and other dependencies). When I have working on teams with multiple IDEs in the past, I spent by far the most time on resolving dependencies as the prerequisites for building the project changed over time. In the worst case you may even end up with developers not bothering to get the latest version from the version control repository, since they think setting up the new project is such a hassle.
If your project has many library dependencies, I think its a good idea to make these available in binary form in the version control repository. That way people don't have to resolve all the dependencies of the dependencies and so on just to build a single project. This does however require that you have someone responsible for keeping the "official" binaries up-to-date whenever they change. (This is pretty much the same philosophy used by the Maven repository, but the principles can be applied manually even when not using Maven.)
Well, that's a pretty self-answering question.
The files to not check into source control are files that have to do with the IDEs themselves.
Leave it to the developers to generate these files.
If you use Maven, it can generate the files such as Eclipse's .project and .classpath for you. Eclipse in general is very easy to use with a basic file structure (with the new Java Project option).
I think Maven has Netbeans support as well, not sure about IntelliJ though.
Maven's site is maven.apache.org.
For each IDE that has more than one developer, check-in all the supporting files. Why re-invent the wheel at every desk.
I have done this with many different IDEs, and I have yet to see a filename conflict.
In fact, even when only a single developer uses a particular IDE, it is to his/her advantage to version the supporting files, for the same reason that you version the other files in your development environment: history, diffing, comments, etc.
For Eclipse, that would be .classpath and .project files.
My team uses Maven, and developers are discouraged from checking in Eclipse-specific files. Because they can be generated from Maven, these files are redundant.
Also, checking project-specific files seems like it would save time, but it usually winds up being a pain because of variations in different developers' workstations, resulting in wasted time resolving conflicts in the IDE-specific files. The only way to get around that is to force everyone to set up their environment the same way, which goes against the IDE-agnostic approach.
There are many considerations when using multiple toolsets within the same project team. For example, my team has Java developers using IntelliJ and most of the front end (JSP/CSS/HTML) developers using eclipse. We are in the process of migrating the Eclipse users to IntelliJ because of some IntelliJ plugins that we have developed that provide extended support for our environment. We're not going to develop the plugins for multiple platforms, so we are standardizing on IntelliJ across the board.
In terms of specific files, I can speak to IntelliJ. We have checked in our .ipr files and our .iml files. Do not check in .iws files. If you also have Eclipse users, configure your IntelliJ project to read/store dependency information in the .classpath file and commit that to your VCS.
We intentionally support multiple IDEs from the same SVN repository. Our thinking was that we want to ensure that, if a new person joined the team or someone had to start working on a new machine, we wanted them to be able to checkout the codebase, import it to the IDE and immediately have a work-able configuration.
What that means on the developer end is that they should not commit their changes to the IDE files. Everything else (e.g., src, test, lib and so forth) becomes the set that we normally update and commit every day.
The side benefit is that we have completely eliminated the IDE wars here: Netbeans and Eclipse people live in perfect harmony (looking askance at the IntelliJ people, but hey... ;-).
For more comments and answers on this topic see this question (How do you handle different Java IDEs and svn?)
We rename our IDE files for checkin with an extra extension .deletethis or similar. When a new person checks out the project, they simply strip off the extra extension and are good to go. This way we avoid source control conflicts with the project files as people tweak their environments. And you don't have to worry about educating new developers to not check in those files.
Typically, I would consider this a bad idea. I'm not sure what kind of environment this is (perhaps open source?), but it would really suck to support multiple IDEs. One thing I would recomend if this is unavoidable, would be to standardize your builds in ant scripts. If you have a large set of dependencies, this may be the easiest way to get a predictable build across all platforms.
If one of the IDEs happens to be RAD (based on eclipse), there is an entire folder called .settings that you would not want to include in the SCM.