I have seen that if I right click on a project in Eclipse and choose to run it on a server, then I can see output which means the project is running.
If everything is working fine without Maven, what's the point of using it. How is it different than simply running it via eclipse?
Maven is a build tool (build manager, in fact), similar to ANT. The main job of any build tool is configure the project, compile using required projects and do the final packaging. A build script in your project gives a blue-print of project's deliverable structure. This frees you from any configurable dependencies on specific IDE like Eclipse. All you need to know is the standard command to perform the build and you can build your code almost anywhere.
Now, back to your question, why wouldn't do it in Eclipse?
For a simple project and small team Maven is an overkill. You can easily communicate the configuration, IDE to use, and instruct any special steps to be taken. In big projects, however, there exits lots of loosely coupled dependencies. To start with, there will be different settings for developer machine build, test build and production build. There are requirements to run automated test, integration tests, store the build package (artifact) to a commonly accessible repository, update versions of various modules.
Obviously, if all the steps mentioned above is done manually there are chances of missing a step. Moreover, the manual process is time consuming.
Ideally, you should prefer a tool which fits the best for you. If you think that you're able to achieve what you required without Maven, it makes sense to not to use Maven/build-tool just because everyone uses it.
It is suggested to study automated deployment, this will give you bigger picture on what all the stuffs that you can do with build tools. And if you do not feel that it adds any value to your current process, you probably don't need Maven or any other build tool right now.
Your question does not make much sense. Do you expect your users to access your application from eclipse? If so that is a very strange set up in my opinion.
Perhaps your question should be about how to build your project. Maven provides you a way to centralize dependency libraries across the enterprise. It lets you automate your build process (most likely in conjunction with a CI server like hudson, cruise control, etc). It lets you automate your unit testing. Maven makes the packaging of app very easy to do. A developer does not have to follow arcane set of steps to package an application. You add the right plugin and maven takes care of it as part of the build life cycle. All of this magic can happen because of the principle of convention over configuration. There are many more benefits, I just named a few.
Maven is not replacing how you run the app, rather how you package the app, automate that process, and manage the dependencies of your app.
Some links on why someone should use maven:-
Why maven ? What are the benefits?
why I use Maven
Why you should use Maven
Use Maven
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.
We want to use Hudson/Jenkins to build our project which is currently realized entirely in Eclipse. From what I can tell, there are various ways to go from A to B, or E to H, as it were: export as Ant script, export as Maven script, export as Runnable JAR while creating an Ant script for that, etc.
All of the above seem to have in common that between "This runs in Eclipse" and "Hudson produces something that runs" there are multiple steps which are independent, for example, you can change your project, commit to SVN and trigger a Hudson build, but unless you specifically remember to "Export as Ant Script" in between, it will fail.
Is there a "one in all" solution ? I'm not worried about the amount of clicks, but instead about the various steps in between that, to make matters worse, are only needed sometimes. In short: I am looking for something that goes from "I can click on the 'Run' button and it works" to "Hudson produces something that works" without every developer having to remember every optional step in between.
Ideas ?
Edit: All of the answers so far seem to suffer from the same issue: it's all parallel development. You have your Eclipse Run Configuration, and you have Maven/Ant/Whatever build. If you change your run config, you have to then remember later to change your Maven/Ant/Whatever build, commit it, and then HOPE that all other developers notice the change to the Maven/Ant/Whatever build during their daily SVN Update, manually open the file, inspect the changes and then duplicate those changes in their own run configs. That seems like it's just begging for bugs and mistakes, isn't there anything that's properly integrated with the Eclipse Run Configurations ?
Hudson can build Maven or Ant projects, so the first step is to get a reproducible build with either tool, which you only need to set up one time. Then you need to take that pom.xml or build.xml file and actually commit it to Subversion. This is necessary since Hudson won't open Eclipse and will instead use the command-line to execute a build.
Then you can setup a new Hudson job that will watch Subversion for any changes. Your developers can use their normal workflow, where they use Eclipse to do builds and commit changes to source control when they're ready. Hudson will see it and pull down a fresh copy of the code base, and then will do its own compile and will report back any problems.
Personally I prefer Maven2, since I know Hudson has solid integration with it and will do things like run your JUnit tests. Eclipse used to be painful with Maven, but now there's the m2eclipse plugin.
I'd try http://www.ant4eclipse.org/.
It allows you to build your eclipse project from an ant file. From the first paragraph here: http://www.ant4eclipse.org/node/6 it sounds very much like what you want. With ant4eclipse ant will access your eclipse project and then it should be able to build through Hudson.
The aim of the ant4eclipse project is to avoid (or at least: to reduce) the redundancy of Eclipse and Ant configurations. More precisly: it consists of Ant tasks that are able to read and work with some of Eclipse's configuration files.
Migrating to Maven, Hudson has great first class intergration with Maven.
Maven 3 + Archiva makes a very potent build system. Of course there are other Repository Managers but Archiva does just enough for what I need.
Once you get Maven, you really wonder how you did without it up until then. A dedicated private Repository Manager helps this greatly, that is why Archiva is important to the mix.
I am writing a web application with Maven in the Eclipse IDE, and use Tomcat servlet container.
So, I run Maven like this: mvn clean compile. It is reasonable that after this operation I must re-run Tomcat so it can reinitialize the context (Sysdeo Tomcat launcher helps a lot).
The problem is Maven execution and subsequent Tomcat re-running takes noticable amount of time (like 10+ seconds for Maven and 20+ sec. for Tomcat, because of logging, O/R mappings, etc.) every time I do it.
Is there any automated and more faster solution for these operations? As I see it, a way better solution can be moving re-compiled classes only to the target dir.
Is there any automated and more faster solution for these operations? As I see it, a way better solution can be moving re-compiled classes only to the target dir.
Well, the question is why do you run clean each time? Doing incremental compilation would already speed up things a lot.
Update: I agree with #Carl about Eclipse WTP that provides very good support of Tomcat (I don't really see the added value of the Sysdeo plugin nowadays). Using Eclipse WTP for development and running Maven before to commit the changes to check that you didn't break the continuous build is a very typical workflow. And both the maven-eclipse-plugin and m2eclipse (the two alternatives for Maven and Eclipse integration) support the WTP i.e. can get your project recognized as a dynamic project than can be Run on a Server.
You may want to have a look at JRebel. It reloads your classes in a running tomcat, so your changes are near instantaneous. I haven't used it much, but it appears to solicit good comments.
Maven does two things: Dependency handling and build management. I usually find Maven's dependency management a big time-wasting annoyance that I usually don't need, so I do my build management with ant.
At the price of a hand-tuned build file, ant gives you very good control over which files go where when. If you copy newly compiled classes to your WEB-INF/classes directory and touch web.xml to trigger a reload, you don't have to stop and restart Tomcat. This brings my compile/reload time down to around one second.
This is how I prefer to work. Some Maven fans will disagree violently.
EDIT: That said, there's another method that allows me to skirt the build issue completely: I develop in Eclipse using the WTP functionality that's included with the Java EE developer's edition. When I make a code change, I simply hit Ctrl-S to save the changed file and Eclipse automatically copies the newly compiled class into the running Tomcat, so I can then immediately refresh my browser and see the newly changed Web app running. Thanks to Eclipse's incremental compilation, this method probably is probably unbeatable in terms of edit/run cycle time. Of course if you really need Maven then this is not an alternative.
There is Maven tomcat plugin can help you, you just execute "mvn tomcat:redeploy", and maven compile the source, package it and deploy it to your configured tomcat, see tomcat plugin for more information.
Eventually, I've solved that by using Eclipse feature called «Build Automatically» (Project → Build Automatically checkbox).
Every time you save a resource, Eclipse compiles it and moves .class file to the output folder.
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.
We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.
I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.
Write a Hudson plugin which
understands projectSet.psf's to derive
a configuration and build it.
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.
I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.