jakartaee / cdi-tck Goto Github PK
View Code? Open in Web Editor NEWCDI TCK
License: Apache License 2.0
CDI TCK
License: Apache License 2.0
While there was a 2.0.6.SP1 release to maven, we did not update the Jakarta EE 8 TCK, so that needs to happen as well.
org.jboss.cdi.tck.tests.event.metadata.EventMetadataTest
Micronaut will return a custom instance of ParameterizedType
which is not going to match the reflection implementation.
Currently, the project fetches some dependencies from jboss repositories which is fine.
However, it declares the repo using http
instead of https
which becomes an issue with newer Maven (3.8.1+).
Maven changed their default behavior because of a CVE issue, see also https://maven.apache.org/docs/3.8.1/release-notes.html
Any build (TCK or an impl using them) with the above stated maven version will end with something like;
Failed to read artifact descriptor for org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not transfer artifact org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [jboss-public-repository-group (http://repository.jboss.org/nexus/content/groups/public, default, releases)]
We should be able to simply switch over to https
declaration to fix this - I will issue respective PRs shortly.
Note that this will not only break latest master but also 3.x and 2.x making the build fail - we should probably issue a fix into all versions and possibly cut a release?
Otherwise any consumers need to either specify a mirror (which cannot be declared in pom.xml
, it has to reside in settings.xml
) or they would have to re-define the repository with the same <id>
inside their POMs.
The following file does not reference the Jakarta EE 9 schema https://github.com/eclipse-ee4j/cdi-tck/blob/master/impl/src/main/resources/org/jboss/cdi/tck/tests/implementation/simple/resource/persistenceContext/persistence.xml
Breaking up the sets of tests into separate categories, first @interceptors based tests need to added to the CDI_FULL test group.
As per the discussed 4.0 CDI changes, the default discovery mode for an empty beans.xml file needs to change from ALL to ANNOTATED.
I think this repository needs a license file in the TLD. Please consider adding the appropriate documentation.
According to the spec:
If a producer field is annotated @Inject, the container automatically detects the problem and treats it as a definition error.
I would assume that this class should throw an error on deploy of BeanManagerTest
:
@Dependent
public class Snake {
@Inject
@Produces
int age;
public Snake(String name) {
}
}
Currently, we have no coverage for @SkipIfPortableExtensionPresent
- an annotation that can be used when portable extensions and build compatible extensions co-exist in a CDI Full environment.
We should add a simple smoke test for it.
Note that this will have to belong to a Full
category.
The way the test will look will be affected by resolution of jakartaee/cdi#585
The org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest#testResourceBeanTypes is validating the number of types seen in the Bean type with the Greeting annotation. It is expecting a total of four types, which through Java SE 11 would include:
java.lang.Boolean
java.io.Serializable
java.lang.Comparable
java.lang.Object
In Java SE 12 the java.lang.Boolean class includes an additional java.lang.Constable interface, and so this test fails when run under a JVM later than Java SE 11. The test should just compare the expected types to what are seen on the JVM local Boolean.class to avoid JVM version dependencies.
Breaking up the sets of tests into separate categories, portable extension based tests need to added to the CDI_FULL test group.
Breaking up the sets of tests into separate categories, passivation based tests need to added to the CDI_FULL test group.
With new CDI version, we want to change default empty beans.xml
perception from ALL
discovery to ANNOTATED
discovery.
This requires a new TCK test - I will prepare a PR with it.
The repo still uses travis config which is now dead.
We should add GH actions as we did for CDI API repo.
Currently EE10 is targeting allowing or even requiring that a TCK can be run under Java SE 17. Currently the embedded set of tests pass, but when running against the wildfly23 preview, there is a problem loading the arquillian wildly container configuration:
✏️ [starksm@Scotts-iMacPro#1531]-(JavaVirtualMachines)
└> $JAVA_HOME/bin/java -version
openjdk version "11.0.7" 2020-04-14 LTS
OpenJDK Runtime Environment Zulu11.39+15-CA (build 11.0.7+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.39+15-CA (build 11.0.7+10-LTS, mixed mode)
✏️ [starksm@Scotts-iMacPro#1532]-(starksm64-core)-[git://master ✔]-
└> mvn verify -f jboss-tck-runner/pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO] Running TestSuite
...
INFO: Invoke StereotypeWithAlternativeSelectedByPriorityTest.testStereotypeAlternativeIsEnabled: 15/1,808 Failed tests: 0 (12)
[Utils] [ERROR] [Error] java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:146)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:89)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:49)
at org.jboss.arquillian.testng.Arquillian$1.initialValue(Arquillian.java:58)
at org.jboss.arquillian.testng.Arquillian$1.initialValue(Arquillian.java:55)
at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
at org.jboss.arquillian.testng.Arquillian.arquillianArgumentProvider(Arquillian.java:240)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:133)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:77)
at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:46)
at org.testng.internal.MethodInvocationHelper.invokeDataProvider(MethodInvocationHelper.java:146)
at org.testng.internal.Parameters.handleParameters(Parameters.java:798)
at org.testng.internal.Parameters.handleParameters(Parameters.java:740)
at org.testng.internal.ParameterHandler.handleParameters(ParameterHandler.java:59)
at org.testng.internal.ParameterHandler.createParameters(ParameterHandler.java:38)
at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:791)
at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:146)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at org.testng.TestRunner.privateRun(TestRunner.java:794)
at org.testng.TestRunner.run(TestRunner.java:596)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:377)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:371)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:332)
at org.testng.SuiteRunner.run(SuiteRunner.java:276)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1212)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1134)
at org.testng.TestNG.runSuites(TestNG.java:1063)
at org.testng.TestNG.run(TestNG.java:1031)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:284)
at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:119)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
Caused by: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.GeneratedConstructorAccessor52.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:144)
... 43 more
Caused by: java.lang.IllegalArgumentException: No container or group found that match given qualifier: wildfly-23
While running under Java SE 11 produces:
✏️ [starksm@Scotts-iMacPro#1543]-(starksm64-core)-[git://master ✔]-
└> $JAVA_HOME/bin/java -version
java version "11.0.7" 2020-04-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)
✏️ [starksm@Scotts-iMacPro#1544]-(starksm64-core)-[git://master ✔]-
└> mvn verify -f jboss-tck-runner/pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO] ----------------< org.jboss.weld:weld-jboss-runner-tck >----------------
[INFO] Building CDI TCK runner (4.0) for Weld (WildFly) 4.0.2-SNAPSHOT
...
[INFO] Tests run: 1218, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.148 s - in TestSuite
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1218, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
I haven't found any mention of the default interceptor order in the spec but I saw multiple tests that are assuming some order:
org.jboss.cdi.tck.interceptors.tests.order.aroundConstruct.AroundConstructOrderTest
org.jboss.cdi.tck.interceptors.tests.contract.aroundConstruct.AroundConstructTest
- testExceptions
org.jboss.cdi.tck.interceptors.tests.contract.aroundConstruct.bindings.AroundConstructTest
- testExceptions
Should it be required to have all of the interceptors annotated with `@Dependent?
Test coverage issue for jakartaee/cdi#521
We should be able to use some tests that are already existing in Weld.
This project refers to the Java EE JCP based TCK User Guide. Please consider contributing this to the Jakarta EE project so that it can be updated with the correct process details can be included (as well as updates related to Jakarta versions, etc.)
Just checking out the project and running mvn clean install
with JDK 11 gives:
[WARNING]
java.lang.NoClassDefFoundError: javax/annotation/Generated
at org.jboss.test.audit.generate.SectionsClassGenerator.generateSource (SectionsClassGenerator.java:121)
at org.jboss.test.audit.generate.SectionsClassGenerator.generateToFile (SectionsClassGenerator.java:196)
at org.jboss.test.audit.generate.SectionsClassGenerator.main (SectionsClassGenerator.java:83)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
at java.lang.Thread.run (Thread.java:834)
Caused by: java.lang.ClassNotFoundException: javax.annotation.Generated
at java.net.URLClassLoader.findClass (URLClassLoader.java:471)
at java.lang.ClassLoader.loadClass (ClassLoader.java:589)
at java.lang.ClassLoader.loadClass (ClassLoader.java:522)
at org.jboss.test.audit.generate.SectionsClassGenerator.generateSource (SectionsClassGenerator.java:121)
at org.jboss.test.audit.generate.SectionsClassGenerator.generateToFile (SectionsClassGenerator.java:196)
at org.jboss.test.audit.generate.SectionsClassGenerator.main (SectionsClassGenerator.java:83)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
at java.lang.Thread.run (Thread.java:834)
This is not very friendly and we should find the cause and fix it.
Going through some dep updates in Weld, I figured I cannot update TestNG from 6.x to 7.x because newer versions by default disable loading DTD from unsecure urls. And the files are declared in CDI TCK, namely here and here.
There are a few more tweaks needed in TCKs to update testng, such as custom listener extending a removed interface but I think master TCKs should be kept up to date instead of staying on an older version.
Changes done in jakartaee/cdi#549 remove the affect of present/absent version
attribute of beans.xml on chosen bean discovery mode.
I recall that I saw at least one test that verifies this. We should look that up and adjust it.
The TCK has various tck-audit-*.xml files that conform to the http://jboss.com/products/weld/tck/audit schema that providing a mapping from specification assertions and associated text to the actual unit test. This has gotten out of date, and it should be a goal to bring these files back into alignment with the specifications.
With the move to asciidoc, it may be possible to create a converter that allows for the generation of the audit files.
The current approach that attempts to reload classes generated from annotation processing is producing class loading issues, so we need to use a two pass approach that allows the test source to be passed to an annotation processor via the SourceProcessor SPI, and then run the tests against the resulting updated tests.
Add a new parent org.jboss.cdi.tck.tests.full package to use as the root for all CDI tests with the cdi-full group. This should be done as test group is updated.
In looking at current core tests failures related to missing bean defining annotations, I came across the org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.injection.decorated package tests. These are using @decorated and validating the requirements around that qualifier.
Another test is org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.injection.BuiltinDecoratorInjectionTest
As part of jakartaee/cdi#583 I encountered several parts on the lang model TCK that were problematic with JDK 16 while passing with JDK 11.
This concerns any runtime CDI Full implementation (in this case Weld) that will use Java reflection as a basis for the lang model.
An example of the issue is a method with receiver containing generics:
public void methodWithReceiver(@AnnReceiver1 ReceiverOnGenericClass<T> this) {
}
When accessed via reflections. with: ReceiverOnGenericClass.class.getDeclaredMethod("methodWithReceiver").getAnnotatedReceiverType().getType()
this will return:
{Class} "class org.jboss.cdi.lang.model.tck.ReceiverOnGenericClass"
{ParameterizedTypeImpl} "org.jboss.cdi.lang.model.tck.ReceiverOnGenericClass<T>"
This then leads to conflicting expectationd in the lang model interpretation and the TCK assertions.
I have found three cases which are problematic with different JDKs; I'll send a PR that changes the TCK to accept both variants with a TODO
comment explaining it.
As a side note, none of them affects CDI functionalities.
After pulling in the latest updates I'm seeing the following test failure in the org.jboss.cdi.tck.tests.full.* tests:
[ERROR] Tests run: 470, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 24.854 s <<< FAILURE! - in TestSuite
[ERROR] org.jboss.cdi.tck.tests.full.event.observer.extension.BeanManagerObserverNotificationTest.fireEvent Time elapsed: 0.073 s <<< FAILURE!
org.testng.TestNGException:
Cannot inject @Test annotated Method [fireEvent] with [class org.jboss.cdi.tck.tests.full.event.observer.extension.Giraffe, class [Ljava.lang.annotation.Annotation;].
For more information on native dependency injection please refer to https://testng.org/doc/documentation-main.html#native-dependency-injection
The problem is the addition of the @test(groups = CDI_FULL) at the class level is causing all public methods to be treated as test methods. This class only has one test, so moving the groups setting to that test fixes the problem.
CDI API has version 4.0.0.x
CDI TCK has version 4.1.0.x
This needs to be aligned and as discussed on the meeting today (23.11.), we agreed that having TCKs as 4.1.0 was a mistake, not intention. Therefore, we need to change the current project version from 4.1.0-SNAPSHOT
to 4.0.0-SNAPSHOT
and any subsequent releases should contain version 4.0.0
instead.
This isn't a big deal as all version 4 releases up until now were only Alphas.
As per the Jakarta EE 9 release plan any CDI tests that reference the below mentioned optional technologies should be removed or made optional.:
Specifications Added to Jakarta EE 9
The following specifications previously part of Java SE 8 will be added to Jakarta EE 9 either as required or optional specifications as indicated and MUST be moved to the jakarta namespace.
Jakarta Activation (Required)
Jakarta XML Binding (Optional)
Jakarta XML Web Services (Optional)
Jakarta Web Services Metadata (Optional)
Jakarta SOAP with Attachments (Optional)
Note that this impacts both Full Platform + Web Profile.
These tests use @Test(groups = CDI_FULL)
, but are not in the full
package. We should move them.
Issue is described in jakartaee/cdi#563
If we decide to accept the proposed solution, we'll need a simple TCK test that asserts this for standard class-based bean.
CDI API 4.0.0.Alpha1 removed some long deprecated methods.
CDI TCK are still using those (BM.fireEvent()
, @New
tests etc) so we need to rework those tests and cut a release which can be consumed by implementors.
Many tests do need to be updated for the empty beans.xml default behavior defined in:
jakartaee/cdi#500
Many beans need the @dependent annotation added to be seen.
Provided jakartaee/cdi#495 gets accepted, we will need test coverage for it.
Namely we need tests that:
@Stereotype
with @Priority
to enable interceptor@Stereotype
with @Priority
to enable decorator (Full only!)@Stereotype
with @Priority
to enable alternative@Alternative
bean declaring two stereotypes both of which have @Priority
and the bean itself doesn't declare @Priority
@Alternative
bean declaring two stereotypes both of which have @Priority
and the bean itself does declare @Priority
@Priority
and assertion that the most specific value is takenEDIT: TCKs should only cover the case of @Stereotype
with @Priority
used to enable alternatives as that is the main goal of this addition.
Issue to track a test for the new BeanConfigurator.priority jakartaee/cdi#532 change
DisposalMethodDefinitionTest
should detect an incorrect definition of DisposalNonBean
on deploy.
If there is no producer method or producer field declared by the bean class that is assignable to the disposed parameter of a disposer method, the container automatically detects the problem and treats it as a definition error.
Build compatible extensions (in their @Enhancement
and @Registration
) phases state that their methods need to have exactly one parameter from certain types.
We should provide tests that break these restrictions (multiple or no params) and are expecting a deployment problem.
We need to distinguish between test common to both CDI-lite and the full CDI specification requirements. Discussions concluded that the best way to do this would be via a new cdi-full test group to mark tests that make use of features like @interceptors, @decorator, passiviation, portable extensions, etc.
If jakartaee/cdi#577 we need to review all tests using this scope and whether they have Full category.
A quick grep
shows a bunch of them, but not too many, which are possible candidates for this move.
This only concerns TCK tests that require EE container (WFLY, GF, Liberty,...) to run.
I have cobbled together a WFLY with CDI 4 and Weld 5 snapshot and I am running it against TCKs. This is uncovering some (roughly) 200 tests that are failing. Most failures will be just missing annotations because of empty beans.xml
or other trivial changes.
I am planning to look into it and send a PR within a day or two.
@starksm64 all previous CDI TCK releases were available as artifacts in maven central.
Would it be possible to keep it that way under jakarta?
Having a ZIP released is nice but most projects run simply on maven artifacts and having a release which is not downloadable is awkward.
I am talking about latest TCK 2.0.6 release which is only available as ZIP. Moving Weld to use Jakarta GAVs all the way, I OFC encountered this. I'd have to re-do the TCK testing infrastructure which up to this point relied on TCKs being a downloadable artifact and as such bringing in a bunch of required dependencies.
If you want to run the TCKs now, you'd need to get the release, unpack it and install it to local maven repository. That's viable if you do a one time check but becomes really bothersome if you are running TCKs as a part of regular testsuite.
CDI Lite comes with a new language model abstraction that needs to be tested.
As this API is a potential subject for extraction into a separate module, tests should be written in some standalone manner.
Testing with Java SE 17 (early access) to run https://download.eclipse.org/jakartaee/cdi/3.0/cdi-tck-3.0.1-dist.zip tests + WildFly master is seeing failure:
[ERROR] org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes Time elapsed: 0.04 s <<< FAILURE!
java.lang.AssertionError
at deployment.dedc6d5ace7963e7119a9865eca6c1a74203870.war//org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes
This is already resolved for upstream issue #238.
Needed action:
challenge
label for this issue.org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes
test to be in the cdi-tck-3.0.2-dist.zip or in the next cdi-tck-3.0.*-dist.zip release.CDI 4.0 introduces build compatible extensions that will work under both, CDI Lite and Full.
We need to create tests for the functionality that will be akin to what we do for portable extensions.
Breaking up the sets of tests into separate categories, @ Decorator based tests need to added to the CDI_FULL test group.
@starksm64 This change became incorrect after accepting the following change into cdi master - jakartaee/cdi#445
The test asserts that you can return a provider which return null
for its getCDI()
call, but the code now guards against it.
I will send a fix for this shortly.
The CDI TCK currently uses the Shrinkwrap API to construct its test applications, including dynamic generation of metadata files like beans.xml. This results in all of the beans.xml files in the TCK being stuck at version 1.1:
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" bean-discovery-mode="all" version="1.1" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"/>
With the release of Jakarta EE 9 and the switch to the jakarta namespace, these should all be updated to version 3.0.
Based on today's CDI call, we want to revert #256, and then redo it in smaller stages based on small blocks of packages of tests after first applying the cdi-full group to tests based on:
We also want to move the cdi-full tests into a new package to separate them from the lite tests as this regrouping is done. The issue for that is #272.
With the non-Lite tests moved under the full package and labelled with the cdi-full test group, the Weld jboss-tck-runner emedded tests show the following failure count due to missing bean defining annotations:
[ERROR] Tests run: 1423, Failures: 385, Errors: 0, Skipped: 245
The next step in #273 is to add the missing bean defining annotations to obtain a clean run of the core tests under Weld.
When the JarArchiveBuilder was introduced to test cdi-lite specific behavior, it added a call to processSources(archive) to attache the test source files to the archive for use in build time processing. It was not added to WebArchiveBuilder because it was not clear if we would switch all cdi-lite tests to use JarArchiveBuilder. Since we are not, we need to add source addition to the WebArchiveBuilder as well.
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.