I've had my eye on Gradle for a while now and am 99% convinced that I want to switch my builds over from Ant to it. However, before I invest this time, I need to be 100% sure that Gradle can do everything my Ant/Ivy builds already do (I can't lose any functionality):
Run code coverage tasks via Cobertura/JaCoCo
Run some Python scripts
Checkout/commit to a SVN repo
Run AnalytiX CodePro Ant tasks
Run pure Ant commands
Define my own tasks
I'm 99% sure about Python tasks as well as defining my own, but as for the rest I can't find any documentation on those sites that show they have Gradle tasks defined. If I can do all these thing I am bought and sold, otherwise I'm going to hold off until Gradle matures a little more. Thanks in advance!
You can use standard and custom Ant tasks in your Gradle build the way you are used to in Ant itself. Additionally, you can import existing Ant scripts. Targets of the imported Ant script get treated as first-class citizens so you can use them like any other Gradle task. As you can see you don't have to fully migrate your existing code to Gradle right away.
It's as simple as this:
ant.importBuild 'build.xml'
Gradle can call both built-in as well as custom ant-tasks, you'll be able to do all you need by relying on your old code wherever no other solution is available.
Related
Is there any way we can clean all/rebuild the projects in eclipse and run a jUnit test case every time we open eclipse?
I am developing an eclipse application. The scenario is that i want to schedule UI tests to happen automatically twice everyday. But i do not have an executable build as such. But have the full code base with me and i want to run some scheduled JUnit test cases(based on WindowTester) on it.
Any other ideas that you have is also welcome. :) Thanks in advance.
Ant requires a executable build to perform the tests on it from what i have read. :(
Regards,
Thomas
Tough Jenkins is opensource, Going for jenkins will be a good choice if you have more number of projects to manage. Jenkins dose lot more than automated test case and builds.
But, If you have a small code base and need to peform some specific tasks like
scheduled build and test cases, ant build will is much preferable.
In your case for running test cases,
Create a ant build script to build the entire project (How to write Sample Build scprit)
Create another ant script to read the jars and execute them using the tag (How to write Sample Test Build)
Write a bat file to call the ant scripts and Schedule build twice a day in windows scheduler available in control panel.
SO, this will compile, build your project and test it in scheduled time. Just trigger a mail from the ant script if test fails.
Since I am a big fan of developing OSGi with Bndtools. I want to use it for my new project request as well. But one requirement is that all build processes should be done by Hudson.
My question is how I can achieve that I can use Hudson connected to my Bndtools projects? Maybe someone has a step-by-step tutorial for me :) Furthermore, will Hudson use OBR to resolve the dependencies like Bndtools is doing? How should such a deploy process look like? Btw Bndtools has its one "Integrated Test" project environment where it starts an OSGi environment in the background. Will Hudson understand such kind of tests?
What is best practice to use as much as possible of Bndtools?
Thanks for any help.
Christian
I found a way by just iterate with a custom main build.xml through each projects build.xml. I works and it's nothing special.
Create a new build task in hudson and define there ant build steps rather than introducing and maintaining a new build file.
Create for each project an ant build step.
In my case I created a task named BuildAll which has several ant build steps in it.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.
Not long before I had digged into Ant and use it doing simple practice(compile,unit test,package).Now my usual work is under Eclipse for java development,the usual work can all be simply done through Eclipse' function:in-time compiling、click button to deploy、various wizard..
So I am wondering under Eclipse do we have a need for Ant.
And if it is, at which aspect should we use Ant along with Eclipse.
Building applications is not about just building them in your IDE. You need to setup an automated build and deploy method that can be run for, say, continuous integration and deployment. The built package has to be deloyed to various environments and finally production. You cannot build them out of your own box. You cannot build it out of your IDE. You need separate build system. That is where build tools like ANT come in.
Also note that the capabilities of IDEs for doing build, deploy is limited and that is not their strength. It is, however, possible to make use of ANT and its build scripts and run them out of eclipse. This way, you have a single set of scripts for both your local ( developer ) build and the main build process. With ANT being JAVA based, you can also suit your build tool to your needs by writing custom tasks etc.
Also, when you make use of something as standard as ANT for your build system, you can move to a different IDE like Intellij IDEA and still make use of the build system that you know.
Do you need Ant if you can build through the IDE? Of course not! You can see that yourself.
Should you still have a IDE independent build with standard tools? Of course!
Note I didn't say Ant. There are a number of build tools such as Maven or Gradle that are made to build Java programs. However, there are reasons why you want an IDE independent build system:
You have a Continuous Integration Server: You do have one. Right? If you don't get one. A Continuous Integration Server automatically builds your project (and runs every test) each time a change is committed to the version control system. It catches mistakes. It also provides an OFFICIAL BUILD. No more It worked on my machine! excuses. If the Continuous Integration Server can't build it and successfully run the tests, the software isn't good.
You have others who need to work with your project on a different computer in a different environment: The problem with IDEs is that its specific to your system. Someone else checks out your project, and they may be using a different IDE. They maybe have a slightly different setup. An independent build scripting language like Ant guarantees that they can rebuild your project as intended.
If you share a project with someone else, you need an independent standard method way of being able to build that project and to know exactly what is required for that build to work. IDEs can hide that information.
I am a benchmark tester using Ant everyday. Our environment has 7 test machines and 1 console machine. For each test run, the ant script updates the working copy, restarts the database, build the product and the Grinder with proper properties and deploy them to the machines, and starts them and the monitoring softwares. With the 1000-line-buildfile, I can just type in an "ant A B C D E"-like line in the terminal on the console machine. I don't think it's a good idea to do this in a IDE like eclipse or NetBeans or anything else.
Also, in my company's product, ant is widely used. We use ant to build sample data for the benchmark test; we use ant to update Tomcat which is going to be bundled with our product; we also use ant to build and run selenium tests.
What's more, when you want to release the source code, including the IDE project files is not a good idea because there are a lot of IDEs. And what if the user just want to get a fresh build from your latest code (if you don't provide nightly build)? Providing a set of ant (or other build tool) buildfiles is a good idea. With this, you can manage your classpath for the build.
The shortest answer here wold be flexibility. The IDEs may came with pre-defined functionalities and may even allow you to choose some options using wizards. It is like generating html with Dreamweaver or such tools. It will never be as flexible as the pure thing. For example NetBeans uses Ant underneath.
Quoted from: Netbeans: Build Tools
The default NetBeans IDE project system is built directly on top of
the Ant build system. All of the project commands, such as "Build
Project" and "Run File in Debugger", call targets in the project's Ant
script. You can therefore build and run your project outside the IDE
exactly as it is built and run inside the IDE.
Even after you use tools for that purpose you are most likely still to brush up. So, what I am saying is, what the IDEs do for you is only a subset of what you can do with the pure ant or maven( if you use it). For simple tasks such as compile and run, IDEs do pretty much a good job! But if you have a use case as complex as deploying on CI IDEs won't help you. You need the whole flexibility of your build tools.
Item 2 of the Joel Test is "Can you make a build in one step", but what is the best (or commonly accepted) way to achieve this? What are the pros and cons of using the IDE's command-line interface to do a headless build, as opposed to maintaining a build script that is completely independent of the IDE (e.g. using Ant or Maven in the case of a Java project).
I ask this question because I am experimenting with Maven, and was a bit surprised to find that even when using the m2eclipse plugin it's not really feasible to turn off Eclipse's Java Builder and delegate the whole build process to Maven while working on the project. It seems that if I want to migrate the project to Maven, I'll end up having to maintain two equivalent but different build processes, for example the command-line build will use the DataNucleus Maven plugin for enhancing JDO classes, while the IDE build will use the DataNuclues plugin for Eclipse; the command-line build will use the Tomcat Maven plugin, while the IDE will use Eclipse's web tools platform. This redundancy seems unfortunate.
I gather that NetBeans uses Ant for its build, which sounds like it would solve this problem. But unfortunately I'm using neither NetBeans nor Ant!
EDITED TO ADD: I found that I can set up a Maven builder in Eclipse with specific goals that call some of the Maven plugins that I'm using (e.g. in my case the goals "datanucleus:enhance process-resources" take care of JDO enhancement, resource copying, and native2ascii conversion). This leaves java compilation up to Eclipse, but still achieves some degree of integration with Maven.
The eclipse builder gives you intermediate and repeated building, but the "Joel Test" is really about being able to go from source to ready-to-deploy something in a single step. If you're using Maven, there's several ways of going about it - including just invoking Maven as a command line script from within Eclipse.
mvn package
Is what I most frequently used for a quick run through the whole build setup. You can extend Maven through the POM and inject some additional mechanisms if you want to. If you get a little more complex, it's often most effective to start using multi-module POM and maven setups to get functional tests integrated and running with the rest of the code.
Basically, let eclipse "do it's thing" with it's builders and take advantage of what it provides, but when you're ready to use the end product have it invoked from the command line through a continuous integration server (Hudson is a nice easy one to get and set up - free too: http://hudson-ci.org/). Presumably if you're looking at using Maven, you'll also have an instance of Archiva or Nexus set up as your DSL for the resulting libraries. You can have hudson invoke "mvn deploy" for regular checkin builds, or "mvn release:prepare && mvn release:perform" for when you're ready to cut the release (separate builds in Hudson work best for this)
You can do a headless build in an IDE. In eclipse you can execute an arbitrary shell command as an "External Tool". This is also true in IDEA and netbeans with a little effort. At the very least, this is a convenient test of the headless build that you should run whenever you make changes to the build configuration.
Also, I'd like to add that the build should be one-step as a minimum requirement. It should also be easy to set up and easy to debug. If it takes longer than an couple of hours to set up a new developers environment, then the one-step process is likely to be less than optimal. This is with the caveat that if you add or replace team members quarterly or annually this is less of an issue.