researchgate / gradle-release Goto Github PK
View Code? Open in Web Editor NEWgradle-release is a plugin for providing a Maven-like release process for projects using Gradle
License: MIT License
gradle-release is a plugin for providing a Maven-like release process for projects using Gradle
License: MIT License
If I configure requireBranch to null or '' ('' is only a problem on master, not in Version 1.2), only master will be pushed ('git push origin master' is called). Only if I also set pushToCurrentBranch to true, the current branch is pushed.
When the project has some svn external link
The status contains some text but all files are committed.
For sample:
Running "svn status": [X doc
Performing status on external item at 'doc':
][]
Thanks.
The jars that are produced during the release have the version number of the project prior to removing the -snapshot.
I'd rather not tie the stability of my build to the uptime of an unknown website, tellurianring.com. While publishing to maven central would be ideal, it's a PITA. bintray (from JFrog) is a real easy alternative, which is easy to publish to, and easy to pull from.
The system of doing an apply from to a http URL is a source of problems (e.g. it can't be cached by Gradle, and no offline mode), and a security vector. We'd much prefer to have the raw apply plugin in our build scripts, but that's only possible if we also have the repository already setup.
Hi
With Reference to the issue 43.
I tried updating the updateVersion() method. Whether the next release has to be updated in gradle.properties. It is removing all the other properties that are defined in gradle.properties.
Can you please let me know why
Regards
Smurf
Hello, maybe I missed something but is there possibility of using plugin's SNAPSHOT, i.e. version built from latest source code or night build or similar.
Currently I have to build it myself and keeps jars in source repository for using latest changes.
It could be good addition to have possibility of using SNAPSHOT until main version is released
Currently there's several places where plugin dependencies are declared
build.gradle
release.gradle
installation/apply.gradle
First of all it seems that after adoption of Sonatype
apply script only should have dependency declaration of plugin itself. So gradle-git
should be removed from there. Please correct me if I'm wrong
Then again we have an issue with differences between build.gradle
and release.gradle
. This fact will potentially bring problems to Sonatype
users. For instance, release.gradle
has dependency on old version of Spock
and that version is used in generated Sonatype
POM file.
So could you please synchronize dependencies between all gradle scripts used in plugin ? The beast approach could be moving dependencies declaration to separate file that can be included into any script that need plugin specific dependencies.
Currently it just ignores an error on update (here with connection timeout):
Task ':checkUpdateNeeded' has not declared any outputs, assuming that it is out-of-date.
>>> Running [git, --git-dir=/home/foo/bar/.git, --work-tree=/home/foo/bar, remote, update]
>>> Running [git, --git-dir=/home/foo/bar/.git, --work-tree=/home/foo/bar, remote, update]: [Fetching origin
][ssh: connect to host my.remote.host port 29418: Connection timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin
]
Running "git --git-dir=/home/foo/bar/.git --work-tree=/home/foo/bar status -sb"
(...)
It would expect it to fail (but maybe there are other usecases to make it useful).
When LANG=FR
svn info return "URL :" and not "URL:"
Can you execute svn info whith LANG=US ?
Tanks.
If another versionPropertyFile
is specified instead of using the default gradle.properties
, the replacement of the version number fails. The ReleasePlugin
's checkPropertiesFile
method does this replacement:
project.ant.replace(file: propertiesFile, token: "version=${project.version}", value: "version=${project.version}", failOnNoReplacements: true, preserveLastModified: true)
The problem is that the project.version
is not set unless the version is in gradle.properties
or set somewhere else with some code that reads the specified version property file.
Hi, I'm trying to create a jenkins job that does my releasing.
The problem I'm facing is that jenkins seams to change gradlew, causing the release plugin to fail.
Since you (@townsfolk) mentioned on another issue that you are using jenkins I figured you might have come across this issue and could help with it.
A more complete description of the issue is in a stackoverflow question regarding the issue.
I'd like to set up my CI server (Jenkins) to create nightly builds, those shouldn't change the main version, but should only replace the SNAPSHOT part with the hashcode of the git commit.
How can I do that with this plugin?
It is sometimes useful to have a full control over interaction with remote error on release process. There could be an additional flag (pushChanges? - default true) which would allow to review changes done by a release plugin before (manual) push.
It could be good addition to allow configure release tag prefix via plugin convention properties.
Currently it's possible to use project name for prefixing tag but could be something like
release {
releaseTagPrefix = 'MY_PREFIX_'
}
So all tags created will look like MY_PREFIX_1.2.3
Apologies if this isn't the right forum, but do you know how this great plugin can be used to actually publish the release artifact? I'm using the maven-publish plugin already but what I want to be able to do is to add a call to publish in the short window where gradle release creates my non-snapshot artifact.
Hi folks!
We ran into bug in your 1.2 version of the plugin. Shortly said, JGit does not follow symbolic links, so that every link is recognized as 'modified' by gradle-release. Please see https://github.com/eclipse/jgit#warningscaveats.
That means, non of git repository w/ symlinks can be used with plugin, except for the 'uncommited' flag turned on, and we are forced to switch to 1.1 version, where you were using native exec for 'git status --porcelain'.
Please consider removing usage of jgit, e.g. revert GitReleasePlugin.groovy to 1.1 condition.
Thanks!
Hi,
While executing the release task, I noticed 2 things:
gradle.startParameter.taskNames.contains('release')
, but this property gets lost during the release task because it runs in a new context with a new startParameterSo my question: is there a specific reason why the release task has type GradleBuild i.s.o. being a plain task that depends on other tasks?
Ivo
Hi,
I want to create releases on jenkins with help of release plugin (https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin) where user can self specify release version and new version. It would be great, if I could call gradle in such way:
gradle release -PreleaseVersion='1.0.0' -PnewVersion='1.1.0-SNAPSHOT'
The check for reverting a failed release looks like:
if (releaseConvention().revertOnFail && project.file("gradle.properties")?.exists()) {
log.error("Release process failed, reverting back any changes made by Release Plugin.")
this.scmPlugin.revert()
} else {
log.error("Release process failed, please remember to revert any uncommitted changes made by the Release Plugin.")
}
If a custom properties file is being used, the check should be for that file
I had spaces in my gradle.properties file, e.g.:
version = 0.0.1
This caused updateVersion to fail:
Building > :updateVersion
??> Enter the next version (current one released as [0.0.1]): [0.0.2]
:updateVersion FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':updateVersion'.
Unable to update version property. Please check file permissions, and ensure property is in "version=0.0.2" format.
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Since this is an allowed practice in properties files it should be supported.
When using --parallel, the release will not work reliably. I have parallel mode enabled in my ~/.gradle/gradle.properties.
Workaround:
add a line 'tasks.release.startParameter.parallelThreadCount = 0' in your buildscript
I see two possible sollutions:
1.: in ReleasPlugin.groovy set startParameter.parallelThreadCount = 0 in definition of the release task
2.: use Task.mustRunAfter for each task.
I'm new to gradle and I'm looking to port my existing maven builds to gradle this year. One of the biggest requirements that I have is that we must be able to cut release builds like we do with maven today. I've been working on migrating a single project to gradle using the release plugin but it doesn't seem to work as I would expect it to. Basically, I'm looking for behavior like I have with maven today.
My project has several subprojects... build.gradle looks like this. When I run the build I would expect the tagged version to have a non-snapshot version in the gradle.properties (it has the snapshot version). Also, the SNAPSHOT artifacts are published, not the 1.0.0 versioned artifacts. I'm sure that I'm doing something wrong, so any help would be appreciated!
apply from: "https://launchpad.net/gradle-release/trunk/1.0/+download/apply.groovy"
.....
uploadArchives {
def mvnUser = 'XXX'
def mvnPassword = 'YYY'
repositories.mavenDeployer {
//configuration = configurations.mavenDeployer
uniqueVersion = false
def mainPom = addFilter('main') {artifact, file -> !artifact.name.endsWith("-tests") }
def testsPom = addFilter('tests') {artifact, file -> artifact.name.endsWith("-tests") }
def poms = [ mainPom, testsPom ]
poms.each { it.version = project.version }
repository(url: 'http://maven01.xxx.com:8080/nexus/content/repositories/releases') {
authentication(userName: "${mvnUser}", password: "${mvnPassword}")
}
snapshotRepository(url: 'http://maven01.xxx.com:8080/nexus/content/repositories/snapshots') {
authentication(userName: "${mvnUser}", password: "${mvnPassword}")
}
}
}
release {
project.setProperty("gradle.release.useAutomaticVersion", "true");
//project.setProperty("gradle.release.unSnapshotVersion", "true");
tagPrefix = "enterprise-services-common"
preCommitText = "ESC-3 Release Build"
preTagCommitMessage = "ESC-3 Release Build"
tagCommitMessage = "ESC-3 Release Build"
newVersionCommitMessage = "ESC-3 Release Build"
}
Hello
I'm planning to start some work regarding migration from cmd line git client ot JGit library. This allows plugin to not depend on cmd line client and external environment.
For this I have two options
So this questions is open and I would like to know your opinion about it before proceed.
Thank you
Hi
I am working on the gradle release plugin https://github.com/townsfolk/gradle-release on the multi module project. I am able to do a svn ls url from command prompt. But this does not work.
I have mentioned the below in the main build.gradle
buildscript {
repositories {
mavenCentral()
maven { url "https://oss.sonatype.org/content/groups/public"}
}
dependencies {
classpath 'com.github.townsfolk:gradle-release:1.2'
}
}
apply plugin: 'release'
Have i missed giving the username and password for svn ?? Can you please let me know.
I tried to do a gradle release , but i am getting the following error:
:release
:svnPlatform:initScmPlugin
:svnPlatform:checkCommitNeeded FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':checkCommitNeeded'.
You have 7 un-commited changes.
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debu o
ption to get more log output.
BUILD FAILED
Thanks
Smurf
I'm using version 1.2 of the plugin.
If the version assignment used in gradle.properties contains spaces around the = sign, the release plugin will silently fail to update the version number. Everything looks like it works, but the version never gets changed. It also makes the commits in Git look a bit wonky.
I've run into the same thing before filtering properties files with Gradle and I still have a warning in the comments at the top of the file, so I'm not sure how to fix it.
To clarify, version=0.0.1-SNAPSHOT works, but version = 0.0.1-SNAPSHOT fails.
The plugin works very well for me BTW. It's nice and simple (to use).
My primary development environment is Windows with a Cygwin command line.
Sadly, System.console in Cygwin returns null. It's a known issue, but there isn't a direct work around other than working around it. Our project uses your plugin, but this means I cannot do a release in Cygwin. Could you modify your readLines() to do something such as
http://stackoverflow.com/questions/4203646/system-console-returns-null
for more cross environment compatibility?
I have cloned the gradle-release project from github and attempted to execute:
gradle clean test
The tests fail with the following output:
release.GitReleasePluginTests > should apply ReleasePlugin and GitReleasePlugin plugin FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31
release.GitReleasePluginTests > when requireBranch is configured then throw exception when different branch FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31
release.GitReleasePluginTests > should push new version to remote tracking branch by default FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31
release.GitReleasePluginTests > when pushToCurrentBranch then push new version to remote branch with same name as working FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31
20 tests completed, 4 failed, 1 skipped
:test FAILED
My git versions is:
git version 1.7.11.msysgit.1
Looking in TEST-release.GitReleasePluginTests: A snippet...
org.gradle.api.GradleException: Running "git commit -m test test.txt" in [C:\Users\dwhewell\git\gradle-release\build\tmp\test\release\GitReleasePluginTestLocal] produced an error: [**\* Please tell me who you are.Run
git config --global user.email "[email protected]"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'dwhewell@LHM-LAP-DEV0610.(none)')]
at release.PluginHelper.exec(PluginHelper.groovy:98)
at release.GitReleasePluginTests.setup(GitReleasePluginTests.groovy:31)
It seems that the git operations fail because the user.name and user.email are not set.
So, I run the suggested git config commands above and repeat the gradle build, with the same result.
gradle --version
Gradle 1.4
Gradle build time: Monday, 28 January 2013 03:42:46 o'clock UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.6.0_31 (Sun Microsystems Inc. 20.6-b01)
OS: Windows 7 6.1 amd64
Is there anything I should be doing to make these unit tests work? It seems as though the embedded git execs in GitReleasePluginTests.groovy prevent git from seeing .gitconfig.
I would like to configure the plugin to use my own lifecycle task(s) instead of the default build
task. I imagine something like this:
release {
lifecycleTasks = [ 'releaseBuild', 'anotherTaskMaybeEmailSomeone' ]
}
I'm including part of my build script inline to show how I've set up a few lifecycle tasks and integrated them with the plugin. It seems to work quite well, but I just finished writing it, so it shouldn't be taken as an example of how to structure a build.
def majorJavaVersion = '1.7'
def exactJavaVersion = '1.7.0_17'
def runningJavaVersion = System.getProperty("java.version")
def buildTimestamp = new Date()
def buildLabelFormat = new SimpleDateFormat("yyMMddHHmmssZ")
def buildLabel = buildLabelFormat.format(buildTimestamp)
apply plugin: 'release'
release {
// this needs to be changed if using a release branch
requireBranch = 'master'
}
allprojects {
ext.buildTime = buildTimestamp
}
// application updates are going to depend on the type of build being done.
// release builds belong to the stable update channel and preview builds
// belong to the preview update channel. installers are customized based
// on the update channel set up here.
def updateChannels = [':previewBuild': 'preview', ':releaseBuild': 'stable']
gradle.taskGraph.whenReady { graph ->
def updateChannel = 'dev' // catchall default
updateChannels.keySet().each {
if (graph.hasTask(it)) {
updateChannel = updateChannels.get(it)
}
}
allprojects { ext.updateChannel = updateChannel }
}
task build {
// prevent the use of 'build' as a start parameter to give us more fine grained
// control over the build
gradle.taskGraph.whenReady { graph ->
assert (!graph.hasTask(it)): "Cannot invoke 'build' directly. Try 'devBuild'."
}
}
task release(overwrite: true) {
// override the release task so we can plug in the releaseBuild lifecycle task
// instead of using 'build'
gradle.taskGraph.whenReady { graph ->
if(graph.hasTask(it)) {
def releaseStartParam = gradle.startParameter.newInstance()
releaseStartParam.setTaskNames([
'initScmPlugin',
'checkCommitNeeded',
'checkUpdateNeeded',
'unSnapshotVersion',
'confirmReleaseVersion',
'checkSnapshotDependencies',
'releaseBuild',
'preTagCommit',
'createReleaseTag',
'updateVersion',
'commitNewVersion'
])
GradleLauncher.newInstance(releaseStartParam).run().rethrowFailure()
}
}
}
task updateBuildLabel << {
allprojects {
ext.buildTime = buildTimestamp.toString()
ext.buildLabel =
project.version.contains("SNAPSHOT") ? buildLabel : project.version
}
println "##teamcity[buildNumber '${project.ext.buildLabel}']"
}
task checkDevEnv << {
// make sure the env is good enough to perform dev builds
assert(runningJavaVersion.startsWith(majorJavaVersion))
}
task checkReleaseEnv << {
// fail if the environment is wrong or if a release build was triggered without
// using the 'release' task (the version will be unSnapshotted by the time this
// task runs if the 'release' task was used to start the build).
assert(runningJavaVersion.equals(exactJavaVersion))
assert(!project.version.contains('SNAPSHOT'))
}
task devBuild {
// some env checks, create a timestamp or release version based label, and
// build the most dependent sub-project (an installer). this does not run
// any tests.
dependsOn checkDevEnv, updateBuildLabel, ':itma-standalone-installer:i4jBuild'
}
task ciBuild {
// an alias for the ci server
dependsOn devBuild
}
task nightlyBuild {
// it would be nicer to add a buildNeeded task to :itma-standalone-installer, but
// i don't know how without using the java plugin. this adds tests to all java
// projects that :itma-standalone depends on.
dependsOn ciBuild, ':itma-standalone:buildNeeded'
}
task previewBuild {
// only start uploading installers automatically for builds that are preview
// or better
dependsOn nightlyBuild, ':itma-standalone-installer:i4jUpload'
}
task releaseBuild {
// the same as preview, but with some extra env checks
dependsOn checkReleaseEnv, previewBuild
}
// make sure no one accidentally adds a task named releaseBuild to any subprojects
subprojects {
afterEvaluate {
assert(it.getTasksByName(releaseBuild.name, true).isEmpty())
}
}
Hi,
for some reason
jar {
manifest {
attributes('Implementation-Version': version)
}
}
still has the old value instead of the unShapshot version. project.version as well. Is there any other property or am i doing sth. wrong?
Cheers, markus
Hello
gradle-release
we need to use version 0.5.0
of gradle-git
. Please upgradeSorry for inconveniences brought by my pull request.
When we do a 'gradle release' task, we get the following:
:ourapp:initScmPlugin FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.
FAILURE: Build failed with an exception.
Current Git branch is "integration" and not "master".
While this is great from enforcing release process ( of releases coming off master), for the sake of testing we would like to test this plugin in a separate branch. How do we customize the same ( of specifying a different branch )? Thanks !
FYI. Our build.gradle looks as below:
///////////// build.gradle begins
apply from: 'http://tellurianring.com/projects/gradle-plugins/gradle-release/apply.groovy'
allprojects {
release {
failOnUnversionedFiles = false
failOnUpdateNeeded = false
useAutomaticVersion=true
}
}
task build() {
}
///////////// build.gradle ends
Can you please specify the license and terms of usage of the gradle-release module?
Thanks.
Hi - is there a possibility to specify that the next version should be -SNAPSHOT automatically? If not, any chance that you can add it...?
Thanks,
Tamas
Hi
I wanted to do add upload task as well in the plugin, so that it uploads to nexus repo
At present, in the release plugin, you have added a task as 'build'. I tried to add a task as 'upload', but it does not wrok. Can ou please help me on that
As you have the
Thanks
Smurf
Is it possible to set the tag path to use, similar to how you can specify the tagBase configuration value in the Maven Release plugin?
The project I am working on has the following projects:
svn.company.com/repo/trunk/foo
svn.company.com/repo/trunk/foo/foo-a
svn.company.com/repo/trunk/foo/foo-b
Where foo, foo-a and foo-b are three individual projects.
The requirement is to tag them as such:
svn.company.com/repo/tags/foo-1.0
svn.company.com/repo/tags/foo-a-1.0
svn.company.com/repo/tags/foo-b-1.0
Can this release plugin handle that kind of tagging structure?
project is not problem
i was testing from svn 1.6 ( osx ) but problem is windows or subversion 1.7
plz.!!! i want to release plugin
[liongo.SF2-SEONGWOO-PC] โ sh gradlew release
xxxx Poject <<<<<
0.7.4.1-GR-SNAPSHOT
:release
xxxx Poject <<<<<
0.7.4.1-GR-SNAPSHOT
:xxxxserver:initScmPlugin
:xxxxserver:checkCommitNeeded
!!WARNING!! You have 19 un-versioned files.
:xxxxserver:checkUpdateNeeded FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':checkUpdateNeeded'.
Running "svn info svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver" produced an error: [svn: E670008: Unable to connect to a repository at URL 'svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver'
svn: E670008: Unknown hostname 'developer.xxxx.co.kr']
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 8.721 secs
[liongo.SF2-SEONGWOO-PC] โ svn info svn://developer.xxxxx.co.kr/svn/xx2/trunk/xxxxserver
Path: xxxxserver
URL: svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver
Repository Root: svn://developer.xxxxx.co.kr/svn/xx2
Repository UUID: e7335162-918b-11e0-b175-019f8cb6028d
Revision: 3418
Node Kind: directory
Last Changed Author: liongo
Last Changed Rev: 3418
Last Changed Date: 2013-06-03 20:12:59 +0900 (, 03 6 2013)
When the task release faild after having commited gradle.properties whith the new version. Cannot you revert the gradle.properties with the old version comit the file.
Thanks.
Hi,
i am not sure if i am wrong, but i think the release tag has the wrong content (using SVN).
as an example:
SVN REV 200: has code with version 1.2-SNAPSHOT
-> the plugin changes to 1.2 and preTags, so we have SVN REV 201
-> the plugin builds the project and has artifacts of version 1.2
-> the plugin does the release tag but with SVN REV 200 instead of REV 201
-> the plugin does change the version to 1.3-SNAPSHOT and commits to REV 202
The issue from my perspective is, that the code living on the tag is not the code which has been release, but the code before the release.
I guess when doing the preTagCommit the result SVN Rev has to be remembered as svnRevision
Cheers, markus
When using the following gradle.properties
:
version=0.0.1-SNAPSHOT
..and the following build.gradle
:
buildscript {
repositories {
maven {
url "https://oss.sonatype.org/content/groups/public/"
}
}
dependencies {
classpath 'com.github.townsfolk:gradle-release:1.2-SNAPSHOT'
}
}
apply plugin: 'release'
task build << {
assert(false)
}
..runing gradlew release
will fail, and gradle.properties
will include:
version=0.0.1
I think the version should only be updated in memory before the build
task runs and updating the gradle.properties
file should be done after the build
task runs. Using the above example to clarify, I think project.version
should be 0.0.1
while the build
task is executing, but gradle.properties
shouldn't be touched until just before the preTagCommit
task is run.
Hi
I tried this plugin and it updated the gradle.properties with the updated version and also created the release tag . But, once the version is updated in the gradle.properties, it does not commit that code to svn.
Can anyone please let me know, if i have missed something. Or how to implement that.
Thanks
Smurf
Hi,
Thanks for the plugin to facilitate my development work. Can make the gradle-release plugin support TeamCity ? Currently I do some special handing in build.grade to make "gradle install" can build in teamcity, and the "gradle release" only work in local PC which have svm folder, such as ".git", which TeamCity work directory don't have!
Hi
Has this plugin been tested in jenkins?
Thanks
Smurf
Hi,
I just happened to find out that this plugin doesn't work with git 1.7.1 - it needs the git status -b option which seems to have been added in 1.7.2
You may want to add an explicit git version check to give the user a better error message in that case
I have a project which is placed not in the Git root directory (there are some other folders with scripts, docs, etc. besides the projects sources). This breaks a plugin:
``Running "git --git-dir=/home/foo/myRepo/myAppSource/.git --work-tree=/home/foo/myRepo/myAppSource branch" produced an error: [fatal: Not a git repository: '/home/foo/myRepo/myAppSource/.git']`
There could be an additional parameter to define a SCM root in a build script (e.g. scmRoot = "../"
).
Hello
For further migration to GitHub it could be useful to put plugin jar to download section and update README to configure downloading of plugin from GitHub instead of Launchpad.
Also maybe you can consider releasing minor version of plugin with couple of fixes introduced by latest changes
What do you think ?
Thanks for providing this plugin! I'm currently using it for a couple of our projects (java/war multi-project builds, SVN, jenkins).
I had to make a couple of adjustments to leverage this plugin:
exec
methods to use project.getProjectDir()
which solved the issue (this also works locally)What do you think about those 2 points? If a find time I'll issue a pull request.
I also struggled with issue 27, so it might be helpful to include this in the readme.
Looking ahead it might be useful to be able to provide the release version and the next version (compared to the local execution) in a CI environment as well (for instance provided by the jenkins release plugin).
Best,
Moritz
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.