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 have a Java application I've developed in Eclipse. To package it into a .jar, I simply run File->Export->Runnable JAR file with copy jar files into sub folder selected.
For deployment, I turn over the compiled jar file along with my source code and the deployment team packages it up and deploys it to our systems. One of the responsiblities of the deployment team is to verify that the source code that is turned over compiles into the binary that is turned over with it. This is the only Java program the deployment team works with so they don't have Eclipse available to import my source code and validate it against what I provided them. For the time being, they have just been taking my word for it, but that needs to change. They will need to compile the code on their own and make sure it matches what I've given them.
How would they go about doing this? I suppose one option is to get all of them up and running Eclipse, but that seems like an overkill. Is there something they can run outside of Eclipse without having Eclipse installed to generate a jar file that they could validate is the same as what I've provided?
Thank you for any assistance.
First, how can they tell that what you supplied "matches"? That doesn't really make sense.
What they really want to do is to build their own deployment artifacts from your source. They can either set up Eclipse and use that as their build tool, or you and they can agree to use a build tool such as Maven or Gradle. These tools integrate with Eclipse, but they are designed to run stand-alone or as part of a tool like Hudson or Bamboo, which will perform build on a schedule or when a VCS is updated.
A client used Maven and Bamboo, along with the rest of the Atlassian suite, to handle enormous builds based on contributions of more than 100 developers. That included running JUnit tests, test coverage, and code quality tools.
I'm totally new to java programming but I'm been programming with .Net and PHP. In .Net all you have to do is run it and it will output exe file in the bin dir which is already deployable, right? I'm confused with the use of maven and javac. I've been searching around but I don't still able to fathom them.
What I'm thinking is that when a certain source code is to be compiled in java, you use the cmd "javac " which is similar to "Run" in .Net. So why do we need Maven?
Building an application is a lot harder than running javac. There are two big motivations for build tools like Maven: cross-platform builds and dependency tracking.
Part of life for Java developers is needing to build applications on multiple platforms. A build has to run locally on a developer's machine, it also has to run on a Continuous Integration server or on some other environment. (And for some projects developers may have different platforms so even just getting a build to run on everyone's machine may require cross-platform builds.) Getting shell scripts to run in multiple environments proved to be prohibitively painful, and people started creating things like Ant and later Maven.
Any sizeable Java application is put together using dozens of third party libraries and frameworks. Most of these third party components have dependencies on other libraries, keeping track of the tangled mess is too much work for anybody. An important function of Maven is to pull in dependencies, making sure the libraries have compatible versions.
Maven is a software project management and comprehension tool and not a programming language compiler like javac.
Maven gives you a way to manage your project dependencies through out the development and deployment phases of it, meaning that it ensures that you have the necessary libraries to develop, build and deploy your project. Javac only gives a way to compile your Java code.
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 think this question is an extension of Compare to the IDE for Java,do we still need Ant?
There are answers for the question above, but I wish to know a concrete example of using Maven or Ant over just Eclipse.
When I develop in Eclipse, Eclipse does everything for me and I just need to click the run button. And also, Eclipse can let you export your code to a runnable jar or even .exe for windows.
So I really don't know why I need Maven or Ant.
And also if I do need, which one should I choose, Maven or Ant?
Because your collegue might prefer NetBeans or IDEA
Because the settings might vary from one eclipse install to another
Because you might want to get your dependencies automatically
Because you want to automate the complete build: build, jar, apply static code analysis, run the unit tests, generate the documentation, copy to some directory, tune some properties depending on the environment, etc.
Because once it's automated, you can use a continuous integration system which builds the application at each change or every hour to make sure everything still builds and the tests still pass...
Because Maven uses convention over configuration.
Because your IDE may not support some fancy code generation/transformation you need.
Because a build script documents the build process.
Eclipse is a development environment. But it's not a build tool.
I personally hate Maven, but YMMV. There are many alternatives: gradle, buildr, etc.
Maven strikes me as a case of something written by a bunch of past-their-sell-by-date c-shell script kiddies who think autoconf is leading edge code automation and don't understand that object code requires an object environment to be in any way efficient either for development or deployment. Ant was bad enough, but Maven combines all the worst features of Ant and Ivy. It doesn't create an object environment, and it doesn't play well with tools that do.
Simply, an object environment should have all class objects, i.e. the objects that determine the types of objects available to the system, live and available at all times. From there I can do whatever I want, instantiate multiple objects of a class, set up various sequences and instantiation rules, etc. Since the environment should be completely live, I shouldn't need a build tool at all. In terms of deploying my app, it's not difficult for the environment to simply throw out all the class objects that are never referenced by code in the namespaces that make up my app. The garbage collector in the JVM does almost the same thing on the fly today. At that point I have a deployment environment made up of my objects and all the objects (primarily class objects) that my objects reference, i.e. my application and all dependencies. This is how virtual machines work. (that our VMs are so poorly written we need to run a Spring VM on a Java VM on a Linux VM on a VMWare VM on another Linux VM is another example of the idiocy of software development). When dependencies get updated, it's simple enough for the environment to prompt the developer to merge his old code to the new libs, merge the code using the new libs down to the older version, or keep both versions. Prompting encourages the developer to make the slight modifications that are sometimes necessary to avoid having twenty versions of every library, while tools like Maven hide the fact that you have twenty versions and result in the massive runtime bloat common in Java apps.
In the Java development space Eclipse comes closest to being a proper object environment, although granted there are plenty of plugins that break the paradigm in various ways. Most of the reasons given for using Maven fall apart when examined critically.
Netbeans and Idea are overblown text editors, not object environments, but if you do want to use their tools for something not covered by the thousands of Eclipse plugins, both can import and maintain Eclipse projects, your build will just be inordinately slow compared to developers using Eclipse, but then, they'd be that slow if they were pure Netbeans or Idea projects anyway.
Not a serious reason to use Maven.
The ease of exporting / importing settings in Eclipse (something every team should do in any IDE in any case) makes the different settings problem nothing more than laziness on the part of the development team (or a religious argument over spaces vs tabs, lol).
Again, not a serious reason to use Maven.
Team environment? Show me a team that doesn't already use a repository like GIT or SVN. Why do we need to duplicate both the functionality and the maintenance headache by setting up Nexus repos as well?
That one's actually a good reason NOT to use Maven.
Running a server build? Great idea, now, shouldn't that be kicked off by code that's actually checked in to the source repo rather than a random build that happens to get pushed to Nexus? This brings up a point against Git, particularly Git with Maven. Since in Git I don't work on a branch, test locally, then commit (partly because my local test doesn't prove the server build works due to differences in the Maven configuration in Jenkins and Eclipse) I have to commit my changes to a different branch in order to see that the server Maven build fails, then commit a further change to fix the problem, resulting in an unreadable source history in the repo. Checked in code should at the very least build and pass unit tests, which if Git and Maven were out of the picture should be guaranteed.
Exporting a headless build from Eclipse is trivial if you actually look into it - all you need is ant or Gradle, the developer build already maintained by Eclipse, and a few Eclipse jars (Eclipse will export all the necessary files for a headless build to a directory or zip file, or ftp them to the build server). Server build tools like Hudson/Jenkins can pull updated code from most source repos and call any build script, there's no dependency on Maven. With Maven you either force developers to use a tool not suited to anybody but build engineers (the magnitudes longer it takes to build, even using M2E, is sufficient for that case to be made), or you live with the possibility that the server build doesn't work quite like the workstation build, which is still true if you go through all the hassle of integrating the two using the plethora of M2E plugins. Either way you get a slower and more fragile workstation build for the sake of an equally slow and more fragile server build. On every Maven based project I've worked on I've seen transient Hudson/Jenkins errors that don't show up in Eclipse unless you have absolutely every possible M2E plugin installed and correctly configured, and most developers never do.
Seems like another great reason to avoid Maven.
That doesn't cover some of the more fundamental problems with Maven, such as its namespaces breaking Java namespaces and XML namespaces, it's build unit (the POM) having no relation to anything in the actual deployment environment (think about it, when you separate via POMs what are you actually accomplishing in the finished product? Nothing. All it accomplishes is a false sense that you've separated concerns and functionality into different build units that all run as one monolithic piece of code); the hassle of manually maintaining complex configuration files, which only gets worse if you happen to need to use OSGi or another container and have to maintain other config files that affect and are affected by the Maven config with very little obvious sense to it; the problems caused by trying to run unit tests without a full environment for the code to execute in; the myriad versions not only of dependencies but of Maven specific plugins (I've actually seen JAR hell in the Maven build itself where multiple Maven plugins were using conflicting dependencies - one of the problems Maven was supposed to solve.
Yes, you can build object code with Maven. You can also write pure object code in C or even assembler, but I don't know why you'd want to.
The best reason to avoid Maven is the phenomenal amount of work required to de-mavenize a set of projects when you get sick of all the problems noted above (and numerous others not mentioned).
The mindset, inherited from C development, that the development cycle consists of write code, compile, assemble, build, deploy, test, do over again, is hopelessly outdated in an object environment. At some point we need to tell all the people with this mindset that they need to relearn how to develop, period. Doing so would remove any need for Maven, Git, and a host of other tools that do nothing but waste time.
Object development should be done in a live object environment, where a code change is tested as it is saved since the modified object is live. Deployment should consist of removing development only artefacts from that environment, creating a runtime that has everything used by the running app in development and test.
I'm currently dealing with a problem caused by creating deployment assemblies for an OSGi app using the maven-assembly plugin. The app works perfectly in the Eclipse environment, which hot deploys all code changes into a running OSGi container within the environment. However the configuration doesn't survive intact through the maven-assembly process, despite having a very good configuration/build engineer whose sole job is to accomplish that process. If we got rid of Maven (very difficult now due to the amount of code, but possible) and used the BNDTOOLS Eclipse plugin we could simply export the Eclipse build as an Ant or Gradle headless build (note, the OSGi developers who write BND and BNDTOOLS don't support Maven, and for good reason, the Maven plugin is written by the Felix developers who themselves use Netbeans and Maven, and no live environment other than at the end of the deploy cycle), where both tools set up the same environment as Eclipse, without the GUI objects that are only meant for developers anyway. The result would be an identical configuration and build for deployment. This would easily save 2-3 hours per day per developer currently spent watching slow Maven or M2E builds, and free up the config/build engineer to do more testing of the app on the deployment hosts.
Getting over the mindset of write/compile/assemble/build/deploy/test is the only major impediment. Pretending you're coding on a 1979 VT100 terminal instead of a modern machine doesn't make you a 'real' developer, it just demonstrates that your methods are 35 years out of date.
Of the developers on the team, none of the others properly understands a live object environment like Eclipse sufficiently to get it to work as a live environment with M2E and OSGi, and they are top developers, they just haven't been exposed to it due to the prevalence of outdated command line development tools. They only realized it was possible to do so when we were pair programming to solve the configuration problem and I was sharing my screen, causing one of the other team members to exclaim "that's how you write code so damn fast", when he saw my code change instantly test itself in the background OSGi container. I can use a bash shell when I have to, such as when I'm looking at logs on a remote server, in fact I do so fairly efficiently precisely so I can get out of that environment as quickly as possible and return to the 21st century.
There are soo many advantages to using Ant or Maven.
Maven is more or less an update concept of Ant.
Instead of giving you a bullet point answer I have decided to take another approach into answering this question. I'll ask you a simple question. I'am assuming here that you would be a developer; or have some sort of OO programming background.
So If your manager was to ask you to copy two hundred directories, but ignore jar, war and ear files within those directories and once copied. You then deploy those two hundred directories to another destination but deploy only .class files; copy rest of the files into another destination etc.
For you to do this in java; it will be lots of logic, lots of code and would not be extensible or adaptable to change. So that in mind Ant or Maven will accomplish and prepare all this on the fly with less overhead for your application to use. The size of the code in ant or Maven will be 1/4 compare to Java.
Click on the links for more technical benefits:
Maven
Ant I could not find an authentic answer with benefits, but I'm sure this would convince you ;)
Maven and Ant are used to script builds so that they may be executed in batch jobs like with Jenkins or on the command line.
In fact Eclipse itself uses Ant extensively to build plugins.
If you were to learn one of the two, learn Maven, it's the one pretty much everyone uses these days (replacing Ant).
Maven is generally used to build the plugins or jars for a particular application.
Suppose you have developed an application but you don't want to go for adding the jars needed for that application manually. In this situation Maven or Ant is very helpful. Once you have written your code just got to Run As -> Maven Build (click on Maven Build) , it will generate all the required plugins or jars and include in your application library build-path. A doubt may come like how the application will get those jars, For each application there is a xml file named as POM.xml where reference of all the jars are kept there for downloading purposes.