Before creating and posting my own git repos of the sample/demo code does anyone know if the ATAP Tango dev relations team is posting the demos and dowloadable code on any accessible git repos?
Otherwise I'm likely to investigate setting up my own so I can look at diffs over time (especially to any of the shared lib code).
It depends on what sample, or demo, code you're looking for. All of the C and Java sample code can be found on a public github repository, which is linked below.
Unity sample code is released in the form of the SDK package with each new Tango developer release. While source code for Unity samples will be available for each major release, demos will not. Binaries for all demos can be found on the official developer page, linked below.
Official C sample repository -> https://github.com/googlesamples/tango-examples-c
Official Java sample repository -> https://github.com/googlesamples/tango-examples-java
Official Unity SDK package and binaries -> https://developers.google.com/project-tango/downloads
Official release notes and known issues -> https://developers.google.com/project-tango/downloads
Cheers,
Chase
I did find two projects under github:
https://github.com/googlesamples?query=tango
Related
I am looking into eman functionality. Can anyone please suggest me link to some tutorials or example which would help me understand this feature.
As outlined in Why eman project is dropped from opendaylight oxygen release., the eman project is no longer actively maintained so you're most likely on your own although you could try the eman-dev list. Other than that there's the project page https://wiki.opendaylight.org/view/EMAN:Main and/or whatever online docs were provided in releases prior to Oxygen.
I cannot se any docs or code on github with that integration.
Branch have integration with react-native, cordova, android Java, IOS and others tools, but i cannot see any documentation or lib related to NativeScript on the branch.io site or account on github.
My app is written in NS, can i use branch on my project?
Currently Branch does not directly support integration with Native Script. You may still be able to integrate your application with Branch native SDK by building a bridging header or something similar, but Branch will not be able to provide any guidance on the integration.
I've read a whole bunch of articles and SO questions on importing 3rd party go packages which all seems straight forward, but what I don't understand is that none that I have read make any references to versioning. In Dartlang there's the pubspec file that defines your package including its version and its dependencies including their required versions. What if I do a go get github.com/gorilla/sessions and write my app then 6 months later I have to clear my directories and re get everything again, in which time that package has been update and broken backwards compatibility with my code that was using the older version?
The official version, from the GO FAQ:
If you're using an externally supplied package and worry that it might change in unexpected ways, the simplest solution is to copy it to your local repository. (This is the approach Google takes internally.) Store the copy under a new import path that identifies it as a local copy.
There are many alternative to that approach, mainly based on declaring the exact version of those projects you are using.
See for instance "Dead Simple Dependencies in Go -- Keep it simple and keep your sanity." (based on emil2k/vend)
The main different options for Go Dependency Management are listed at:
"Go Package Management -- A summary of dependency management in Go"
(And its associate GOPM mailing list)
Update July 2015:
the official vendoring approach from Go team is discussed here.
an alternative go build tool called "gb" is proposed at getgb.io by Dave Cheney.
Update Q4 2017: as mentioned below, go dep is the official tool for pinning version of dependencies (even though that pinning approach is not without criticism: see "The cargo cult of versioning").
It should be merged into the toolchain when Go 1.10 development begins, according to its roadmap.
Update Q2 2018: go dep has been replaced by go mod (modules) in Go 1.11, following works on vgo.
I use dep as a dependency management tool for golang project. Please use the following link dep tool for more info.
dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile.
dep was the "official experiment." The Go toolchain, as of 1.11, has (experimentally) adopted an approach that sharply diverges from dep. As a result, we are continuing development of dep, but gearing work primarily towards the development of an alternative prototype for versioning behavior in the toolchain.
Current status: January 2019
dep is safe for production use.
Note: I am not asking how to use Google Code's SVN repo as a Maven repo :-)
I'm looking for the simplest / most reliable way to automate uploading the built artifacts of a Maven project to a Google Code 'Downloads' tab.
I've found 4 different Google Code Maven plugins that claim to do this, but would appreciate any advice on evaluating them as fit-for-purpose, because they all seem to be in various states of inactivity.
maven-googlecode-plugin (Last commit: Sept 2009. Latest version: 0.0.1-SNAPSHOT)
gcupload-maven-plugin (Last commit: Jan 2009. Latest version: 0.9)
maven-gcu-plugin (Last commit: Oct 2010. Latest version: 1.1)
maven-googlecode (Last commit: Feb 2008. Latest version: 2.0, but labelled 'test')
In addition to these 'level of activity' clues, some of them offer their releases on the 'Downloads' tabs, which might be a good sign from an 'eat your own dogfood' viewpoint; but as these are supposed to be Maven plugins, having them available in Maven Central might inspire more confidence.
Anyone care to comment (perhaps even the owners / committers of these projects) ?
Thanks!
Update:
I have test-driven each one of these in turn and could not get any of them to work as advertised.
Two of them are still configured to upload to a Google Code URL ending in /files, whilst another claimed to work and reported success, but the artifacts did not appear in the 'Downloads' tab. With the last one there appeared to be no released code which could be referenced as a Maven plugin.
I have since emailed each of the project committers to see what can be done.
If you are not averse to looking beyond maven plugins, google code has a SciptedUploads documentation, which seems to provide a python script and an ant task for doing this.
You may want to start reading the comments bottoms-up to see challenges using them, if any.
I got to this page by clicking on the link to "Create a New Download" for my google code project and clicking on the "Tip".
I always wondered why google didn't offer a Maven repository for each project by default.
Digging further, I discovered the following deprecated project:
http://code.google.com/p/google-maven-repository/
It appears the recommendation is to publish releases to Maven Central. This makes a lot of sense, as it certainly simplifies the discovery and integration of your project with other open source.
This movement towards Maven Central is a welcome and increasing trend in Java projects. Large projects like Oracle, Spring and JBoss are now publishing their releases there.
Just wondering on the recommended process of checking in an output of a project or solution post a successful build.
For example the Build relates to a common library. Post a change I want that to be checked in to a known location so other solutions can reference.
Some examples might be
Custom Workflow activities
Invoking TF exe directly
I would not check an output in. Instead, I would move it to a well-known location, probably a file share.
I don't do this currently but plan to investigate NuGet as a solution to this scenario. MSDN has some articles showing how to incorporate NuGet into your projects and host a private gallery of your own NuGet packages. MSDN has examples of a build that compiles your common code and then packages it and updates it into your private NuGet gallery. Then in your projects you would consume the NuGet package of the common library you wish to use.
Main MSDN article describing this:
http://msdn.microsoft.com/en-us/magazine/hh781026.aspx
Other resources:
http://nuget.org/
http://nugetter.codeplex.com/
Have a look at this post from Ewald Hofman, it updates certain files and checks them in using a custom activity. You could use the same process. But this involves customizing the build process template and deploying custom build activities to all build agents.
But you might also want to investigate the free AIT Dependency Manager which can download the latest specific version (can filter on build outcome or quality) of one build from the buildserver as reference to another build (also inside Visual Studio). This is a lot more flexible than constantly checking in the build output and allows you to have your dev branch to always get the latest (unstable) version, but your release branch to always get the latest well tested and approved version.