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.
Related
I'm looking at an application and it has the following statements
executeProcess("java.exe -cp { 500-characters worth of stuff } someProg");
This is done several times through the program, since this application launches other programs to perform certain tasks. The previous developers decided to just copy and paste again and again as long as it works.
The problems I have with this are
it's redundant. That classpath is copied a dozen times. I can refactor it and move it to a single location, so that's easy to deal with for now and makes life easier for the next guy that might have to maintain this thing.
everytime a program adds a new dependency, I need to update the class path. All of our libraries are stored in a single folder (with subfolders for different libraries), so I can't just use wildcards because they do not check recursively: -cp "path/to/lib/*
Currently I'm the only one maintaining our entire tool set, so if I add a library, I know what to do to make it work, but in general this seems like bad practice.
What are some ways to make these process calls easier to manage?
You can add it as an environment variable and then refer to that, if
that is feasible.
As you already suggested, you can refactor it to a
single location.
I have had good experience with using ant and maven-ant-tasks for launching java applications without managing the classpath manually. Of course, in order to do that you would have to use maven for build/dependency management or at least install your jars to a local nexus instance.
The end user needs to checkout a maven project that declares a list of top level runtime dependencies (transitive dependencies will be resolved automatically, for libraries that are maven projects) that also contains some ant scripts with targets that execute the application.
You will have to figure out how the java application will know the actual location of the ant scripts (an env variable maybe?), but it's an extremely superior solution to manual jar and classpath management.
This might look like a gargantuan task - and it kind of is - but the benefits of transparent jar version and classpath management are so huge, that I cannot even dare to remember how we did it in my current company before setting up the infrastructure for this.
Also, note that apart from installing ant (with maven-ant-tasks) and maven (with nexus configured) everything else you need to launch is on the SCM.
In my current project we use Java and Coq. We have a continuous integration set up, using maven. We want to check coq files as part of it. I.e. we need:
Download and install coq locally if it isn't installed (like maven does with frameworks like gwt, etc)
Check that coq files are correct
Did anybody try setting up this? How can this be done?
I don't recommend automate that from your CI Build. Instead, it looks more like a Machine Configuration Dependency.
In cases like this, it is worth it to rely in tools like Puppet and Vagrant in order to ensure your Development Environment conforms to a given context, so your code needs to deal with this as either a premise or - better yet - ensure it is available in your PATH.
I know this is a really old question, but I have a different answer.
I have a similar CI setup that needs to install build tools. In some cases, such as on bitbucket, I pre-build a docker image containing the tools and update the build configuration each time I update the tools. In bitbucket, this works well because the source code of the package being built points to the particular docker image version to use to build it, which ensures that older builds can still be built, assuming the older docker images are retained.
Otherwise, I just script the installation of the tools using wget or curl to download as necessary.
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'm compiling using android tools without eclipse.
I compile launching "ant debug" from command line.
I have found many many instructions around the web about how to remove with annoying warning, but I haven't been able to make any of them work.
I've tried -D option, I've tried randomly tweaking build.* files, I've tried exporting an environment variable... nothing.
I guess some of these methods just don't work, and some others would work but I've been doing them incorrectly. Anything is possible and I can't stand it any more: any advice on how to do it?
I had the same problem. This is how I solved it:
When I launch ant release, there is this line in the output: [setup] Importing rules file: tools/ant/ant_rules_r3.xml. I edited ant_rules_r3.xml and replaced "ascii" with "UTF8".
I have android-10 SDK kit, this is how I fixed an encoding warning while building a project.
* create c:/myproject/build.properties file
* override default ANT variables
## Override default ANT properties
java.encoding=ISO-8859-1
While it is certainly possible to tweak the system defaults in the Android SDK, such attempts may lead to unpredicted and non-standard behaviour of ANT. Some other bit of the system may expect the default behaviour of ANT or an update will undo your changes. Also if you attempt to compile the project on a different system such as a build server or a team member's computer, you will need to remember to tweak every system involved. As such system tweaks should be avoided and are not recommended.
ANT build process accepts per project overrides for system wide defaults. While it does require an additional file for every project, it is likely to give more consistent build behaviour on all development platforms and ease development, diagnostics and maintenance.
I am using ANT 1.8.4 and providing a build.properties file as suggested by Whome didn't work for me but it is a step in the right direction. I had to create an ant.properties file (for every project) and provide overrides just as Whome suggested.
It is however a bad idea to provide these overrides in any other file, such as local.properties or build.xml files. These files are created and modified by the android tool.
I do recommend the reader to read the build.xml file as it is well documented and provides excellent hints and instructions on how to use the Android ANT build system.
The next interesting bit of reading is the root ANT build script located in android-sdk/tools/ant/build.xml. This file will list all overridable properties such as:
java.target=1.6
verbose=true
But the encoding is set just as it was previously suggested by Whome:
## Override default ANT properties
java.encoding=ISO-8859-1
For the swedish character set, I did as fhucho suggested. But I had to use ISO-8859-1 instead of UTF-8. So maybe it is better to use ISO encodings instead.
Anyone who is looking for a solution, setting the following in the gradle.properties solved it for me.
org.gradle.jvmargs='-Dfile.encoding=UTF-8'
I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.