I might be missing something but how do you manage Java projects in eclipse that need a lot of Jar files. I know maven manages libraries well if there are new updates but maybe I'm missing something, is there a way that eclipse can update new jar files (it would be especially useful for projects using apache-commons, say).
I don't want to sound like asking for a feature request, but I'm looking at if there are ways to keep libraries jar files that a Java project uses to keep them updated automatically the way maven does. With more languages coming with this type of features, finding the right Jar files probably should be easier than this.
Eclipse doesn't manage your jar versions for you, and as far as I know it won't do any auto-updating of jars that have newer versions out there. There's simply not enough information or infrastructure for Eclipse to recognize that a given jar you've added to the classpath is eligible for updating and that you want it updated.
However, there is a Maven plugin for Eclipse called M2Eclipse, which will read a POM and construct a classpath out of jars it finds in the local repository and any remote repositories you've configured. It behaves largely like Maven does in terms of finding the latest version for a given jar (if you've specified a version range in your POM).
You can create user libraries and change their content when new versions are available. That way you do not at least need to change the build path of every project. Or you can load sources of the libraries from their svn and use their trunk version. Remember that you can select multiple projects and svn update them at once.
Related
I've written programs in several languages and have tutored students in computer science, but just starting to learn Java on my MacBook. Regarding this question, I'd be happy with any answer that points me to available information or tutorials that address my question; I'm capable of understanding advanced things.
I've been searching for the right IDE for me as well as something I can use with my students, and I've tried IntelliJ, Eclipse, and VS Code. Along the way I've installed external JARs to provide extra capabilities, such as Apache Commons.
Things are getting confusing. I've lost track of how I got to the present state in each IDE. I'd like to understand better how to know the overall Java environment that any given project is using on each of these IDEs, including any external JARs and where they are located. And I'd like to know if they borrow from the Java system environment.
My goal is to understand how my own system got to the way its currently configured, to update my configuration on a project-by-project basis, and to help my students get a matching configuration.
I'd also like advice on the right way, or simplest/cleanest way, to install external JARs.
Maven
Question: I'd also like advice on the right way, or simplest/cleanest way, to install external JARs.
If you really wanna work in a organised way and wanna focus completely on coding rather than looking for dependencies to work with , then try building your projects with Apache Maven. The magic wand of Maven projects are pom.xml file where all magic happens depending upon your wish.
Maven is a build automation tool used primarily for Java projects. Maven addresses two aspects of building software:
Describes and manages how software is built.
Describes and manages dependencies (various libraries used by your code).
Why Maven:
De facto standard
Able to compile, test, pack and distribute source code ( different Goals)
Robust dependency management (Most important from my point of view)
Extensible via plugin
Good community support and many fan boys around.
The big 3 IDEs (IntelliJ, NetBeans, and Eclipse) all having good
support for Maven, letting you use Maven as a substitute for their
own proprietary project definition and build process.
Maven famously caches all of its dependencies in the ~/.m2
directory, which is sometimes called the local Maven repository.
Maven local repository keeps your project's all dependencies (library jars,
plugin jars etc.). When you run a Maven build, then Maven automatically
downloads all the dependency jars into the local repository. It helps to
avoid references to dependencies stored on remote machine every time a
project is build.
You can simply deploy your project as JAR, WAR, or EAR file and use it on different IDEs or as standalone.
All IDEs need a way to know your project's dependencies. You can either tell them that yourself or let a build tool do that.
Manual dependency handling: by adding the jars to your project. This is probably the fastest way when working on a small project, with one developer, on a specific IDE, with few dependencies. Usually when telling the IDE that this .jar is a dependency of your project, the IDE stores that reference to a project-specific file (eg. in Eclipse the .classpath file which you can edit with a txt editor and see the dependencies yourself). However, it kind of locks your application to your IDE. Most IDEs have cross-IDE support for import and migration, but using both IDEs at the same time can be confusing when a dependency is added to one and has to be repetitively added to other as well. Furthermore, your dependencies have dependencies on their own. By adding manually your jars you are responsible to find and download their own dependencies as well.
Use a build tool: There are 3 standard such tools right now: Apache Ant with Ivy, Apache Maven and Gradle. All of them have support in the major IDEs for Java: IntelliJ IDEA, Eclipse and NetBeans. All of them use some extra build-tool specific files to store your project's configuration and subsequently configure your IDE and the IDE-specific files. That way, your project becomes IDE-agnostic, the IDE outsources the dependency handling to the build tool. These tools will download any direct or transitive dependencies of your project in a local directory or you can compile jars in a specified folder. From those, Ant is the oldest (with Ivy adding dependency handling support), Maven was developed after that and Gradle is the newest and probably the most flexible. In production however Maven is by far the most established one right now.
It would be also useful to look up the Standard Directory Layout. If you adhere to that, it will be easier to work/start with either Maven or Gradle.
Finally, you can search and find most of the free libraries in Maven-Central where conveniently their Ivy/Maven/Gradle script is added as well for you to use on your build-tool script. In many cases a .jar is provided as well if you prefer to manually add it as a dependency.
Regarding VS Code, I think it supports these tools through plugins but I'm not sure.
I've seen a lot of projects, even from big companies like Elephant Bird (Twitter) and Akela (Mozilla) that offer source and ask you to compile it yourself instead of also offering jars. Is there some benefit to compiling in your own environment instead of just downloading a jar someone else has compiled?
Dependencies are not in the same location or even have the same version on every machine. It is simpler to detect where they are at compile-time.
If there is any native code (sometimes just for optimization) in a project, there are probably platform-dependent flags that need to be set at compile-time.
The short answer is dependency management. Most public OSS Java projects offer jars by publishing them to Maven Central. You are expected to use a build system like Gradle, Ivy, or Maven to manage your dependencies - these tools will automatically download the library you want along with any of its dependent libraries and be smart about it, caching it on your local filesystem so if a library is shared across multiple libraries it won't be downloaded twice.
As for the example projects you listed, Elephant Bird is available via Maven Central whereas Akela tells you exactly how to create your own jar (perhaps it's not quite far along enough to justify going through the rigmarole of publishing to Maven Central):
Building
To make a jar you can do:
mvn package
To make a Hadoop MapReduce job jar with no defined main class in the manifest:
mvn assembly:assembly
Without an automatic build system its hard to maintain a current version of the jar file online. Including the jar file in the repository is generally not a good idea as users who clone it don't need the compiled jar, they want the code. So unless the publisher explicitly adds a jar file to a download location outside of the sourcecode repository and updates this file every time the application changes you have to compile it yourself. Automatic Build systems can help a publisher to provide a current compiled jar to it's users but for smaller projects it's not always sufficient to go through the trouble of setting one up.
I'm using Maven to build and deploy jOOQ. I now want to start generating XJC-generated classes using appropriate Maven plugins (before, I used ant scripts). This works very nicely for me, but I'm afraid that some users wanting to build jOOQ themselves without Maven will now have trouble generating those missing sources. So I'd like to move those sources out of target/generated-sources/xjc and into src/main/java, in order to be able to put them under version control.
Is this a common practice?
How can I do it (should I use plugins to move the files on a low-level, or should I generate files directly into src/main/java)?
Do I have other options?
Note, the underlying XSD hardly ever changes, so I don't have to generate these sources every time I build...
This is a terrible idea, you should never put generated sources in version control because whatever they are being generated from can change, and then your code is out of sync.
Even if the XSD never changes, note I said never, not hardly ever, as you said, which is different, I would not put the sources under version control. Maven can be told to not generate the sources every time if the XSD hasn't changed.
If you go down the Maven route, then anyone building your stuff should use the same tool chain. This is not specific to Maven. If this was Ant, or a C++ project with a make file, you wouldn't want to do this either.
If you really want to provide a Maven free stand alone distribution, then have Maven generate that, there are plenty of plugins that will export all the artifacts as an archive that you can distribute. But don't compromise your build for some nebulous external requirement that may not exist.
Maybe an alternative is to use the Maven assembly plugin to zip all those sources and expose those as a versioned artifact. The dependency plugin would allow you to pull in those sources from a local or remote repository and make sure you have the correct version of those sources.
(In my opinion, leave it like it is. If Maven is your build system, everybody trying to build your code should use that)
I installed ZK Studio plugin for eclipse and have used it to create a new ZK based webapp. However, inside my /WebContent/WEB-INF/lib folder, there are a number of .jar files that were included automatically (beloning to the zk framework). I'm assuming this was done by selecting "create a new ZK project". However, when it comes time to deploy this to the webserver, I only want to include the libraries I actually need and use. Is there a way of finding that information out so I can shrink the size of my .WAR file?
Thanks!
These are called "transitive dependencies" - libraries that required by libraries that you use. The libraries that you use can't work without their dependencies, so ultimately you need all of the jars in WEB-INF/lib.
Maven is a dependency-management tool that tells you what are the transitive dependencies, (via a dependency graph). I would recommend using maven, although it would require some effort to introduce it in the current project.
Take a look at The Content of ZK Binary Distribution
then you can remove the library you don't need :)
My project requires some external libraries to build in in Eclipse. They live in /trunk/lib whereas my project is in /trunk/projectA. To get Eclipse to find the libraries on all machines we set a variable PROJECT_A_HOME.
Now I'm trying to get some builds going with maven and I can not figure out how to add that path (be it environmental variable or relative to $(basedir)) to the build. I really do not want to set up a repository for these dependencies, as I keep them in source control and want builds to continue to work in Eclipse.
I've seen talk about but that hasn't worked for me.
Ideas ?
You should put your static configuration files in resources/ dir. If you have your own or proprietary jars you should set a your own repository so you can download them from the repository or better yet just install them manually , here is how
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Setting up a file-based repository as suggested in this previous question would allow to keep the libs in your version control system and work seamlessly at the Eclipse level (the libs would be treated like any other dependency). The only problem I can think of could be at the continuous integration level: a build of projectA would require a checkout of trunk/lib. Many CI tools would allow to implement this though. And if not, moving the libs under projectA (or another mavenized project project if you need to share them between modules) would do the trick.