We use gradle to build our Java projects, some are based on JDK7 and some on JDK8. I know of the org.gradle.java.home property, but it seems flawed to me.
If I configure it in '~/.gradle/gradle.properties' this will force me to use the same JDK for all my gradle projects.
If I configure it in '/my-git-project/gradle.properties' this will force me to put a reference to a local JDK installation in a shared Git repository. The path to JDK do not belong there.
What I basically would like to have is something similar to this in '~/.gradle/gradle.properties':
systemProp.jdk8=/my/local/path/to/jdk8
systemProp.jdk7=/my/local/path/to/jdk7
And under source control in '/my-git-project/gradle.properties':
org.gradle.java.home=$systemProp.jdk8
What's the best solution/workaround for this?
This is more of a process question than a Gradle or Java question. Ultimately, you have to force everyone to specify their various JAVA_HOMEs without being onerous. You have several options:
Command line: ./gradlew -Dorg.gradle.java.home=/path_to_jdk_directory
But, of course, now everyone has to type some hideous junk into their command line every time they run a build.
gradle.properties and check-in the path. Then, make everyone use the same path.
Not everyone's going to want to use the same path, especially if you have Mac/Unix and PC users.
2b. Instead of using an identical path, everyone could modify their local gradle.properties with their custom values, then never check-in their modifications.
Primary problem: someone's totally going to check-in their local values and screw up CI and everyone else.
gradle.properties.template check-in, everyone creates their own gradle.properties; put gradle.properties in your .gitignore
This might be your best bet. You have a template file that you check-in, but everyone has to copy it to gradle.properties and fill in their specific values. You'll need to setup your CI to do something similar, or check-in something like gradle.ci.properties and have CI use that. But, everyone only has to do this once instead of once per build. Unfortunately, they will have to update their personal file every time the template changes (unless you write some code to do that).
We cope with that problem like this:
The one who starts the build is responsible for properly setting JAVA_HOME
On developer machines that may be brittle. But it works perfectly, if you build and deploy from a dedicated buildserver.
I am experimenting with my first GWT app that uses GIN. I am essentially mimicking the exact same source code example found in their Getting Started tutorial. At the end of that tutorial, the author mentions that you need to supply the the GWT compiler with a classpath pointing to the compiled Java binaries. The example they use for doing this is done using an Ant target.
Although I will have an automated (Ant-driven) build that also emulates this build task, I want to be able to run/debug my GWT apps from inside of Eclipse without having to kick off an Ant build.
So I ask: when running my GWT app inside Eclipse (Dev Mode), how do I configure the GIN library to point to the compiled classes? Thanks in advance!
All you should need to do is add the gin.jar (and dependencies, probably just guice.jar) to your project's classpath.
It should not be required to copy these to WEB-INF/lib/, though depending on your server setup, you may require guice.jar there, but never gin.jar.
I have two computers, and want to share a java project in eclipse by saving and opening the project from my USB stick.
But I can't seem to get it to work very easily.
What steps do I need to take to set this up properly?
These things should be discouraged. My advice is using an SCM (Source Control Management)
like Git and keep a repository on the external drive (if using Git, a bare repository on the USB stick and a local repository on each machine). At the beginning you'll spend quite some time getting used to, but it will pay soon (you'll have descriptive changelogs and disaster recovery facilities)
Eclipse has support for Git via Egit, and for SVN builtin.
When you share a project like this, you may encounter troubles related to classpath references to external JARs, which may be overcome by
using a lib/ folder (thus keeping the JARs under version control)
using an environment variable like $JAVA_LIB
using some dependency manager like Maven or Ivy (again, there are lots of stuff, but will pay even in the short term)
For existing project that you don't want to put under version control, you can simply (again, there may be missing library errors) use the menu File > Import > General > Existing projects into workspace
I strongly recommend using a cvs, svn, or other version control repository for this purpose. Trying to manage it manually is eventually going to bite you.
But if you insist, the best way I know of is to create the project in Eclipse by un-selecting the Use Default Location option in the New Java Project wizard. That allows you to specify an external location for the project contents, in your case the USB drive. You'll have to make sure of a few things:
that the USB drive is always plugged in while Eclipse is running.
Refresh the entire Project each time you move the USB drive from one computer to the other.
Any references to JARs are either internal to the project (eg, in a /lib folder inside the project) or use Classpath Variables.
It's going to be quite tedious, which is why it's always recommended to not try this and use a version control repository instead.
I do this. With some projects I have in SVN or GIT. For me it's more important to have only one eclipse and one workspace. Unfortunately this limits to Windows (or one os). The trick is to ensure that it always has the same drive letter. I tried with subst first, but I forgot to often. But using the drive manager from Windows everything works fine.
Can me and my other friend programmer work on same project with Eclipse synchronizing it, or we need to share the src every 10 minutes?
You can certainly use the "Team" menu, which gives you access to version control systems. I would recommend Git or Mercurial (Distributed Version Control Systems).
EGit/JGit are now part of the mainstream plugins: you can install them using the "Indigo" repository (assuming Eclipse 3.7) in "Install new software...".
Centralised Version Control Systems (like CVS or SVN) also have plugins for Eclipse. They might, however, make it more difficult to branch and merge conflicts when required.
You are looking for a version control system (VCS) like CVS, SVN, Git, Mercurial, etc.
It seems like you are asking if Eclipse has support for sharing workspaces so that you and your friend can (in essence) cooperatively edit and run the same set of java files in real time.
Something like this - http://www.readwriteweb.com/cloud/2011/07/cloud9s-web-based-real-time-co.php
The answer is No. Eclipse doesn't support this directly.
However, there is an Eclipse plugin / project called Saros that claims to do this. And the Saros site has links to related projects that may be relevant.
(FYI - the relevant search terms are "collaborative programming".)
This is what you need:
http://en.wikipedia.org/wiki/Revision_control
SVN or CVS - kind of version controlling system will help u to work together or u want to maintain your repository online then kindly check out https://stackoverflow.com/questions/59791/free-online-private-svn-repositories link.
I use SVN Notifier which sits in the system tray and notifies me every time the repository changes. And I can highly recommend it. It means you only update when there's something to update!
Alternatively you can set up a scheduled task/cron job to run svn update in the appropriate directory every hour/day/whatever.
refer this Microsoft article on setting up a scheduled task.
You want a batch file called svnUpdate.bat or something which looks like this:
cd C:/path/to/your/working/copy
svn update
Get the scheduled task to run this as often as you like (once an hour seems sensible)
Make sure you have the command line version of svn installed (I use SlikSvn) and available on your PATH (in a command window type svn and ensure it says 'Type svn help...' or similar.
I see reference of ant a lot but I don't get exactly what its meant to do? from what i've heard its supposed to compile your projects but can't i just do that by clicking Run->Run in eclipse?
Edit : I guess I should rephrase my question. I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line ) .
You may need additionally run test cases, unit tests, and many, many other process.
What ant does, is provide a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.
For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.
Connect to subversion server.
Download/update with the latest version
Compile the application
Run the test cases
Pack the application ( in jar, war, ear, or whatever )
Commit this build binaries to subversion.
Install the application in a remote server
Restart the server
Send an email with the summary of the job.
Of course for other projects this is overkill, but for some others is very helpful.
rogeriopvl is absolutely correct, but to answer your "can't I just do that by clicking Run->Run in Eclipse?" question: that's fine for a project that you're working on on your own, and don't need a repeatable, scriptable build in multiple environments.
If you're working on an open source project, however, or professional software which needs to be able to build on a build server etc, requiring a particular IDE to be running isn't a good idea.
Ant is used to automate a build process, but a build process is often much more than compiling. Ant has "tasks" that can be used to perform miscellaneous useful functions. You can create your own task to do just about anything by writing a java class and telling ant where to find it. You can then mix and match these tasks to create targets that will execute a set of tasks.
You can also set up a dynamic environment in which to build your application. You can set up property files to hold variables that can be used in the build process, i.e. to hold file paths, class paths, etc. This is useful for instance to differentiate between test and production builds where deployment paths, database instances, etc. might change. Ant also includes flow control (if, etc.)
Some things I've seen ant do:
Compile code
Use version control to checkout the latest version or to tag the version being built
Run sql scripts to build or rebuild a test database
Copy files from an external resource for inclusion in a project
Bundle code into a jar, war or ear file
Deploy a web application to an application server
Restart an application server
Execute a test suite
Static analysis, i.e. CheckStyle or PMD
Send email to a team to alert them to a build.
Generate files based on information from the build.
Example: I have a jsp in my app that does nothing but display version/build information. It is generated by ant when I run a build, and the production operations team checks this page when they deploy the application to make sure they've deployed the correct build.
In many larger companies (and likely some smaller ones), you'll find that production code is not built by the people who developed it. Instead, the developers may check their code into a source code repository and tag it. Then they give this tag to a build team.
The build team, in a separate (clean) area - possibly on some headless server (i.e. with no GUI) - will then check out the code and run a build script. The build script will be completely independent of the desktop environment/IDE.
This ensures that nothing which happens to be on any one developer's computer is "polluting" the build. (Or, more likely, nothing outside source control is required for the system to work!)
So most software you use will never, ever be built from a developer's desktop.
PS. You might also want to look at the idea of Continuous Integration
The short answer is that Ant is a great way to create a complete project build that is independent of any particular tool any developer may be using. Without an independent build, things can go haywire quickly - especially for large project teams.
And now for the long answer... I have been brought into several projects without any sense of an independent build. On one project, there was one guy who was not a developer that was tasked with building and deploying the software. He had created 147 separate windows batch files to compile each EJB, each servlet, and each client component. There was no error checking for this build. All log messages, including error messages went to standard out. It was up to him to manually recognize by reading this log which exception or message printed was a normal and which message was an error. He also had to deploy this software he just built. Deploying was equally as complex since there were several load-balanced tiers. Each module had to be placed in the right place manually with options setup to match downstream and upstream tiers. Building and deploying this software took him at least 3 days using this method. Of course, only then could anyone determine if the build "worked". Usually, after this period all the programmers would scramble to debug the build. Programmers would say my module works fine in my IDE. I just click run like this, see?
Indeed, the individual software modules usually worked, but the build and deployment was horribly ineffective. And just as bad, it was equally as difficult for anyone to deploy a build to more than one environment. Management would say, ok you now have this build working in our regression testing environment. Now deploy that same build in this other environment so the sales guys can demo up and coming software. That should be simple to do, but it also took at least 2 days, followed by a "debugging the build" period. Builds and deploys were never simple and never accurate. It really slowed the project down.
Anyway, we replaced this entire procedure with a complete Ant based build and deploy mechanism. The end result was that a complete build could be created and deployed in less than 30 minutes, completely automated. The QA guy managing the builds and deploys could keep a whiteboard of which environment had which build deployed to it and which group was using that environment. This was something that was just not possible with the old system.
Ant is for automating software build processes:
http://en.wikipedia.org/wiki/Apache_Ant
Ant allows CRISP (complete, repeatable, informative, schedulable, portable) builds. You can find great info on it in this presentation by Mike Clark and in his book, Pragmatic Project Automation.
Ant is a build tool, akin to makefiles (albeit with a very different syntax in XML). If you're only using Eclipse it's fine to stick to that and you can always convert an Ant build file into an Eclipse project (Eclipse's launch configurations are then, if I remember correctly, the equivalent of Ant's build targets).
If you want to deploy the source code of the application and allow others to easily build or set it up, automating that using Ant is probably not a bad idea. But it's usually not a consistent experience for users or at least I haven't seen much consensus on what targets should be there and doing what so far.
Ant may also be used for regular automated builds (you wouldn't want to hit Run in Eclipse every night, right? :-))
If there's one close to you I think you'd get a lot out of CITCON, the Continuous Integration and Testing Conference. You get to talk with lots of people about the benefits of automation applied to building and testing software.
Basically people use Ant (with other tools) to automate everything they want to have happen after a commit. The basic advantages of such automation are faster, better and cheaper.
Faster because things happen right away without waiting for a human to get around to it.
Better because computers are really really good at doing the same thing the same way every time. (Humans tend to suck at that.)
Cheaper because you have fewer mistake and the mistakes that occur are caught sooner and therefore cheaper to fix.
You are also referring to the ""Export ant buildfile".
If you write your own Ant script for building your application outside eclipse, you can write your own targets that use the Ant task to delegate to the generated build.xml.
Also, you can configure a project's 'builders' (project properties ยป Builders) to run any script (ant or otherwise) you want when you build the project, manually or automatically.
Joel (Spolsky) has a great article on "The Joel Test." Many of them revolve around being able to do important things often, quickly and reliably. One of those things is your build.
Eclipse is using ant for building, running, deploying, ...
"Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code." (from link text