[TOC]

Breaking changes to come with the 3.x releases

The default value for generateDataFetcherForEveryFieldsWithArguments will be changed to true, which makes more Data Fetchers to implement

2.x versions

Main enhancement in the 2.x releases

The generated code uses spring-graphql
Since 2.5, the generateDataFetcherForEveryFieldsWithArguments plugin param. This parameter allows to generate data fetchers for every field that has input argument, and add them in the generated POJOs.
- The default is false, to backward compatibility.

Breaking changes in 2.x versions

2.5
- [Gradle] All task properties in build.gradle files, that contain file path must now be relative to the local project root. This is due to the compatibility with the configuration cache, which changed the path resolution methods.

2.7

Client mode:

Issue #213: The GraphQL custom scalars are wired according to spring-graphql needs. This fixes bean error at startup, in some specific cases

All modes (client and server):

Issue #213: The GraphQL custom scalars which names in the provided schema is different that the GraphQL type name in the provided GraphQL scalar implementation would throw an error at execution.

Internal:

The server_GraphQLWiring.vm.java custom template has been renamed to GraphQLWiring.vm.java, as this template is now used for both the client and the server mode.

2.6

Gradle:

issue #21: dependencies for spring framework6 are enforced for graphql-gradle-plugin3

All modes (client and server):

Issue #113: base the code generation on a json schema (from an introspection query), instead of regular graphqls GraphQL schema files. This is done with the help of this new plugin parameter: jsonGraphqlSchemaFilename
Issue #208: the plugin is now marked as thread safe (no more warning when using maven parallel builds)

2.5

Gradle:

Upgrade of gradle wrapper to 8.6
Issue #14: The plugin is now compatible with Gradle configuration cache
- Possible breaking change: The path given to the task properties must now all be relatives to the root of their project (without a leading slash), eg : "build/generated/mytarget" (not "/build/generated/mytarget" or "$builDir/generated/mytarget"))
- (Pojo goals) No more need to add the generated source folder to the sourceSets.main.java.srcDirs. It is automatically added to the java source folders.

All modes:

Remove a bad java import, which could cause compilation error when just generating POJO

Server mode:

Add of the generateDataFetcherForEveryFieldsWithArguments plugin param. This parameter allows to generate data fetchers for every field that has input argument, and add them in the generated POJOs. This allows a better compatibility with spring-graphql, and an easy access to the field's parameters.
Issue #209: error with subscription that returns enum, when the implementation returns a Publisher that is not a Flux

2.4

Dependencies upgrade:

Spring boot to 2.7.18 and 3.2.1
Upgrade of plexus-utils to the 3.0.24 (to get rid of CVE vulnerabilities)

Client and server modes:

Issues #205 and #207: The JSON and Object custom scalars are now properly managed

Client mode:

When executing full requests, the query keyword was mandatory, whereas it is optional in the GraphQL specs.

2.3.2

Client and server modes:

Correction of issue #202: the generated code would not compile, if a GraphQL interface or type has a class attribute (due to the final getClass method). The generated method is get_Class()

2.3.1

Client mode:

Issue 199: the generated code would not compile if the GraphQL schema is too big
Issue #195: the data part is now parsed even when there are errors. If an error occurs during the request execution (for instance the GraphQL server returns errors in its response), then the plugin tries to parse the _data _ part of the response. The parsed data is attached to the thrown GraphQLRequestExecutionException or GraphQLRequestExecutionUncheckedException, along with the full response. They can be retrieved with the getData() and getResponse() methods.
Issue #200:
- A missing break would prevent Custom Scalars of type Boolean to be deserialized (could not read the server response)
- Alias on fields that are a Custom scalars could not be deserialized when using the deprecated ResponseType

2.3

Client and server modes:

Correction of issues #184 and #198: error with custom scalar, when the custom scalar's class is not in the plugin's classpath

Client mode:

Add of the reactive executors and GraphQL repositories:
- Queries and mutations return Mono
- Subscriptions return Flux

Gradle plugin:

Correction of the issues #13 and #18: The plugin is running all tasks instead of running only the configured tasks

2.2

Gradle plugin:

Creation of a graphql-gradle-plugin3 plugin, compiled against Spring Boot 3 and Spring Framework 6
- graphql-gradle-plugin is still available, if you' re using Spring Boot 2 and Spring Framework 5

Both mode:

The schema personalization capability is now open to both the server and client modes. It allows to:
- Add or modify fields
- Add interface and annotation to classes (GraphQL types, input types, interfaces, unions and enums) or fields.

2.1

Gradle:

A graphql-gradle-plugin3 is now available, that is compiled for Spring Boot 3.x and Spring Framework 6.x
- Due to an issue during the plugin publishing, the plugin3 version is 2.1b, whereas the runtime version is 2.1, like this:

plugins {
	...
	id 'com.graphql-java-generator.graphql-gradle-plugin3' version "2.1b"
	...
}


dependencies {
	// Use the server runtime ... for the server side :) 
	implementation "com.graphql-java-generator:graphql-java-server-runtime:2.1"

	// OR
	
	// Use the client runtime ... for the client side :) 
	implementation "com.graphql-java-generator:graphql-java-client-runtime:2.1"
	
	...
}

Samples are available for the client side and for the server side.

2.1

Both mode:

Compile dependency upgraded to Spring Boot 2.7.12 (and 3.1.0)

Server mode:

Issue #190: The Spring Entity Controllers generated by the plugin can now be overridden

Client mode:

Issue #189: using OAuth2 in spring 6 (with copyRuntimeSource=true only) would through this error: "missing createError() method in OAuthTokenExtractor.GetOAuthTokenClientResponse"

2.0

Change of some plugin parameters value (please read either [[Client migration from 1.x to 2.x|client_migrate_1-x_to_2-x]] or [[Server migration from 1.x to 2.x|server_migrate_1-x_to_2-x]] for more information) changed of default value:

copyRuntimeSources: false (both client and server mode)
generateBatchLoaderEnvironment: true (server only)
generateDeprecatedRequestResponse: false (client only)
skipGenerationIfSchemaHasNotChanged: true (both client and server mode) It was initially planned to force their value to the new default valye. But this would have too much impact on the existing code. Changing the default value allows 'old' users to minimize the impact when switching to the 2.0 version, while new user will use cleaner code.

2.0RC1

Release Candidate version for the 2.x versions.

Main changes:

Based on spring-graphql
Upgrade of dependencies, based on spring-boot 2.7.10
Needs JDK 17 to be build, but the generated artifact is compatible with Java 8
Compatibility with Spring Boot 3.
- For a sample of this, you can check the graphql-maven-plugin-samples-Forum-client and the graphql-maven-plugin-samples-Forum-server samples that are part of the build.
gradle plugin: The id changed from com.graphql_java_generator.graphql-gradle-plugin to com.graphql-java-generator.graphql-gradle-plugin

You can check these pages for more information on how to migrate from 1.x versions:

[[Client migration from 1.x to 2.x|client_migrate_1-x_to_2-x]]
[[Server migration from 1.x to 2.x|server_migrate_1-x_to_2-x]]

Know issues:

All builds for servers should be executed with a clean (mvn clean install or gradlew clean build), otherwise the GraphQL schema available at runtime becomes invalid. The server won't start.
For Spring 3, in client mode, copyRuntimeSources should be manually to false, to avoid compilation errors

1.18.11

Both modes:

Issue #179: Problem with primitive types as java type for custom scalars
The build is now Ok with java 17
Much better reliability of Subscriptions

1.18.10

Dependency upgrade:

Upgrade from graphql-java 19.2 to 20.0
Upgrade from graphql-java-extended-scalars 19.0 to 20.0

Both modes:

PR #171: Add descriptions for input parameters if they exist
Field that are java reserved keywords of either GraphQL types or GraphQL input types would cause error during request execution
- Subject started thanks to the PR #177 (Modifying the getGetter method to accept reserved keywords)

Client mode:

Issue #173: introspection query from graphql-java 19.2 would not work (the plugin was using an old introspection schema)
Issue #174: request execution error with Custom scalar that are arrays
Issue #175: adding the @JsonProperty("xxx") annotation on getter of the generated POJO would solve some issues when generating an openAPI based on the generated file, with field having case issues
Issue #176: the GraphQLRequestExecutionException class has now a getErrors() method, that allows to retrieve the list of GraphQLError returned by the server, including the extension field.

1.18.9

Dependency upgrade:

Upgrade from Spring Boot 2.7.4 to 2.7.6

Both modes:

Issue #166: Corrected an issue that prevents to request data when GraphQL field's name are java reserved keywords
Issue #164: the descriptions from the GraphQL schema is now included in the java comments for objects, fields, union...
GraphQLDirectives are now written as Java annotation in the generate code
- Note: this doesn't work yet for schema, scalar (that may receive a Directive when extended) and custom scalars

Server mode:

Issue #162: Declaring a GraphQL directive applicable to VARIABLE_DEFINITION would prevent the GraphQL server to start

1.18.8

Dependency upgrade:

Upgrade from Spring Boot 2.4.4 to 2.7.4
Upgrade from Spring Framework 5.3.5 to 5.3.23
Upgrade from graphql-java 18.3 to 19.2
Upgrade from graphql-java-extended-scalars 18.0 to 19.0
Upgrade from lombok 1.18.12 to 1.18.24 (to solve compatibility issues with JDK >= 15)

All modes:

(Thanks to agesenm-ELS) Prefix and Suffix management for POJO generated from the GraphQL schema.
- Please check these new plugin parameters: typePrefix, typeSuffix, unionPrefix, unionSuffix, enumPrefix, enumSuffix, interfacePrefix, interfaceSuffix, inputPrefix, inputSuffix

1.18.7

Dependency upgrade :

Upgrade from graphql-java 17.3 to graphql-java 18.0
Upgrade from graphql-java-extended-scalars 17.0 to 18.0

All modes:

Issue #136: most usages of the extend GraphQL keyword where not managed
Prevent endless compilation from an IDE (eclipse...) when a type is removed from the GraphQL schema
Issue Gradle n°11: maxTokens is not set by default to Integer.MAX_VALUE (=2147483647). This prevent errors on big GraphQL schemas
Issue #139: Compilation Failures, when keywords used in enum values, or query/execution/subscription fields

1.18.6

All modes:

Removed various compilation warnings in the generated code

Client mode:

Issue #132 (regression in 1.18.5). The code would not compile when generateDeprecatedRequestResponse=false and separateUtilityClasses=true.

Gradle plugin:

As soon as a task defined in the build.gradle , it is added as a dependency for the compileJava and processResources tasks
- No more need to write compileJava.dependsOn(generateServerCode) or processResources.dependsOn(generateServerCode)
Removed a warning (about a missing javax.annotation.meta.When annotation), when building from the Gradle plugin
No more Gradle 8 compatibility warning

1.18.5

Both modes (client and server):

Issue #130: A GraphQL type of name Field or Builder would prevent the generated code to compile

Client mode:

Removes some useless dependencies (that could lead to a wrong error message, about a missing graphQL bean)
commons-io upgraded from 2.8.0 to 2.11.0
commons-text upgraded from 1.8 to 1.9

Server mode:

Issue #131: Spring configuration properties like spring.codec.max-in-memory-size would be ignored.

1.18.4

Both modes (client and server):

(Issue #128) partial rewrite of the generation code, to avoid conflicts between the POJO's java types, and other class names (like Client, Date...)

Server mode:

Added a generateDataLoaderForLists plugin parameter. The default value is false, which let the generated code unchanged. When set to true, data loader methods is also generated for lists (in DataFetcherDelegates)
Added the generateDataLoaderForLists directive: it can be added to a specific GraphQL field, which type is a list of GraphQL objects, which have an id. The generated code will then make use of a Data Loader. Please read the details are on the Wiki server page.
The DataFetcherDelegate interfaces has now two methods for batch loading (instead of once before). The provided default implementation prevent side effect on the existing DataFetcherDelegate implementations. These methods are batchLoader and unorderedReturnBatchLoader. All the details are on the Wiki server page.
Upgrade of java-dataloader from version 2.2.3 to version 3.1.2

1.18.3

All modes:

Solved an issue: an Exception would be thrown when using the POJO setters with a null value.

1.18.2

Gradle plugin:

Solved a build issue, that would generate an error with some old configurations of the plugin

Server more:

Issue #122, and PR #123: NullPointerException would occurs when a notification returns a null value. This may occurs when a Subscription response is a non mandatory object or scalar. For this kind of subscription only, the DataFetcher must now return a Publisher<Optional<JavaType>> instead of a Publisher<JavaType>
- There is no impact on DataFetchers for Queries or Mutations
- There is no impact on DataFetchers for Subscriptions which return type is mandatory (like String!)

1.18.1

All modes (client and server):

Dependencies has been restructured to properly separate client and server runtimes:
- The graphql-java-runtime module no longer exists . If you're using, you must change to one of graphql-java-client-runtime or graphql-java-server-runtime.
- When copyRuntimeSources is false, the used dependencies should be either graphql-java-client-runtime or graphql-java-server-runtime
- When copyRuntimeSources is true, the used dependencies should be either graphql-java-client-dependencies or graphql-java-server-dependencies
- This solves issues #109 and #56
graphql-java upgraded from 16.2 to 17.3
- You can check the changes on the graphql-java release page
- The main changes are:
  - Non standard scalars have moved from the graphql.Scalars class (that is included in the graphql-java module) to the graphql-java-extended-scalars. So, if you're using non standard scalars like Byte, Short and Long (...), you'll probably have to change your configuration in your pom.xml or gradle.build file, from graphql.Scalars.xxx to graphql.scalars.ExtendedScalars.xxx
  - The graphQL schema is, by default, limited to 15000 tokens. This version adds the new plugin parameter maxTokens, that allows to override this limit.
Issue #114: allows overriding field's type when implementing interface

Server mode:

More robust multi-threading management for subscriptions

Upgrade of dependencies versions (to remove security issues):

h2 is used only for sample. Upgraded from 1.4.200 to 2.1.210
velocity is the template engine. Upgraded from 1.7 to 2.3
- A (positive) side effect, is that the velocity logging is managed through slf4j, like all the plugin's code logging. So this solves the issue #103, caused by velocity.log beeing created in the Intellij bin folder.

1.18

All modes (client and server):

Subscriptions are now managed with full respect of the graphql-transport-ws WebSocket sub-protocol, as defined in the graphql-ws reference library.
- Caution: if you are using Subscriptions, you must upgrade both the client(s) and the server, as the subprotocol changes in this version.
PR #101: Removes unused imports in some generated classes
generatePojo : corrected compilation errors (before this release, the graphql-java-runtime, graphql-java-client-dependencies or graphql-java-server-dependencies) was necessary to compile the generated code.

Client mode:

The Spring Configuration is an auto-configuration. This was not the case in 1.17.x releases, which would prevent the Spring @Primary annotation to work, causing a regression compared to previous version. Thanks to that, it's now easy (again) to override Spring beans.
Subscription: better exception management (especially if a connection error occurs)
Simplified and secured the code that generates the request
You can override the RequestExecution to use query, mutation and subscription according to the graphql-transport-ws. Please find a sample in the GraphQLTransportWSSpringConfiguration spring configuration class of this test

1.17.3p1

All modes:

Corrected an issue with duplicate files that can break the Gradle build

Caution: this is a Gradle only release. So, for this version, the Gradle plugin version is 1.17.3p1, whereas the graphql-java-client-dependencies, graphql-java-server-dependencies or graphql-java-runtime version is 1.17.3.

1.17.3

Client mode:

Corrected issue 98 (in the maven plugin project): Spring Bean name collision with the QueryExecutor (which is an internal Bean from the plugin). This is a regression of the previous 1.17x versions.

Internal:

The QueryExecutor interface (and its implementations) has been renamed into RequestExecution, to avoid name collision with the QueryExecutor Spring Bean, coming from the GraphQL schema.

1.17.2

Client mode:

Correction of issues #95 and #96 (of the maven project): the springBeanSuffix is now properly applied to all spring beans. Now it is also applied to the query, mutation and subscription executors, as well as all other Spring beans.

1.17

Gradle Plugin:

Corrected some issues when executing a gradlew clean build, whereas gradlew clean then gradlew build works ok

Client mode:

The generated code can now attack two (or more) GraphQL servers.
- More information on this page.
Added the ability to create GraphQL Repositories: like Spring Data Repositories, GraphQL Repositories allow to declare GraphQL requests (query, mutation, subscription) by just declaring an interface. The runtime code create dynamic proxies at runtime, that will execute these GraphQL requests.
- In other words: GraphQL Repositories is a powerful tool that allows to execute GraphQL request, without writing code for that: just declare these requests in the GraphQL Repository interface
- More information on this page.

1.16

Both mode:

The plugin now properly manages GraphQL scalar extensions
Added a control, that the version of the runtime matches the version of the plugin. Doing such a control can prevent some weird errors.
Added a check, that the provided custom templates have valid names and match to existing files (or resources in the classpath)

Client mode:

Issue #82: Using Hard coded Int parameters would raise an exception (for instance in this request: "{aRequest(intParam: 3) {...}}")

1.15

Client mode:

The queries, mutations and subscriptions now accept GraphQL aliases, like specified in GraphQL spec
- Once the request is executed, The alias value can be retrieved with the Object getAliasValue(String: aliasname) method that has been added to every generated objects and interfaces. This method returns the alias value, parsed into the relevant Java Object.
The default QueryExecutor provided by the plugin is now a Spring bean. If you want to override it, you should not mark your own QueryExecutor with the @Primary annotation, to ignore the default one.

Gradle only:

Since 1.15, the files are generated in these folders:
- Resources are generated in: build/generated/resources/graphqlGradlePlugin
- Sources are generated in: build/generated/sources/graphqlGradlePlugin

1.14.2

New goal/task added:

generatePojo: This goal allows to only generate the Java classes and interfaces that match the provided GraphQL schema.

Server mode:

Workaround to build a project with Gradle 7 without the gradle wrapper (this commit prevents a strange error during the build)

Internal:

The plugin now uses slf4j as the logging frontend framework, as do Gradle and Maven (since maven 3.1). This means that, when using Maven, the minimum release version is the 3.1 version.

1.14.1

Both mode:

Upgrade of com.google.guava, to version 30.1.1-jre, to remove a vulnerability
Upgrade of Spring boot from 2.4.0 to 2.4.4
Upgrade of Spring framework from 5.3.0 to 5.3.5
Upgrade of Spring security from 5.4.1 to 5.4.5
Upgrade of graphql-java-extended-scalars version from 1.0.1 to 16.0.1
Upgrade of commons-io from 2.6 to 2.8.0
Upgrade of dozer-core from 6.5.0 to 6.5.2
Upgrade of h2 from 1.4.199 to 1.4.200

Client mode:

Issue #65: When using requests with the parameters in the request (no GraphQL Variables and no Bind Parameter), the request is properly encoded when these parameters are or contain strings
Dependency order changed in the graphql-java-client-dependencies module, to make sure the right spring's dependencies are used (this could prevent a Spring app to start)
Removed the use of the reactor.core.publisher.Sinks class, to restore compatibility for those who uses an older version of Spring Boot

Gradle:

Update in the build.gradle to make it compatible with gradle 7

1.14

Both mode:

Upgrade of com.google.guava, to remove a vulnerability

Client mode:

Request with GraphQL variable are now accepted. Of course, this works only with full requests. You can find more information on GraphQL Variables in the GraphQL spec.
Subscription can now be executed as full request. They were previously limited to partial requests.

Custom templates:

The following templates have been updated : client_DirectiveRegistryInitializer.vm.java, client_GraphQLRequest.vm.java, client_jackson_deserializers.vm.java, client_query_mutation_executor.vm.java, client_subscription_executor.vm.java, client_subscription_type.vm.java, server_GraphQLDataFetchers.vm.java
These updates are due to:
- The GraphQLInputParameters has been updated, to now embed all the GraphQL information (prerequisite for GraphQL variable)
- The list level is now better managed (not just a boolean, but the real depth when there are lists of lists)
- The input parameters now typed with an enum, not just a boolean for mandatory/optional.
The client_query_target_type.vm.java was not used and has been removed.

1.13

Both mode:

Custom Templates can now be defined as a resource in the current project (no need to embed them in a jar prior to use them). See the CustomTemplates-client pom file as a sample for that.

Client mode:

The extensions field on the root of the GraphQL server response can be retrieved by using Full Queries. More information on the Client page about request execution
Issue #55 : the extensions field of the GraphQL errors is now properly managed. It's possible to receive any GraphQL valid response for this field. And the Error class has now the proper getters to manage it (including deserialization of the extensions map values in any Java classes)
Issue #65: It's now possible to provide a full query that contains all GraphQL parameters (without runtime parameters). More info in the Client FAQ

Server mode:

The Query/Mutation/Subscription are now available on the same URL (/graphql by default). This is the standard GraphQL behavior, but it was tricky to build, due to a Java limitation.

1.12.5

Client mode:

Issue #53: custom scalars would not be properly managed when they are a parameter of a query, mutation or subscription.

1.12.4

Server mode:

It's now possible to override the type wiring, thanks to the new GraphQLWiring class.
It's now possible to override the DataFetcher definitions, by overriding GraphQLDataFetchers. This allows, for instance, to change the DataLoader behavior.
[Internal] The GraphQLProvider class has been removed. The Spring beans it created are now created by the GraphQLServerMain class. The type wiring has been moved in the new GraphQLWiring class. This allows an easier overriding of the generated type wiring.

1.12.3

Both mode:

Corrected a multithreading issue with the provided custom scalars GraphQLScalarTypeDate and GraphQLScalarTypeDateTime

Server mode:

Issue #72: The subscription notifications would not be properly sent when more than one client subscribed to a subscription.

Client mode:

The GraphQL server response could not be deserialized, when it contains the (non standard) extensions entry

1.12.2

Both modes (client and server):

Added the skipGenerationIfSchemaHasNotChanged parameter. It's in beta version. It prevents code and resource generation, of the schema file(s) are older than these generated sources or resources. It's default value is false in 1.x releases.
When the addRelayConnections parameter is true, the XxxConnection types of the fields marked with @RelayConnection are now non mandatory.
The comments read in the provided schema are reported into the generated code and the generated GraphQL schemas.

Server mode:

The graphql-java version has been upgraded to 16.2 (the latest version at this time)
The generated code would not allow the specific implementation to override the GraphQLInvocation Spring Bean

1.12.1

Both modes (client and server):

Correction for the addRelayConnections: the Node interface was not properly copied to all implementing subtypes and subinterfaces

Server mode:

The server won't start when the graphql-java-runtime dependency is in the classpath (that is when the copyRuntimeSources plugin parameter is set to false)
When a DataFetcher has a BatchLoader, two datafetchers would be wired, instead of just one. This is internal to the generated code, and has no impact on the "user's" code.
The cache of the DataLoader is now managed for per request.
When the addRelayConnections plugin parameter is set to true, the generateServerCode task/goal (and graphql task/goal when in server mode) copies the generated schema file in the /classes folder, so that the graphql-java engine has a proper access to it, at runtime.

1.12

Both modes (client and server):

Added support for OAuth 2
Removed all dependencies to log4j
[internal] The GraphqlUtils class has been moved into the com.graphql_java_generator.util package

Client mode:

The client can now be a Spring Boot app (and that's now the recommended way to build a GraphQL app). see the plugin web site for more info on this
The subscription management has been updated. ==> Spring reactive WebSocketClient ==> The SubscriptionClient interface has a new method: WebSocketSession getSession(), which allows to retrieve the Spring reactive WebSocketSession.

Server mode:

Corrected a regression in 1.11.2, due to generateBatchLoaderEnvironment plugin parameter (see issue #64)

1.11.2

server mode:

The generated code would not compile for fields with parameters (when the field's type is an entity with an id)
Add of the generateBatchLoaderEnvironment parameter. When in server mode, it allows the batch loader to retrieve the context, for instance the field parameters associated to this id.

1.11.1

Both modes (client and server):

Upgrade of spring boot from 2.3.3 to 2.4.0
Issue 54: The generated code would not compile for subscriptions that return a list

Gradle plugin:

The plugin is now compatible with a JDK/JRE 8 (it previously needed java 13)

1.11

Both modes (client and server):

Changes in goal(maven)/task(gradle) names, to make them clear and homogeneous between the gradle and the maven plugin:
- The graphql maven goal (and graphqlGenerateCode gradle task) are deprecated, but they will be maintained in future 2.x versions
- The goal(maven)/task(gradle) are now:
  - generateClientCode : generates the Java code on client side, to access a GraphQL server, based on its GraphQL schema. It is the same as the deprecated graphql maven goal (or graphqlGenerateCode gradle task), with the mode parameter removed (it is internally forced to client).
  - generateServerCode : generates the Java code on server side, to access a GraphQL server, based on its GraphQL schema. It is the same as the deprecated graphql maven goal (or graphqlGenerateCode gradle task), with the mode parameter removed (it is forced to server).
  - generateGraphQLSchema : new, see below
  - graphql (maven) / _graphqlGenerateCode (gradle) : deprecated and maintained. It's the same as the new generateClientCode and generateServerCode goals/tasks, with the mode plugin parameter that allows to choose between the client or the server mode.
New generateGraphQLSchema goal/task that allows to generate the GraphQL schema file. It's interesting when:
- There are several GraphQL schema files in input (for instance with the extends GraphQL capability)
- The addRelayConnections is used, that adds the Node interface, and the Edge and Connection types to the schema.

Client Mode (generateClientCode):

Corrected issue 50: could not work with nested arrays (for instance [[Float]])
Corrected issue 51: error with argument being a list of ID ([ID])

1.10

Both modes (client and server):

Upgrade of graphql-java from v14.0 to v15.0
The main improvement for this is: the plugin now accepts interfaces that implement one or more interfaces
Attributes of input types that are enum are now properly managed

Server mode:

The generated code would not compile if a GraphQL interface is defined, but not used, in the given GraphQL schema

1.9

Both modes (client and server):

The GraphQL schema can now be split into separate files, including one file containing GraphQL extend keyword on the other file's objects
Add of the merge goal/task: it generates a GraphQL schema file, based on the source GraphQL schemas. It can be used to merge several GraphQL schema files into one file, or to reformat the schema files.

Client mode:

Fixes #46: Strings not properly escaped for JSON

1.8.1

Both modes (client and server):

The generated code was not compatible with Java 8 (only with Java 9 and above)

1.8

Both modes (client and server):

Corrected issue #43: GraphQL Float was mapped to Float, instead of Double

Client mode:

a XxxxExecutor class is now generated for each query, mutation and subscription types, for better separation of GraphQL objects and utility classes . They contains the methods to prepare and execute the queries/mutations/subscriptions that were in the query/mutation/subscription classes. These the query/mutation/subscription classes are still generated, but their use to prepare and execute the queries/mutations/subscriptions is now deprecated.
- In other word: existing code CAN remain as is. It'll continue to work.
- New code SHOULD use the XxxExecutor classes.
Add of the generateDeprecatedRequestResponse. Default value is true, which makes it transparent for existing code. If set to false, the XxxResponse classes are not generated (where Xxx is the GraphQL name for the query, mutation and subscription objects), nor the Xxxx classes in the util subpackage (only if separateUtilityClasses is true). If generated, these classes are marked as Deprecated, and should not be used any more.
Solved issue #44: no more need to add an extension bloc in the build pom's bloc, to make the plugin work.
Named Fragments would not work if seperateUtilityClass was false

Server mode:

Added the scanBasePackages plugin parameter. It allows to create our Spring Beans, including the DataFetchersDelegateXxx implementation in another place than a subpackage of the package define in the packageName plugin parameter
Corrected a dependency issue (for server implemented from the code generated by the plugin)

1.7.0

Both modes (client and server):

The plugin now manages subscription
For custom templates: the QUERY_MUTATION_SUBSCRIPTION template has been split into two templates, QUERY_MUTATION and SUBSCRIPTION

Server mode:

In some cases, the DataFetcherDelegate now have another DataFetcher that must be implemented
Some server templates rename, to respect java standards. An underscore has been added to these templates name: BATCH_LOADER_DELEGATE, BATCH_LOADER_DELEGATE_IMPL, DATA_FETCHER and DATA_FETCHER_DELEGATE

1.6.1

Both modes (client and server):

Default value for input parameters (fields and directives) that are null, array or an object are now properly managed.
Plugin parameter copyGraphQLJavaSources renamed to copyRuntimeSources
New Plugin parameter separateUtilityClasses: it allows to separate the generated utility classes (including GraphQLRequest, query/mutation/subscription) in a subfolder. This avoids collision in the generated code, between utility classes and the classes directly generated from the GraphQL schema.

Client mode:

Thanks to the separateUtilityClasses plugin parameter, the plugin can generate the code for the shopify and github GraphQL schema (needs some additional tests: tester need here...)

1.6.0

Both modes (client and server):

Added a templates plugin parameter, that allows to override the default templates. This allows the developper to control exactly what code is generated by the developer.
Added a copyGraphQLJavaSources that allows to control whether the runtime code is embedded in the generated (previous behavior, set as the default behavior), or not. ==> copyGraphQLJavaSources renamed to copyRuntimeSources in 1.7.0 version
Removed the unused java annotation GraphQLCustomScalar
Solved issue #35: argument for directive could not be CustomScalar, Boolean, Int, Float or enum (enum are still not valid on the server side of this plugin, due to a graphql-java 14.0 limitation, see graphql-java/graphql-java#1844 for more details)

Client mode:

Added GraphQL fragment capability. Query/mutation/subscription can now contain Fragment(s) and inline Fragment(s), including directives on fragments.
Added support for GraphQL Union
The client code has been highly simplified :
- The Builder support is now limited to the withQueryResponseDef(String query) method.
- The support for the withField(), withSubObject() (...) methods has been removed
- The __IntrospectionQuery class is no more generated: the __schema and __type queries has been added to the GraphQL schema's query, as defined in the GraphQL spec. A default query is added if no query was defined in the GraphQL schema.
- The client code should now use the GraphQLRequest that is now generated along with the GraphQL java classes.
- A GraphQLConfiguration class has been added. The generated query/mutation/subscription classes create an instance of this class, so there is no impact on existing code. But this class must be used to configure the GraphQLRequest.
- Please check the behavior of your full queries: the mutation keyword is now mandatory for mutations, as specified in the GraphQL specification. The query keyword remains optional.
- Please the client mode doc for more information.

1.5.0

Both modes (client and server):

GraphQL Directives are now managed
GraphQL types can implement multiple interfaces
Upgrade of graphql-java from v13.0 to v14.0

Client mode:

Directives can be added in the query, on query and fields (fragment is for a next release, coming soon)
The query/subscription/mutation classes have now a collection of exec methods, which allows to execute several queries/mutations/subscriptions in one server call. This allows to add directive on the queries/mutations/subscriptions. Please the client mode doc for more information.
Added a queryName/mutationName/subscriptionName that accept bind parameters, for each query/mutation/subscription. Please have a look at the allGraphQLCases client tests, in the org.allGraphQLCases.FullQueriesDirectIT class
interfaces are properly deserialized, thanks to GraphQL introspection. (caution: code impact. Previously, for each interface, the plugin would generated a concrete class that doesn't exist in the GraphQL schema. This is not the case any more, and only GraphQL types are now generated
The __typename is added to the list of scalar fields, for every request GraphQL nonscalar type. This allow to properly deserialize interfaces and unions.

1.4.0

Both modes (client and server):

The plugin is compatible again with java 8
The provided Date and DateTime scalars are now provided as a static field (instead of the class itself), due to a graphql-java change)

Client mode:

Can now invoke GraphQL introspection queries (it was already the case on server side, thanks to graphql-java)

1.3.2

Both modes (client and server):

Input parameters are now managed for scalar fields (custom or not)
Removed the dependency to log4j, replaced by slf4j
the GraphQL schema may now use java keywords (if the GraphQL schema uses identifiers that are java keywords, these identifiers are prefixed by an underscore in the generated code)

Client mode:

Added a constructor in the generated query/mutation/subscription with a preconfigured Jersey client instance to support customization of the rest request

1.3.1

Both modes (client and server):

The project now compiles up to JDK 13 (the generated code is still compatible with java 8 and higher)
Unknown GraphQL concept are now ignored (instead of blocking the plugin work by throwing an error)

1.3

Both modes (client and server):

Custom Scalars are now properly managed. You can provide your own Custom Scalars, or used the ones defined by graphql-java
Fixed issue 8: Problem when using Boolean Type with property prefix "is"

1.2

Both modes (client and server):

Corrected a bad dependency version, which prevents the released plugin to work
Input object types are now accepted
[CAUTION, code impact] All GraphQL exceptions have been moved into the com.graphql_java_generator.exception package

Client mode:

Connection to https is made simpler (just declare the https URL)
Input parameters are properly managed for queries, mutations and regular GraphQL type's field. It's possible to prepare query with Bind variables, like in JPA
Only for request prepared by the Builder: simplification and change in the way to construct ObjectResponse objects
Exception GraphQLExecutionException renamed to GraphQLRequestExecutionException

Server mode:

XxxDataFetchersDelegate interfaces renamed as DataFetchersDelegateXxxx (code is easier to read, as the DataFetchersDelegates are grouped together in the classes list)
Input parameters are accepted for queries, mutations and object's field.
Add of the generateJPAAnnotation plugin parameter (default to false)

Files

CHANGELOG.md

Latest commit

History

CHANGELOG.md

File metadata and controls

Breaking changes to come with the 3.x releases

2.x versions

Main enhancement in the 2.x releases

Breaking changes in 2.x versions

2.7

2.6

2.5

2.4

2.3.2

2.3.1

2.3

2.2

2.1

2.1

2.0

2.0RC1

1.18.11

1.18.10

1.18.9

1.18.8

1.18.7

1.18.6

1.18.5

1.18.4

1.18.3

1.18.2

1.18.1

1.18

1.17.3p1

1.17.3

1.17.2

1.17

1.16

1.15

1.14.2

1.14.1

1.14

1.13

1.12.5

1.12.4

1.12.3

1.12.2

1.12.1

1.12

1.11.2

1.11.1

1.11

1.10

1.9

1.8.1

1.8

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.2

1.3.1

1.3

1.2