I have a bunch of Eclipse plugins and features, which I would like to build as part of a nightly (headless) build. I've managed to do this using a complicated setup involving manually specifying paths to Eclipse plugin jars, copying customTargets.xml, etc.
Is there really no simpler solution? Isn't there a way to just point out my Update Site's site.xml and say "build"; i.e. the equivalent of clicking "Build All" in the Update Site project?
Given that all the answers to this question are all 3-5 years old, I figure an update would be useful to others.
For those who want to add the building of Eclipse plugins to the CI process, I recommend they check out the Eclipse Tycho project. This is essentially a Maven plugin that allows you you to wrap eclipse projects within Maven project. With this we use Atlassian Bamboo to build our Eclipse plugin. This also allows us to use the Maven jarsigner plugin to sign our plugin files.
I've just been fighting with this problem myself. Are you using the productBuild script? Maybe putting your features into a product would help you out.
I am doing a headless build on a product configuration. The only script that I customized was to add some ant tasks to customTargets.xml to get my sources from SVN and to do a little cleanup on JNLP manifests after the build as I am using WebStart.
Then you only need to invoke antRunner on the out of the box productBuild.xml in the scripts/productBuild directory (in the pde-build plugin).
Check out Ant4Eclipse. I've used it to parse Eclipse's .classpath/.project files to determine project dependencies and classpaths. In combination with Groovy Ant Task, I have automatically built multiple projects in Ant using the Eclipse project files for build information.
A buildPlugin task exists, but I have not personally used it.
We are currently using PDE to automatically build features and our complete product. It works quite well. Make sure you use the right script for product build or feature build.
Eclipse Help on using PDE
EDIT: We've now migrated to Buckminster, which has an excellent command line interface.
You might look into buckminster and maven. There is a learning curve for sure, but they seem to do their jobs well.
We are using headlesseclipse, which can be found on Google Code:
http://code.google.com/p/headlesseclipse/
It works quite well, and can easily automate command-line building of plugins and features. However, I have not yet found a way to automate building of the update site via the command line.
Related
I'm currently using JUnit 5.1, but I want to switch to JUnit 5.5 (at least 5.4) to use new features of that version (mainly the #Order annotation), but I'm really struggling to properly set it up.
Unfortunately I cannot simply switch to a newer eclipse version, because I'm tied a specific version we use at my workplace.
As there is no JAR-download, i've tried to build it from source. The only guidelines concerning this are saying to build it with Gradle, but I don't understand how to do this.
What I tried so far:
- downloaded the repository as an archive (zip) and imported it to eclipse, which resulted in multiple projects and <1.000 errors
- imported the repository into eclipse (via import wizard), but failed to find a way to make a build from it
I was able to run some test with JUnit 5.4 features, but i achieved this by downloading different modules as JARs from some maven-repository I found in a JUnit issue on github and including them as external JARs into the classpath. This was very tedious because of the number of different JARs & the way they were organized in the repository folders.
To me this feels like a workaround, as I still have no idea how to solve the initial problem of building JUnit from source.
I'm quite new to eclipse and have a basic understanding of what Gradle is, but I've never used it so far.
I don't expect a detailed step-by-step guide on how to achieve this (although I wouldn't complain ;) ), but I'd really appreciate it, if you could give me an outline of how building from source is done in general and maybe additional references for me to read about certain steps (e.g. setting up gradle).
I'm about the setup an automatic (command-line) build for my Eclipse RCP Application.
I have found out the following ways to do it:
Buckminster
Using Maven with the pde-maven-plugin
Headless PDE Build
The problem with all these options is that they require me to create essentially a new representation of the information already contained in my target platform definition. For example in Buckminster, this would be the .rmap file.
In my thinking all the information to build the product should be already there when I have the following:
Plugin project with product configuration file (foo.product)
Target platform definition file (foo.target)
Therefore I would expect there to be a command like the following:
build-rcp-product foo.product foo.target win32
Is there anything like that which I may have missed?
With Buckminster you don't need to replicate the information in your target definition file. You can simply import the target file using the importtargetdefinition command. If all your dependencies defined in the target definition file, then in the rmap you define only from where to materialize your plugins (svn, git, maven, file system etc).
With PDE build, there is a filed request (Bug 266311) and it seems it is still not possible to utilize the target file directly but there are some workarounds suggested in there (which I didn't try, I am using Buckminster).
I use the PDE build and it's pretty simple. It essentially gets what it needs from the MANIFEST.MF file and the build.properties file.
The command to run it is more complicated, as you have to start Eclipse and point it to a few things, but it's very well integrated with the IDE. It does everything by making Ant scripts.
you can try tycho
here's a good start:
Tycho tutorial
Reference card
with tycho, all you need is a POM and you usually will not change this information, which is generated via maven
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.
I am starting getting used to Eclipse, but I have much more experience with Visual Studio. In Visual Studio it is possible to run auto commands after the build has finished.
Now I am creating a GWT project and several other projects at once in one solution (or workspace) in Eclipse. Some files which are compiled with the GWT project needs to be copied to another location when they have been compiled. I am currently doing this manually and would like to do it automatically. I am not doing it often, since the project works fine in debug mode (...?gwt.codesvr=localhost:9997).
But where is the location for executing a post build command for a GWT project in eclipse? Is it possible?
Just open project properties, choose 'Builders' item and click on 'New...' button.
Good question! I'm using Eclipse since about 2003, and I remember that I also wanted a functionality like that back then. However, I got so used to using ant for any serious build, that I completely forgot about it.
There is some useful ant integration in Eclipse (e.g. the ant view), and if you create your GWT project with webAppCreator you already get a few good ant targets you can build upon.
It would still be nice sometimes to have something more GUI-like to do simple multi-step builds with Eclipse. I haven't found anything like that yet, but it's absolutely possible that it exists, especially as a plugin.