Git Product home page Git Product logo

orbit's Introduction

Eclipse Orbit Recipes

Orbit Restructuring

Please see the Orbit Restructuring Plan for details on how and where to consume Orbit bundles going forward. New recipes, barring very special cases, should be contributed to the orbit-simrel repository where you can find contibution instructions.

This repositories hosts recipes for building OSGi bundles as part of the Eclipse Orbit project. This repository is based on functionality provided by the Eclipse EBR maven plug-ins.

The output of the Eclipse Orbit builds are located on download.eclipse.org: https://download.eclipse.org/tools/orbit/downloads/

The Very Short Version

See Adding Bundles To Orbit in 5 Minutes as a quick explanation of the contribution process.

Prerequisites

This project uses Maven for assembling of OSGi bundles based on artifacts in Maven Central or any other accessible Maven repository.

  1. Install Java 11 (Java 8 and Java 17 don't work) and Maven.
  2. Clone this repository and go into the repository root folder.

How to build all bundles yourself

  1. Clone this repository and go into the repository root folder.
  2. Run the following command to build the OSGi bundle: mvn clean install

This will publish all OSGi bundles produced by the recipes into your local Maven repository. You can consume the bundles directly from Maven in any Tycho build.

Generate p2 repository

  1. Go into the repository root folder.
  2. mvn clean install -f releng/aggregation-mirror-osgi/pom.xml
  3. mvn clean install -f releng/aggregationfeature/pom.xml
  4. mvn clean package -f releng/repository/pom.xml

The repository will be made available as archive in releng/repository/target.

Note, you must build the recipes first and install the result into your local Maven repository. Otherwise the p2 build won't find any bundles.

How to build just a single recipe?

This is not difficult at all. Just change into the directory of the recipe to build and execute Maven from there.

  1. cd recipes/\<path/to/recipe\>
  2. mvn clean package

(To preview local changes, add -DdirtyWorkingTree=warning to ignore uncommitted Git changes - see "How to add recipes" for more details)

The resulting bundle will be available in the recipes target folder.

How to add recipes

Adding recipes to this repository is part of the general process for adding bundles to Orbit. Please read the following additional information first before you proceed.

It's important to ensure that the bundle you're adding has been approved for use. See IP Provenance for some instructions. See IP Prereq Diligence for further details.

1. Pick a Category

Recipes are organized in folders by category. There is no strict rule on categories, i.e. categories do not map to vendor names by definition. However, it seems logical to select a category name based on some common critaria shared by recipies. Most of the time, "origin" of the 3rd party libraries seems like a good fit. But occasionally, functionality (eg, 'logging') is also helpful in order to avoid too fine grained grouping (eg., categories with only two recipies).

In case of doubts/questions, please reach out to the Orbit Committers List. Also, don't be afraid of mistakes. It's all in a single Git repository so re-organization is possible at any time later on.

Note, when creating a new category please create the category pom.xml first before any recipes. Use another category pom.xml as template to inherit the proper Orbit recipe parent pom. This ensure that proper Orbit defaults are used when creating recipes (for example, the bundle vendor is automatically set to "Eclipse Orbit").

2. Create the recipe

The preferred method for creating recipes is by consuming a Maven artifact. The EBR Maven plug-in can be used to create a recipe including required Eclipse IP information based on data available in Maven artifact poms.

# create the recipe for a specific Maven artifact
# the recipe will be created in a folder named "<symbolicname-of-the-orbit-bundle>_<version>"
mvn ebr:create-recipe -DgroupId=<maven-source-groupId> -DartifactId=<maven-source-artifactId> -Dversion=<maven-source-version> -DbundleSymbolicName=<symbolicname-of-the-orbit-bundle>

# modify recipe pom and osgi.bnd to suit the needs of the bundle
cd <new-recipe-folder>
$EDITOR pom.xml
$EDITOR osgi.bnd

# do a test build (this will create a default ip_log.xml)
# (note the -DirtyWorkingTree=ignore to ignore uncommitted Git changes for now)
mvn -U clean package -DdirtyWorkingTree=warning

# review the generated about files
ls -la src/main/resources/about_files
cat src/main/resources/about.html

# add new recipe to category pom
$EDITOR ../pom.xml

# update the build feature with your bundle
$EDITOR ../../releng/aggregationfeature/feature.xml

# add, commit the recipe to Git and push to Gerrit for review
git add .; git commit -m "Added org.example.foo 1.2.3"
# NOTE: Please push via Pull Request to ensure you don't bypass code review

3. Troubleshooting

If you are having trouble with the build after submitting your change, this is typically because there is a missing dependency. It is ideal to have all transitive dependencies of the library you're adding available as OSGi bundles in Orbit, though there may be exceptions to this. The dependency metadata can all be customized using the osgi.bnd file. You can discover the dependencies using mvn dependency:tree under the project folder of the library you're adding.

orbit's People

Contributors

rgrunber avatar msohn avatar jonahgraham avatar guw avatar godin avatar smadani avatar akurtakov avatar tony-- avatar creckord avatar cdietrich avatar tjwatson avatar sarikasinha avatar mbooth101 avatar loulloudesn avatar noopur2507 avatar pcdavid avatar eselmeister avatar nitind avatar merks avatar jjohnstn avatar sbegaudeau avatar vogella avatar erwindl0 avatar fipro78 avatar apupier avatar pontesegger avatar zulus avatar dhendriks avatar dhuebner avatar frankbenoit avatar

Stargazers

Luca Sacchi avatar  avatar

Watchers

 avatar  avatar  avatar  avatar Sebastian Zarnekow avatar Mikaël Barbero avatar Markus Knauer avatar  avatar  avatar  avatar  avatar  avatar Christopher Guindon avatar Horacio Hoyos avatar  avatar  avatar sebastien.heurtematte avatar Alexander Fedorov avatar  avatar

orbit's Issues

Remove EJML (v0.29) bundles from Orbit

A newer version (v0.43) is available here:
http://ejml.org

Furthermore, we faced some problems with conflicting classes when consuming EJML via Orbit. Nowadays, it works fine to reference the EJML dependencies in the product definition by using the Maven dependency option.

If no one else has objections, I will remove the bundles soon.

Remove bundles that have OSGi metadata upstream

For a long time Orbit's re-bundling was the way to get third-party libraries from Maven into an Eclipse p2 consumable state.

For a while now there has been a better way for getting third-party dependencies that already contains OSGi metadata. That is to use the M2E's maven target locations and sign the bundles with PGP instead of jarsigning. There has been much communication on mailing lists and in issues on this topic in the the last couple of years.

The next step now is to stop maintaining the Orbit bundles that rewrite the OSGi metadata when the upstream bundle has the OSGi metadata in it correctly already.

The goal is to have the first step of this process done for 2023-09 M1 by removing the bundles. In addition @merks's work in https://github.com/eclipse-oomph/oomph.incubator will be migrated into the Orbit project so that Orbit provides p2 repos with the PGP signed third-party dependencies already in them.

Here are the bundles that have valid OSGi metadata in the upstream version that we plan to remove. This list will be added to as we vet additional bundles.

  • #9 #26
  • #19 #24
  • #27
  • #28
  • #29
  • #30
  • SLF4J
  • logback
  • commons-logging
  • #33
  • #34
  • #35
  • #36
  • jakarta.servlet-api and jakarta.el-api (Eclipse Platform ships direct from Maven version older than versions in Orbit)
  • #38
  • #39
  • jackson (Eclipse platform consumes direct from Maven, but does not re-publish, other projects are publishing Orbit version to SimRel)
  • #40
  • apache commons-collections 3 (Eclipse platform consumes direct from Maven, but does not re-publish, other projects are publishing Orbit version to SimRel)
  • #42
  • #43
  • #44
  • commons-codec
  • commons-compress
  • commons-io
  • guava
  • #45
  • guice aka com.google.inject
  • #46

Remove com.ibm.icu4j from Orbit

I've updated the Platform to version 73.1 and added it to my target:

https://github.com/merks/simrel-maven/blob/17fcd1ac411cd73d9c733093981b265a9b8fe49d/merged-target/updated.target#L240-L245

It's available from here:

And I've done builds to make it available

This would seem like a good first opportunity to remove something from Orbit...

Complete migration to GitHub

The Eclipse Orbit Project is now in GitHub (this repo!). This issue is to track the items left to do to complete the migration with a general goal of getting this all done by 2023-06 M1 on 4 April.

  • Update CI jobs with new URL
  • Move releasing steps from wiki.eclipse.org to GitHub
  • Consider closing out old bugs in Bugzilla (with Resolved -> Moved)
  • Find and update all locations that say file bugs in bugzilla and migrate that to GitHub issues
  • #6

use dependabot

Is it possible to use dependabot or some tool alike to monitor the used libraries?
I manually stumbled across a vulnerable library in orbit which already has a fixed version.

removed httpmime dependencies cause failures

Bundle version number does not match what's in the GAV

We have two IP review requests created by the Orbit build bot for a bundle ID com.github.virtuald.curvesapi.

e.g., https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/10700

In both cases, the version number of the bundle does not match the version number of the corresponding Maven component.

For example, AFAICT, com.github.virtuald.curvesapi_1.7.0 maps to com.github.virtuald:curvesapi:1.07.

Should I expect that the version numbers align?

Did the BundleID change?

The Eclipse Dash License Tool uses this repository to figure out how to map a bundle Id (e.g., com.atlassian.commonmark-gfm-tables) to the corresponding GAV (e.g., com.atlassian.commonmark:commonmark-ext-gfm-tables). The scanner walks this repository and pulls this information out of the pom.xml files. It generally works (with some small amount of hinting).

The expectation is that as we encounter new versions of things, they are likely to have similar IDs to the older versions. The exceptions are handled with the aforementioned small amount of hinting.

The Orbit build (the only information that I have is that the issue "was created 2 days ago by orbit bot user) recently created a handful of reviews for which the scanner cannot find source code.

For example: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/10695 (there's actually a bunch of similar "commonmark" entries).

Here... we need to map the bundle ID org.commonmark-gfm-tables. The closest that I can find in this repository is a bundle named com.atlassian.commonmark-gfm-tables.

Are these the same thing? Did the name change intentionally? Is this a mistake?

Replace Orbit recipes with M2E's 'Maven' target locations fetching from Maven-Central

In order to ease the transition to use M2E's Maven target locations in projects directly and to simplify the update of existing artifacts in Orbit and reduce the technology stack, I want to propose to use Maven type target locations in Orbit.

When migrating a Orbit recipe to a dependency in a Maven target location one has to distinguished if the artifact at Maven-Central already has a OSGi compliant manifest or not:

  • OSGi compliant artifacts can be used as they are from Maven-Central as simple dependency
  • For not OSGi compliant artifacts, use instructions element of a Maven-Target. The instructions should probably be similar to the previous Orbit recipe (osgi.bnd).

In some cases this can leads to subtle differences in OSGi metadata and the artifact content. In Orbit some artifacts were split into two (e.g. logback 1.2) or mutliple into one (e.g. guava and its failureaccess dependency).
The generated artifact will also not contain the Eclipse license files. But if they are a requirement the build could be adjusted to add them to the artifacts with generated manifest.

To ensure license compliance of all artifacts in Orbit the reusable eclipse.dash-licenses license-check workflow can be used:

Ed's new SimRel-Maven service (which is great :) ) would then mainly serve the purpose of providing updates for Maven-targets used in SimRel projects until dependabot can do it (dependabot/dependabot-core#6913). At the moment I have the impression that it is also used as extended Orbit with more recent Maven-artifacts from Maven-targets (merks/simrel-maven#3).

If you are interested I can make an initial migration for a simple case, but migrating all recipes will be a greater task and will probably also need some adjustments in consuming projects because of the subtle differences mentioned above.

At the same time this could also be a good opportunity to clean up unused artifacts. But it is probably not sufficient to only look into SimRel is it?

CD for Orbit

Orbit should have a CD pipeline, i.e. after a PR is merged, a new repository should be provided and published under a "latest" or "main" (as in "main" branch) URL.

Eliminate "Legacy" Bundle

In order to produce this aggregation:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation

these really, really old bundles are dragged in:

image

These all need to be removed or replaced.

A bunch of these are dragged in to make batik happy, i.e., the 3 selected bundles above. They could be replaced by one of these:

But those things do not provide sources and I don't think it's okay to not provide sources. It's certainly not nice and not ideal.

Note that I tried to find if anything on Maven Central provides sources and have reached the conclusion that the only thing providing sources are the old Orbit source bundles themselves.

The problem isn't just that these are old, they also have package imports that could be satisfied by the JDK, but not when there is a version constraint because the JDK's packages are not versioned.

I would like to propose that we create a new Git repository to maintain bundles in source form for bundles that cannot be created by bundling a Maven Central artifact. Of course we want as few of those as possible!

I've prototyped the following repository contents:

image

I've take the three source bundles and combined them into a single bundle with the same combined contents as the above two Maven artifacts.

image

If I use the resulting repository in the aggregation, we can see that the new bundle eliminates the org.w3c.dom.events bundle too, it satisfies all the batik constraints, and it will allow us to eliminate the javax.xml bundle too.

#48

@jonahgraham

Shall I create a new orbit-legacy Git repository with the initial contents as outlined above to produce a p2 repository https://download.eclipse.org/tools/orbit/simrel/orbit-legacy that can then be used in the aggregation to replace using an actual older orbit ebr repository?

Do you have any questions or concerns?

Status and future of javax.xml

I wanted to record some observations about java.xml. There are two versions on the train:

image

I'm not sure why WTP is explicitly including/requiring the older version.

Note that some other older legacy dependencies also require the older version, so I wanted to figure out why that is...

Looking at the 1.3.4 version, the pretty printed MANIFEST.MF looks like this:

Bundle-Localization                     plugin
Bundle-ManifestVersion                  2
Bundle-Name                             %Bundle-Name.0
Bundle-RequiredExecutionEnvironment     J2SE-1.2
Bundle-SymbolicName                     javax.xml
Bundle-Vendor                           %Bundle-Vendor.0
Bundle-Version                          1.3.4.v201005080400
Export-Package                          javax.xml.datatype;version="1.3"
                                        javax.xml.namespace;version="1.3"
                                        javax.xml.parsers;version="1.3"
                                        javax.xml.transform.dom;version="1.3"
                                        javax.xml.transform.sax;version="1.3"
                                        javax.xml.transform.stream;version="1.3"
                                        javax.xml.transform;version="1.3"
                                        javax.xml.validation;version="1.3"
                                        javax.xml.xpath;version="1.3"
                                        javax.xml;version="1.3"
                                        org.apache.xmlcommons;version="1.3.4"
                                        org.w3c.dom.bootstrap;version="3.0"
                                        org.w3c.dom.css;version="2.0"
                                        org.w3c.dom.events;version="2.0"
                                        org.w3c.dom.html;version="2.0"
                                        org.w3c.dom.ls;version="2.0"
                                        org.w3c.dom.ranges;version="2.0"
                                        org.w3c.dom.stylesheets;version="2.0"
                                        org.w3c.dom.traversal;version="2.0"
                                        org.w3c.dom.views;version="2.0"
                                        org.w3c.dom.xpath;version="3.0"
                                        org.w3c.dom;version="3.0"
                                        org.xml.sax.ext;version="2.0.2"
                                        org.xml.sax.helpers;version="2.0.2"
                                        org.xml.sax;version="2.0.2"
Manifest-Version                        1.0
Require-Bundle                          system.bundle

Note the exports are not imported. Note too the version numbers on the packages.

Compare that to the Orbit 1.4.1 version:

Ant-Version                             Apache Ant 1.7.0
Automatic-Module-Name                   javax.xml
Build-Jdk-Spec                          11
Bundle-ManifestVersion                  2
Bundle-Name                             %bundleName
Bundle-SymbolicName                     javax.xml
Bundle-Vendor                           %bundleVendor
Bundle-Version                          1.4.1.v20220503-2331
Created-By                              Eclipse Bundle Recipe Maven Plug-in
Export-Package                          javax.xml.datatype;version="1.4.1";uses:="javax.xml.namespace"
                                        javax.xml.namespace;version="1.4.1"
                                        javax.xml.parsers;version="1.4.1";uses:="javax.xml.validation,org.w3c.dom,org.xml.sax,org.xml.sax.helpers"
                                        javax.xml.stream.events;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream"
                                        javax.xml.stream.util;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream,javax.xml.stream.events"
                                        javax.xml.stream;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream.events,javax.xml.stream.util,javax.xml.transform"
                                        javax.xml.transform.dom;version="1.4.1";uses:="javax.xml.transform,org.w3c.dom"
                                        javax.xml.transform.sax;version="1.4.1";uses:="javax.xml.transform,org.xml.sax,org.xml.sax.ext"
                                        javax.xml.transform.stax;version="1.4.1";uses:="javax.xml.stream,javax.xml.transform"
                                        javax.xml.transform.stream;version="1.4.1";uses:="javax.xml.transform"
                                        javax.xml.transform;version="1.4.1"
                                        javax.xml.validation;version="1.4.1";uses:="javax.xml.transform,org.w3c.dom,org.w3c.dom.ls,org.xml.sax"
                                        javax.xml.xpath;version="1.4.1";uses:="javax.xml.namespace,org.xml.sax"
                                        javax.xml;version="1.4.1"
                                        org.apache.xmlcommons;version="1.4.1"
                                        org.w3c.dom.bootstrap;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.css;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.stylesheets,org.w3c.dom.views"
                                        org.w3c.dom.events;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.views"
                                        org.w3c.dom.html;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.ls;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.events,org.w3c.dom.traversal"
                                        org.w3c.dom.ranges;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.stylesheets;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.traversal;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.views;version="1.4.1"
                                        org.w3c.dom.xpath;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom;version="1.4.1"
                                        org.xml.sax.ext;version="1.4.1";uses:="org.xml.sax,org.xml.sax.helpers"
                                        org.xml.sax.helpers;version="1.4.1";uses:="org.xml.sax"
                                        org.xml.sax;version="1.4.1"
Import-Package                          javax.xml.namespace;version="[1.4,2)"
                                        javax.xml.stream.events;version="[1.4,2)"
                                        javax.xml.stream.util;version="[1.4,2)"
                                        javax.xml.stream;version="[1.4,2)"
                                        javax.xml.transform.stream;version="[1.4,2)"
                                        javax.xml.transform;version="[1.4,2)"
                                        javax.xml.validation;version="[1.4,2)"
                                        org.w3c.dom.events;version="[1.4,2)"
                                        org.w3c.dom.ls;version="[1.4,2)"
                                        org.w3c.dom.stylesheets;version="[1.4,2)"
                                        org.w3c.dom.traversal;version="[1.4,2)"
                                        org.w3c.dom.views;version="[1.4,2)"
                                        org.w3c.dom;version="[1.4,2)"
                                        org.xml.sax.ext;version="[1.4,2)"
                                        org.xml.sax.helpers;version="[1.4,2)"
                                        org.xml.sax;version="[1.4,2)"
Manifest-Version                        1.0
Originally-Created-By                   1.3.1 (IBM Corporation)
Require-Bundle                          system.bundle
Require-Capability                      osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.2))"

Note the package versions and note the non-optional imports of the exports with bounded version ranges.

This is not really a good drop-in replacement for the 1.3.4 version and I believe that the upper bounds on the imported exports is what makes package imports requirement version 2.x or higher require the older 1.3.4 version instead of the newer one.

Here is a new version that I created using an m2e location:

Ant-Version                             Apache Ant 1.7.0
Bundle-ManifestVersion                  2
Bundle-Name                             Bundle xml-apis : xml-apis
Bundle-SymbolicName                     javax.xml
Bundle-Version                          1.4.1.v20230703-0729
Created-By                              1.3.1 (IBM Corporation)
Eclipse-Wrapped-Bundle                  xml-apis:xml-apis:1.4.1
Export-Package                          javax.xml.datatype;version="1.4.1";uses:="javax.xml.namespace"
                                        javax.xml.namespace;version="1.4.1"
                                        javax.xml.parsers;version="1.4.1";uses:="javax.xml.validation,org.w3c.dom,org.xml.sax,org.xml.sax.helpers"
                                        javax.xml.stream.events;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream"
                                        javax.xml.stream.util;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream,javax.xml.stream.events"
                                        javax.xml.stream;version="1.4.1";uses:="javax.xml.namespace,javax.xml.stream.events,javax.xml.stream.util,javax.xml.transform"
                                        javax.xml.transform.dom;version="1.4.1";uses:="javax.xml.transform,org.w3c.dom"
                                        javax.xml.transform.sax;version="1.4.1";uses:="javax.xml.transform,org.xml.sax,org.xml.sax.ext"
                                        javax.xml.transform.stax;version="1.4.1";uses:="javax.xml.stream,javax.xml.transform"
                                        javax.xml.transform.stream;version="1.4.1";uses:="javax.xml.transform"
                                        javax.xml.transform;version="1.4.1"
                                        javax.xml.validation;version="1.4.1";uses:="javax.xml.transform,org.w3c.dom,org.w3c.dom.ls,org.xml.sax"
                                        javax.xml.xpath;version="1.4.1";uses:="javax.xml.namespace,org.xml.sax"
                                        javax.xml;version="1.4.1"
                                        license;version="1.4.1"
                                        org.apache.xmlcommons;version="1.4.1"
                                        org.w3c.dom.bootstrap;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.css;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.stylesheets,org.w3c.dom.views"
                                        org.w3c.dom.events;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.views"
                                        org.w3c.dom.html;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.ls;version="1.4.1";uses:="org.w3c.dom,org.w3c.dom.events,org.w3c.dom.traversal"
                                        org.w3c.dom.ranges;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.stylesheets;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.traversal;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom.views;version="1.4.1"
                                        org.w3c.dom.xpath;version="1.4.1";uses:="org.w3c.dom"
                                        org.w3c.dom;version="1.4.1"
                                        org.xml.sax.ext;version="1.4.1";uses:="org.xml.sax,org.xml.sax.helpers"
                                        org.xml.sax.helpers;version="1.4.1";uses:="org.xml.sax"
                                        org.xml.sax;version="1.4.1"
Manifest-Version                        1.0
Originally-Created-By                   1.3.1 (IBM Corporation)
Require-Capability                      osgi.ee;filter:="(&(osgi.ee=JRE)(version=1.1))"

Note the extremely low generated BREE. It uses this recipe, hence to imported exports:

Bundle-Name:            Bundle ${mvnGroupId} : ${mvnArtifactId}
version:                ${versionmask;===;${version_cleanup;${mvnVersion}}}
Bundle-SymbolicName:    javax.xml
Bundle-Version:         ${version}.v20230703-0729
Eclipse-Wrapped-Bundle: ${mvnGroupId}:${mvnArtifactId}:${version}
Import-Package:         *
Export-Package:         *;version="${version}";-noimport:=true
-noextraheaders:        true
-removeheaders:         Private-Package

Probably this version is a drop-in replacement for the 1.3.4 version...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.