ClojureScript

Unspecified dependency on google-closure-library-third-party

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Temporary fix to this issue: Add the G.Closure Library third-party extensions as a project dependency.

;; In :dependencies vector of Leiningen's project.clj
[org.clojure/google-closure-library-third-party "0.0-2029"]

We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this G.Closure mailing list discussion.

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in script/cljsc and a NullPointerException in lein-cljsbuild.

See the initial Clojure-dev mailing list discussion and discussion of this ticket.

See also lein-cljsbuild issue #155.

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a declared dependency on the third-party extensions JAR. This best reflects the actual dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party-licensed code from projects which do not actually require it.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR. This makes the dependency more visible to ClojureScript developers.

Regardless of the approach taken, developers can always use explicit dependencies/exclusions to choose which version of the G.Closure library to include in their projects.

Activity

Stuart Sierra made changes -
Field Original Value New Value
Description See [mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions.

See [Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ]
Stuart Sierra made changes -
Description We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions.

See [Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ]
We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ].

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in cljsbuild and a NullPointerException in lein-cljsbuild.

See [Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a *declared dependency* on the third-party extensions JAR. This best reflects the *actual* dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party licenses from projects which do not actually require them.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR.
Assignee Stuart Sierra [ stuart.sierra ]
Stuart Sierra made changes -
Description We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ].

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in cljsbuild and a NullPointerException in lein-cljsbuild.

See [Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a *declared dependency* on the third-party extensions JAR. This best reflects the *actual* dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party licenses from projects which do not actually require them.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR.
We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ].

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in script/cljsc and a NullPointerException in lein-cljsbuild.

See the [initial Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ] and [discussion of this ticket|https://groups.google.com/d/msg/clojure/SFX4m0h6Z0g/gLLGOJFhSwsJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a *declared dependency* on the third-party extensions JAR. This best reflects the *actual* dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party-licensed code from projects which do not actually require it.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR. This makes the dependency more visible to ClojureScript developers.

Regardless of the approach taken, developers can always use explicit dependencies/exclusions to choose which version of the G.Closure library to include in their projects.
Stuart Sierra made changes -
Description We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ].

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in script/cljsc and a NullPointerException in lein-cljsbuild.

See the [initial Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ] and [discussion of this ticket|https://groups.google.com/d/msg/clojure/SFX4m0h6Z0g/gLLGOJFhSwsJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a *declared dependency* on the third-party extensions JAR. This best reflects the *actual* dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party-licensed code from projects which do not actually require it.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR. This makes the dependency more visible to ClojureScript developers.

Regardless of the approach taken, developers can always use explicit dependencies/exclusions to choose which version of the G.Closure library to include in their projects.
Temporary fix to this issue: Add the G.Closure Library third-party extensions as a project dependency.

{code}
;; In :dependencies vector of Leiningen's project.clj
[org.clojure/google-closure-library-third-party "0.0-2029"]
{code}

----

We currently distribute the Google Closure Library in two separate JARs: the main library and the third-party extensions. We do this because the third-party extensions are covered by different licenses.

But, as it turns out, various classes in the main library have explicit dependencies on things in the third-party extensions. See See also this [G.Closure mailing list discussion|https://groups.google.com/d/msg/closure-library-discuss/4DG-XJn0s4E/i7nlq84V41kJ].

As a result, the ClojureScript browser-connected REPL has a transitive dependency on the Google Closure Library third-party extensions. This manifests as an error in script/cljsc and a NullPointerException in lein-cljsbuild.

See the [initial Clojure-dev mailing list discussion|https://groups.google.com/d/msg/clojure/kzzBoCZiAx0/W_wlfiSTMZgJ] and [discussion of this ticket|https://groups.google.com/d/msg/clojure/SFX4m0h6Z0g/gLLGOJFhSwsJ].

See also [lein-cljsbuild issue #155|https://github.com/emezeske/lein-cljsbuild/issues/155].

It seems that the dependency on third-party extensions is unavoidable. There are several possible fixes:

1. Release a new G.Closure Library JAR with a *declared dependency* on the third-party extensions JAR. This best reflects the *actual* dependency relationships.

2. Release a new G.Closure Library JAR with the third-party extensions included in the JAR. This would make it harder to exclude the third-party-licensed code from projects which do not actually require it.

3. Release a new version of ClojureScript with a declared dependency on the third-party extensions JAR. This makes the dependency more visible to ClojureScript developers.

Regardless of the approach taken, developers can always use explicit dependencies/exclusions to choose which version of the G.Closure library to include in their projects.
Herwig Hochleitner made changes -
Attachment 0001-CLJS-418-closure-r0.0-2029-2-specifies-dependency-on.patch [ 11745 ]
Herwig Hochleitner made changes -
Attachment 0001-CLJS-418-closure-r0.0-2029-2-specifies-dependency-on.patch [ 11745 ]
Herwig Hochleitner made changes -
Stuart Sierra made changes -
Resolution Completed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
David Nolen made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

Vote (3)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: