How to package Closure libraries? about packages HOT 15 CLOSED

Eric, in the OL3 forum, pointed to Google Closure features for matching namespaces to files. I guess that's the familiar top level script when you build without optimisations.

Namespaces (defined with good.provide) and file names are independent. You can even have files that goog.provide multiple namespaces. And you to have some script to create addDependency statements defining the dependencies tree and the matching between provided namespaces and files. This is what Closure Library's depswriter.py script does.

I guess that could provide the necessary mapping but that's speculation. I'm sure David or one of the other compiler devs will be able to give some concrete advice.

from packages.

Ok. Pretty sure we can package this stuff as native Closure libs. I'll see if I can pull together an example.

from packages.

@olivergeorge for Closure libraries that follow Java classpath naming conventions wrt. to their name there's nothing to do. For Closure libraries that do not there is the :libs features. I haven't used it so it needs to be verified that it hasn't regressed.

from packages.

So that was actually pretty straightforward. I put it together for openlayers in a native-closure branch.

I don't want to merge/deploy that yet though. I'd like to keep things as consistent as possible for end users. Sprinkling this repo and the cljsjs group on clojars with jars that work differently than existing ones is most likely going to lead to confusion.

Suggestion: move Closure libs into another repo (closure-libs) and create a new group on Clojars (cljsjs-closure). Any opinions on that?

from packages.

Oh just in case that's not clear: packaging things like OpenLayers with :libs allows it to be used just like regular Closure libs/Clojurescript namespaces. This allows us to selectively pull in what's needed and enables the full suite of Closure optimization features like dead code elimination.

(ns my.app
  (:require [ol.animation :as anim])
  (:import ol.Map ol.source.MapQuest))

from packages.

Great stuff!
So is it the ClojureScript compiler that does all the goog.provide -> filename conversion?

move Closure libs into another repo (closure-libs)

I do think it would be sufficient to specify this is a closure library in the readme. Not sure creating an extra repo is worth it.

from packages.

I also like the idea of splitting things up for the sake of discoverability but we can leave that for another day.

from packages.

Looks to have worked like a charm. My example file size is sane and it's working.

from packages.

What's the next step on this? I'll use it in a current project so it would be nice if it was uploaded to clojars.

from packages.

@olivergeorge Uploading 3.1.1-1 right now. If you'd like to get 3.2 please update it via PR.

@olivergeorge @jeluard if anyone of you guys feels like helping with maintaining this I'm happy to add you as contributors. I'm planning to write up some CONTRIBUTING.md to make this easy peasy 🌞

from packages.

I'd be pleased to be a contributor and help out. I think I'll be doing
plenty of cljs work this year.

On 10 February 2015 at 21:26, Martin Klepsch [email protected]
wrote:

@olivergeorge https://github.com/olivergeorge Uploading 3.1.1-1 right
now. If you'd like to get 3.2 please update it via PR.

@olivergeorge https://github.com/olivergeorge @jeluard
https://github.com/jeluard if anyone of you guys feels like helping
with maintaining this I'm happy to add you as contributors. I'm planning to
write up some CONTRIBUTING.md to make this easy peasy [image:
🌞]

—
Reply to this email directly or view it on GitHub
#28 (comment).

from packages.

@olivergeorge added you to the @cljsjs/contributors group :)
I'm closing this now as the Closure question as been answered :)

from packages.

@martinklepsch Do you mind adding me as a contributor? I'd like to add some details to the README.

from packages.

@jeluard done/

from packages.

Thanks!

from packages.