I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
Related
I have been trying to use GoClipse (0.8.1v2001409161333 - latest available from the goclipse_feature.feature.group) with Eclipse (4.4.2) on Linux (CentOS6.6) with GO (1.4.2-2.el6) installed via yum from EPEL and have only achieved partial functionality.
Intellisense appears to work fine for the built in packages but GoClipse appears to do something weird with it's directory structure that is different from the normal GO workspace layout. The existing structure under source control looks like:
$GOPATH/bin/...
$GOPATH/pkg/...
$GOPATH/src/externalsite/module/version/*.go
$GOPATH/src/externalsite/module/version/subdir/*.go
$GOPATH/src/me/module/*.go
$GOPATH/src/me/module/feature/*.go
When I try and use GoClipse it always appears to insist that the *.go files must be a peer of the bin|pkg|src directories. This means that I either have my *.go files at $GOPATH or tell GoClipse where main.go is ($GOPATH/src/me/module/main.go) and GoClipse creates the bin|pkg|src directories again:
$GOPATH/src/me/module/bin/
$GOPATH/src/me/module/pkg/
$GOPATH/src/me/module/src/
My GoClipse configuration has $GOPATH set appropriately (I have tried with $GOROOT undefined or set to the yum install location to no effect) and when creating the Go project from existing code specifying the location as $GOPATH/src/me/module/ (manually expanding $GOPATH)
Some resources that I have located do not appear to offer any advice on getting GoClipse to respect the proper go workspace structure and I am hoping someone can tell me how to do this.
The following resources might be of interest but they do not solve this difficulty:
How to run a GO project in eclipse with goclipse installed
https://github.com/GoClipse/goclipse
Indeed, goclipse.github.io/releases is the latest update site URL, so you should use the latest version (the URL did change several times since in the span of the previous year). The way Goclipse handles the Go enviroment has changed significantly since 0.8.0, particularly with 0.9.0, which allows creating an Eclipse project on a folder inside a GOPATH 'src' entry. (and other cases are handled better, especially with the builder).
Note: you will need to recreate your Eclipse Go projects after updating (0.10.0 had some internal, non backward-compatible changes).
You might want to consult the changelog for more details: https://github.com/GoClipse/goclipse/releases
I want to be able to work across multiple workstations synchronously jumping from one to the other without having to worry about committing.
I have windows personal and work desktop and a Mac OSX laptop. At the moment, I point my project to a cloud directory and have the local install of Android Studio pointing to a gradle offline cache in another cloud directory. This keeps failing as it tells me that the path to gradle is invalid. Which I understand because gradle is referenced in different locations on different machine (considering the differing file management system in MACOSX and Windows7).
Edit: When I try to open the project, it brings up the "Import Project from Gradle" screen. To which it has the option for me to select "Use local gradle distribution" and select the Gradle home directory. I pointed it to the cache directory, and it tells me:
Cannot Save Settings
Gradle location is incorrect.
Location:C:/Users/Username/.gradle
All my research (include these answers here, and here) suggest that VCS is the way to go. However, I don't see this as a solution to my problem. I'm not looking to version control, I'm looking to transition seamlessly across workstations. Of course I will still use Version Control System for the purpose of saving a working version of my code, or sharing it with other developers, but there has to be a better way when I simply just want to keep all workstations synced.
I come from web development, and I synchronise local environment on AMPPS across multiple computers without any issue. This meant I can transition from my personal desktop, laptop, and work desktop instantly. It frustrates me if I have to remember to commit every time I move around. If I have to do this 20 times a day, and it takes about a minute to do this, that's 20 minutes that could have been spent writing a couple of functions. And what if I forget to commit, then I get to work, or home, that would be a day wasted because I won't actually have the current up to date code...
So the question remains, is there a way to instantly synchronise Android Studio projects? How do I keep all my code base (ie gradle) in sync?
Ok thanks to the comments above which pointed me in the right direction.
Android Studio create some local files that are specific to the machine that you are on. Following on this principle, to sync the "source" files (files that are specific to your application only), you must ignore all these local files. This is similar to what you would store on github. I followed the answer for this question to apply the ignore rules.
Having ignored all the "local files", when I create a new project, the source files are synchronised across all my workstations. In order to establish a local version, I need to "import" the project first. Once it has been imported, "local files" will be created for that particular machine. From then on, I can "open" the project locally.
To summarise:
Set your sync to ignore files as per .gitignore or refer to this question.
Create a project on one of your workstation and save it in the cloud.
When you are ready to work on the project for the first time on another workstation, "import" the project.
Once the project has been imported, all local files should have been created.
From then on, use the "open" option to continue working on the project.
I hope this helps somebody else, saving hours on googling.
What files can be safely removed from CDT project and workspace before archiving or saving in a source control system?
Having MSVC experience, I tried to remove Debug and Release directories, this was really bad idea :(
Are you using an Eclipse plug-in for your version control system of choice? They seem to take care of everything (at least in my experience with the CVS and Mercurial plugins). If not, you'll need to tell Eclipse to refresh pretty much your whole project whenever you've interacted with version control.
The contents of the Debug and Release directories should all be autogenerated. If they're not, something's wrong.
Rather than what you can delete, turn it around and consider what you need to keep:
.project, .cproject and (if it exists) .settings
Your source directories
Your include directories
Any other human-created files at the top level e.g. Changelog, documentation
It may also be worthwhile looking inside the .metadata directory in your workspace root; for example, any launch configurations you have created are stored by default in .metadata/.plugins/org.eclipse.debug.core/.launches/ . (Although I have seen them inside project directories from time to time.)
I have been working with setting up TeamCity, and I have almost everything working with the exception of being able to compile VS2005 solutions that have referenced assemblies that are outside of the solution path. I have our SVN repository structured as follows
Root
Libraries
Project 1
Trunk
Project 2
Trunk
Project 1 and Project 2 reference third party assemblies located in the Libraries. This works just fine from within the VS2005 IDE and when calling MSBuild on the solution files since the HintPath for all of the references look like this:
..\..\..\Libraries\ThirdParty.dll
The problem I have encountered is that when TeamCity dies the checkout from SVN for Project 1 or Project 2, it places everything into internal directories that don't match the structure of the relative path given by the HintPath.
How do I go about clearing this up, either through a TeamCity configuration or configuring my solutions/directory structure differently? Either one will work for my needs.
Thanks!
If you create a separate VCS root for Libraries, you can use checkout rules to control where the files are placed in the directory structure so that it matches the structure on your local machine.
We set up a network directory with all our third party dlls. Then we mapped the directory to a drive.
That way the dlls weren't a part of our solutions and all projects just call z:\3rdParty\example.dll to get the assemblies.
Someone else on my team actually set up our teamcity, so I could be completely mistaken about how the problem was actually fixed or if we even had that problem initially :)
What i have done is to set the VCS ROOT of the project to the top level directory ("Root" as per your project structure). And detached the default project vcs root created by teamcity. After this you can create a custom build step by specifying your solution here "Solution file path: *" in build type "Visual Studio (sln)". Now it properly handles library references.
There is a drawback here in that, since the vcs root is at the top level, even unrelated check ins could cause your project to build and that may not be suitable for time consuming builds. Don't have a workaround for that yet.
CruiseControl.NET service needs to be restarted to pick up changes in the projects configuration files.
I find this very annoying, not sure if it's a bug or it's the way it works.
Is there any way to overcome this issue in people's experience?
If your projects are separated in a different file from ccnet.config, then you need to restart the service unless you touch the actual ccnet.config.
We use ENTITY with SYSTEM file reference in ccnet.config for our projects, so we're in the same boat. I'm happy to pay the price for easier project maintenance, as it's easy to script a restart:
net stop CCService
net start CCService
IISRESET
If you wanted to completely automate this, and had your projects under source control, then you could trigger an update and restart whenever your project files are touched.
There was a bug in CC.Net prior to 1.4.4 if you were using a pre-processor include it did not reload the configuration when an included ccnet.config file was modified.
That was a bug that I reported and it is fixed in CC.Net 1.4.4 and greater.
Also, keep in mind that if a build is running and there is a change to the configuration it will not take place until that build is in an idle state.
How are you updating your config files? By hand? Mine always recognizes and adjusts. Is your config file in source control and designed to pull it down and replace the file? This for me requires a kick. How I ended up fixing it was have my project pull it down to a seperate folder. THen I call ccnet.exe -validate on it to make sure it is well formed, then I copy it over ontop of the current config file. CC.NET recognizes the changes and loads in the new config
Exceptions: If cc.net is currently running a project, it will not recognize the changes till that project has completed.
If your ccnet.config has errors, it will not ever recognize the changes and keep running the old version it has stored in memory. (However when CC.NET does restart it will try to parse the error filled config and choke.
Hope this helps!!
Do you mean you are using linked files, that is the ccnet.config file has links to the independent project files.
If so then they are not picked up, it's mentioned in the documentation that it doesn't watch the sub-files.
Internally we have modified our CruiseControl.net so that our ccnet.config is optionally a directory - and we can drop shortcuts to our project config files into that directory. We put watches on the directory, the files or shortcuts in the directory and all of the targets of the shortcuts. That means we have our project config files in ClearCase and just drop a shortcut into the ccnet.config directory.
I've just spent half a day or so moving from 1.2 to 1.4.2 dropping our changes into the new version for our internal use. We don't own our code, our client does and so it has to stay internal :(
I have never experienced this. Whenever I change the configuration files, the CruiseControl.NET service seems to automatically re-read them.
I'm using Version 1.3 of CC.NET.
Update:
In the service's config file (ccservice.exe.config), there is a setting to enable/disable watching the ccnet.config file for changes:
<add key="WatchConfigFile" value="true"/>
Make sure this is set to true.