We just started using Lombok plugin for Java.
Developers in our company use Eclipse for workspace and we have some clients who get access to part of our source code.
If we use Lombok library, it doesn't get detected in Eclipse until the plugin is manually installed.
It's hard to send a communication to multiple clients and have them mandate the plugin installation.
Is there a way to automatically install a plugin from the project itself, may be with an yes/no question to let the users accept it, that way we don't get accused of sneaking stuff in :)
It is NOT possible to install an Eclipse plugin from the project itself.
It is clearly stated in the Lombok documentation that manual installation is necessary as Lombok is a preprocessor. Lombok needs to be installed to the Eclipse install folder (next to eclipse.ini). https://projectlombok.org/setup/eclipse
And I suppose it would be a security leak (both in Eclipse and your Customer's environment) if you are able to install something into the 'Program Files' folder from your projects without user interaction. However manually copying is feasible and could be a workaround if you are very keen to do so.
Workaround: You might provide an ANT/GRADLE script that will distribute you local copy of the lombok.jar into Eclipse's program folder. And also create a launcher configuration. So you can refer to this launcher step to be executed. Please note that you need to restart eclipse just after lombok installed. But in fact this is what lombok.jar does when running as described in the install guide.
The standard lombok installation is being done manually.
Therefore, I've created an automatic installer.
It's available here: https://github.com/zorik9/lombok-automatic-installer
Right now it supports only eclipse IDE in windows machine.
The idea is to configure once the variables: lombok_version, eclipse_home and workspace_dir (not mandatory)
And based on this configuration, run the installation script on each machine.
For more details, please read the readme.md file.
Related
In a Java project I have a dependency on my own library. I have installed this library in the local repository by running mvn install in the root of the library's directory.
When I updated the library and re-installed it, VS Code couldn't see a newly-added method (everything compiles fine from the command-line).
I've tried Java: Force Java Compilation (full) and that didn't work.
In pom.xml I right-clicked on my library and chose Update Project and that didn't help either.
If it makes any difference, I am running on WSL2 (Ubuntu-20.04) on Windows 10.
Is there any solution short of restarting VS Code (which is a rather cumbersome workaround)?
Executing the Java: Clean Java Language Server Workspace command from the Command Palette (Ctrl+Shift+P) should work.
If you added new dependencies or jars, java language server will build and compile them automatically.
In some rare cases, you may need to execute the above command to let the language server rebuild your dependencies.
Reference: Library Configuration
I was provided with a Ubuntu virtual box that has netbeans installed whereas locally I have Intellij. My Java workspace is shared between guest and host, therefore I was wondering if there will be any kind of conflict by running Intellij and Netbeans at the same time in such conditions.
Thank you for your help.
I am not sure how the guest-and-host-OSes condition would play into this but I am pretty sure otherwise that the workspace can be shared by both of them especially when they are not working on the same project. Even if they are, it'd be you who'd be getting confused as files would get updated on both IDEs as the other one makes any changes.
There should not be any conflict as long as you have read/write permissions on both the OSs.
However, to track the changes to code in a better way, use a version control system like subversion.
Also, do not copy the resources to your workspaces. Instead check out the code directly to your workspace.
This don't cause conflicts because each IDE adds a set of configuration files per project, for example: netbeans generates the nbproject folder, where is the project configuration for that IDE, while intellij generates a projectName.iml file and the .idea folder where is the configuration for the project.
If you use a version control tool as git, svn, mercurial, is recommended that you synchronize your project in each environment (guest and host) with your repository and do not share the workspace between them.
I have an application that works fine and that I can execute from a .jar file. But I want to know how to make it runnable from any computer even if there is no JRE or the JRE version is not the good one. I thought about a .exe file but don't know how to do it.
I made my code with Eclipse and it use jxl,jdom and jfx librairies.
I tried to use Inno Setup 5.5.6 but when in Eclipse I run my build.xml as Ant Build it return me an error that says :
"'Launching JFX Build - Myapp' has encountered a problem.
The achive : C:/Program%20Files/eclipse/plugins/org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528.jar which is referenced by classpath, does not exist."
JavaFX provides specific utilities for bundling your application as a native package, which is referred to as "Self contained application packaging". These utilities are provided as a command-line tool, or as ant tasks. Additionally, the common IDEs support this via wizards, either out of the box (NetBeans) or via a plugin (e(fx)clipse for Eclipse). The details of how to use any of these are far beyond the scope of a stack overflow question, but the basic documentation is available here. A tutorial for e(fx)clipse is here.
Briefly, for e(fx)clipse, you should double-click the build.fxbuild file that is created in your project. Under the "Overview" tab, find the "Packaging format" option, and select "All" (or the specific type of package you want to create).
Note that you can only create a package targeted at the platform on which you are building, so if you want to create packages for windows, Mac, and Linux, you will need access to all three types of machine.
I know I am late. I faced same problem a trick worked for me. Look at the given directory in the error message. It contains a space (C:/Program Files/...). Move your e(fx)clipse to another directory where the directory doesn't contains any space.
Not sure it will work your everyone or not but it worked for me.
Thanks
There are various tools that let you wrap your Java application in a Windows executable. Some tools are only simple installers, others allow you to bundle your application with a specific JRE version.
A widely used but commercial tool is install4j, but there is a bunch of other tools, such as WinRun4J.
I have javac version 1.6.0_16 already installed on Windows XP and I'm using both Dr.Java and command prompt to compile and run Java programs.
I downloaded and extracted Checkstyle 5.5 and Findbugs 2.0.1. I'm trying to install Checkstyle and the instructions stated that I need to include checkstyle-5.5-all.jar in the classpath.
My question is, should I place the Checkstyle directory in the lib folder of the jdk1.6.0_16 directory and set the classpath as follows:
C:>set classpath=%C:\Program Files\Java\jdk1.6.0_16\lib\checkstyle-5.5\checkstyle-5.5-all.jar
Is this correct? Should I do the same for Findbugs? Thanks in advance
EDIT: When I added the above path using the environmental variables, and ran checkstyle hello.java, I got the error: 'checkstyle' is not recognized as an internal or external command, operable program or batch file
Maven will solve this problem for you
It sounds like you're just getting started in the world of Java. To that end, I'd suggest that you look into Maven for your build process. Also, you should be using at least JDK1.6.0_33 at the time of writing.
Essentially, Maven will manage the process of running Checkstyle, Findbugs (and you should also consider PMD) via standard plugins against your code. It will also manage the creation of the Javadocs, linked source code and generate a website for your project. Further, Maven promotes a good release process whereby you work against snapshots until ready to share your work to the wider world.
And if I don't use Maven?
Well, just create a /lib folder in your project and stuff your dependencies into it. Over time you will create more and more and these will get intertwined. After a while you will enter JAR Hell and turn to Maven to solve the problem.
We've all been there.
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.