So I installed Apache Netbeans. Installed some of the plugins and instead of just seeing the Java folder in the categories when I want to create a new Project, I see this:
What is Gradle, Ant, and Maven? I am not familiar with Java and wanted to study the language, but I have no idea of what these are.
I keep seeing that I need to have certain plug ins installed and active.
Here they are.
Ant, Maven and Gradle are Java build tools. You don't really need to know the exact differences though.
Java with Ant
The "Java with Ant" option uses NetBeans' own internal project format (based on Ant). In older NetBeans versions this category was simply called "Java"
If you don't need to share your project with non-NetBeans users, use that option.
You will have to manage dependent libraries yourself (download, add them to the project) unless you are only using libraries and frameworks that are bundled with NetBeans. The turnaround times (the time it takes between you hit "Run" and the application actually starts) are the shortest with this option, as Maven and Gradle add substantial overhead to that.
Java with Maven
Maven is a standardized dependency and build management tool. A project defined with Maven can be used by everybody else as it automatically manages (and downloads) any dependency.
Use that option if you know you need to share your project with other people (e.g. hand it in your school or university).
Java with Gradle
Gradle is yet another build tool, which also manages dependencies for your and has more flexibility than Maven. However the build scripts are less standardized than in Maven. But that is also a good option if you know that you need to share your project with other people.
Unless you are using NetBeans 11.1 (which is currently in Beta) I would not use this option as Gradle support in older versions is not as good as Ant or Maven support.
You might want to go through the tutorials on the NetBeans homepage:
http://netbeans.apache.org/help/index.html
Related
I am new in Java and I am wondering what builds a java project if it is not Maven or Gradle.
In an IDE, you can also compile your java project and you do not need to use a Maven. Does it mean that such IDE (IntelliJ for example) has an own build tool behind the scene that is used for downloading all dependencies, running test and all that stuff?
Almost any project that grows past a few files requires a build tool of some sort. In the Java world Maven and Gradle are common with Ant and Ivy being somewhat less used anymore. Other programming environments have similar concepts and tools.
The IDE may not require this and has it's own build environment. But once you leave the IDE you still need a way to build - for example, in a build pipeline in a CI/CD environment. So it's better to start with some sort of build tool up front. Additionally, if you ever wanted to change your IDE you no longer have the same way to build. By using a build tool you are consistent across environments.
While I highly recommend a build tool, most build tools (at least the ones I'm familiar with) don't actually compile, that gets handed off to javac in the installed jdk.
Setting up a more sophisticated project, e.g. building a webapp, can be done without any build tool, but you'll need to (either manually or with a script) do the assembly (e.g. moving files into the right locations, preparing the deployment artifact, etc...). Doing that "custom" is a righteous PITA, hence build tools.
In the olden days, every IDE had its own proprietary build system.
This meant that if you wanted to migrate your project from one IDE to another, you had to recreate the project from scratch, move files over manually, and reconfigure actions to be done during compilation, testing, and building. Some migration tools were built to automate this tedious work, but they were often imperfect or incomplete.
With the growing success of tools like Ant, Maven, and Gradle, the IDEs began adding support for users to choose those tools in place of the IDE’s own proprietary features. The IDEs eventually embraced these tools so well that now a Maven-driven project or Gradle-driven project can be easily moved from one IDE to another with virtually no effort and no modifications. You can even build your project without any IDE, just using the command-line interface to the Maven/Gradle tools.
Today’s freedom to easily move between IDEs eliminates the fear of vendor lock-in.
IDEs today still carry their own build technologies. But I believe they are rarely or never used nowadays by the bulk of Java developers. The open tooling provides all needed functionality.
I've been working on a Java project using Gradle in Eclipse that builds on my local machine and works just fine. I want the project to be available to a team of developers via Git, but after creating the repository and trying to build on a different machine using both IntelliJ and Eclipse, I'm realizing that there are some challenges. For instance, it seems like there need to be minor changes in build.gradle. Or in IntelliJ, JDK 1.8.0 must be specified for java.util.stream.
My goal is to create a project that allows a team of developers to simply clone the repository, use any IDE they want, build the project and begin contributing right away. Has anyone attempted to do this before with Gradle? What are some tips or insights? Is Gradle a poor choice for this? How can I standardize the build, libraries, etc.?
I have a project that is build using ant and now i am trying to convert into one that is build in eclipse.
The ant files describes different compiler versions for different course folders i.e few are compiled using jdk 5, few using 6 and still few using 4.
How can we configure the project in eclipse to use different compiler levels in eclipse for different folders in same project.
I noticed that they had this bug lined up in eclipse and they said to release it on 3.5 and i am using 4.3. So it think the feature should be there.
Such feature does not exist. You will need to create multiple Eclipse projects.
I would suggest that you think twice before making a change in that direction.
ANT might not be the best build tool, but switching to Eclipse is way worse as you tight yourself not only to an IDE, but also to a specific configuration of both your instance and your project, making it less portable and more fragile than before.
I would rather suggest that you split your project into different modules/projects and use maven (integration with Maven and Eclipse is ok for simple builds) to organize both you CLI and Eclipse build procedures.
Sourceforge.net has a filter for Java projects, but I'm looking for a way to narrow them down to ones that are meant to be built in Eclipse.
Edit I'm using Eclipse Metrics and Omondo plug-ins to analyze open-source Java projects. I'm looking for a quick way to find Eclipse open-source projects that can build quickly in Eclipse, so I can use these tools on them for analysis.
I presume that a project that is "meant to be built in Eclipse" is one that has an Eclipse .project file and other stuff checked into the source repository.
First, checking in Eclipse-specific stuff can a bad idea because it is easy to include stuff (e.g. build pathnames, preferences) that are specific to the developer. You then get problems if there are multiple committers ...
Second, this should unnecessary. Most of the stuff in the .project file can be generated when you import the project. If that's not possible, then the project should provide instructions for setting up the buildpath etcetera. (Note that if the project uses Maven, this is all taken care of for you.)
Third, any project worth its salt will include build scripts of some kind that allow you to rebuild without using any IDE.
Finally, any project that only supports building using Eclipse is excluding the significant subset of developers who use other Java IDEs.
Note that neither Maven or Ant builds require Eclipse to work. Both of these build tools can run from the command line, or from other Java IDEs.
OK. I understand your requirements now. You don't actually care what the project is ... or that it is sound / worthwhile project. You just need it for testing your plugin. (I won't comment on the "validity" of doing this. It depends on what you hope to achieve.)
I suggest that you install the m2eclipse plugin and look for projects with a "pom.xml" file. The projects don't need to be eclipse specific. The m2eclipse plugin automatically creates the ".project", ".classpath" and so on based on the "pom.xml" file. There's no need to exclude any particular version control system, because the m2eclipse plugin can import Maven projects that you checked out from the command line.
Perhaps the reason I stalled learning Java until now is because I HATE how Java handles external libraries. I'm stuck keeping them in one place, adding them individually, fixing problems with versioning and every time I move/rename them, and copying and writing the classpath over and over each time I release a Java application.
There has to be an elegant solution to all of this. I keep all of my libraries (regardless of task, platform, or other) in their own little folder inside a "lib" folder in my development folder, kind of like this:
Dev
-lib
+JS-jQuery
+Flex-Degrafa
-Java-Xerces
+Xerces-1.2.3
+More libraries
I can use either Netbeans or Eclipse for Java dev, but none of them provide a very streamlined (and not to mention idiot-proof) way of managing all of these.
A nudge in the right direction or an online article/tutorial on this would be greatly appreciated.
You can either use Ant + Ivy or Maven to manage your library dependencies.
If it is only dependency management you're after and you're happy with the rest of your build process, I would use Ivy, as it can unobtrusively manage your dependencies, leaving your existing build process intact. There is a plugin for Eclipse called IvyIDE that contributes your dependencies via a classpath container.
Maven 2 has a steeper learning curve but provides a much richer set of functionality for building your projects and Eclipse integration through m2eclipse or IAM.
Personally I use Maven as I have a large number of projects to work with and Maven is particularly suited to efficient development across lots of projects.
Have a look at the introductory documentation to see what works for you.
Ivy Tutorial
Maven Getting Started Guide
Netbeans 6.7.1's Maven support is quite good and comes out of the box with the IDE.
The Eclipse addon was frustrating enough that I gave Netbeans another try.
A third choice besides ChssPly76's options is to use Ant with the Maven Ant Tasks. I don't know if I'd call any of these solutions particularly "elegant," but they do spare you the need to manage your own lib/ directory and classpath variables.
If you're working on Linux you can install Java libraries with APT or RPM.
Otherwise, I normally check precompiled JARs into a lib directory in my project's version control repository and make sure the names of the JAR files include full version information. E.g. lib/foo-1.5.6.jar, not lib/foo.jar.
To avoid having to manually set the classpath before running your app, you can set the classpath in the Manifests of the JARs themselves to define the dependencies of each JAR file. The JVM will follow all the dependencies when loading classes.
Maven is often more trouble than it's worth, but the ability to open a maven project directly into IDEs such as IntelliJ is excellent. For example, IntelliJ will download all dependencies and have them available without having to run a build first, or an mvn command and then a project refresh. It also isn't necessary to re-generate the project every time a dependency is added. I work with a number of Eclipse developers who switched to IntelliJ for this alone.
However, one shortfall of Maven is that many libraries (or versions of libraries) are not available on public repositories. Therefore it is often necessary to set up a local repository such as archiva. In ant, it would just be a matter of adding it to the lib directory in the repository.
Maven can also attack when you need to do something that maven doesn't directly support via a plugin. What would normally be a few lines of ant can often turn into a morning's worth of work.
Finally, buildr is an excellent way of using Maven's dependency management and plugins, while also supporting ad-hoc tasks.