You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Closure-compiler is our upstream for generating the final JS output, so all else being equal, we avoid extra patches on them which then need to be maintained. They have the behavior that if an included .js file has some @license in the jsdocs, it will be included in the final output.
As of Dec 2019, closure-library now includes such a license, so all output of this plugin now bears a license header indicating that it is apache licensed, and copyright "The Closure Authors". See google/closure-compiler#3551 for more discussion.
Javadoc doesn't have a formal convention for listing a license like closure's flavor of jsdoc (and possibly other jsdocs, i'm not an expert), so tweaking j2cl to correctly generate headers consistently seems difficult. So far, google/j2cl is punting on it (both as a transpiler and for the bazel rules), but I think we need the maven plugin to solve this correctly. See (on-going?) discussion at google/j2cl#80.
Being a maven plugin, we also have extra information about a project than just what is in the .java file (similar to bazel) - the maven element could be used to try to generate a simple header automatically. The issue lies (as discussed in google/j2cl#80) in how to correctly attach these to the final output. My best off-the-cuff suggestion is that regardless the outcome of #26, we continue to ask for an entrypoint to be included in the plugin config, and either a .native.js file is created for it, or the licenses that appear to apply to this project are appended: all runtime dependencies of the project being compiled would have their licenses added.
Basic options:
Fork j2cl and add a new flag or something, allowing a license header to be included on all .java.js output files automatically, and feed that from the pom's tags.
Fork closure-compiler and remove this licensing mechanism entirely (or at least make it optional), and leave it to projects which use this plugin to correctly handle licensing (as GWT2 does today).
Wait for closure-compiler or j2cl to change their perspectives and hope that this gets made a moot point somehow (this is not a serious option, until it is).
This discussion was converted from issue #29 on March 09, 2021 16:40.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Closure-compiler is our upstream for generating the final JS output, so all else being equal, we avoid extra patches on them which then need to be maintained. They have the behavior that if an included
.js
file has some@license
in the jsdocs, it will be included in the final output.As of Dec 2019, closure-library now includes such a license, so all output of this plugin now bears a license header indicating that it is apache licensed, and copyright "The Closure Authors". See google/closure-compiler#3551 for more discussion.
Javadoc doesn't have a formal convention for listing a license like closure's flavor of jsdoc (and possibly other jsdocs, i'm not an expert), so tweaking j2cl to correctly generate headers consistently seems difficult. So far, google/j2cl is punting on it (both as a transpiler and for the bazel rules), but I think we need the maven plugin to solve this correctly. See (on-going?) discussion at google/j2cl#80.
Being a maven plugin, we also have extra information about a project than just what is in the
.java
file (similar to bazel) - the maven element could be used to try to generate a simple header automatically. The issue lies (as discussed in google/j2cl#80) in how to correctly attach these to the final output. My best off-the-cuff suggestion is that regardless the outcome of #26, we continue to ask for an entrypoint to be included in the plugin config, and either a .native.js file is created for it, or the licenses that appear to apply to this project are appended: all runtime dependencies of the project being compiled would have their licenses added.Basic options:
Beta Was this translation helpful? Give feedback.
All reactions