Hi Tim,

It's interesting you're thinking about browser-connected repls. Today I 
added clojurescript support to Jig, it's pushed to master but I haven't 
documented the config options yet, but below is an example. Nothing fancy 
like crossovers yet, it's basically a thin wrapper over ClojureScript's 
compiler, the config options map directly to the options given to the 
compiler.

  :cljs-builder
  {:jig/component jig.cljs/Builder
   :jig/project "../my-proj/project.clj"
   :source-path "../my-proj/src-cljs"
   :output-dir "../my-proj/target/js"
   :output-to "../my-proj/target/js/main.js"
   :source-map "../my-proj/target/js/main.js.map"
   :optimizations :simple
   :pretty-print true
;;   :clean-build true
   }

Another built-in component can figure out, given the dependencies, what 
files to serve and on which server to serve it from.

  :cljs-server
  {:jig/component jig.cljs/FileServer
   :jig/dependencies [:cljs-builder :web]
   :jig.web/context "/js"
   }

which depends on some Ring or Pedestal routing and Jetty or other 
webserver, but you're likely to have that configured already :-

  :server
  {:jig/component jig.web.server/Component
   :io.pedestal.service.http/port 8000
   :io.pedestal.service.http/type :jetty
   }

  :web
  {:jig/component jig.web.app/Component
   :jig/dependencies [:server]
   :jig/scheme :http
   :jig/hostname "localhost"
   :jig.web/server :server
   }

That's it really. I think Jig makes an ideal platform for building and 
serving clojurescript, in comparison to Leiningen plugins. Firstly, there's 
no JVM start-up cost, the point of Jig is to keep the JVM running all the 
time, so there's no need for the once/auto service that lein-cljsbuild 
offers. Secondly, serving the resulting Javascript files is straight 
forward, and built in, so no 'lein ring server' requirement either.. With 
Leiningen, you either have to build routes to the javascript into your own 
app, or run lein ring server, but then Leiningen doesn't make it easy to 
run multiple services concurrently. Thirdly, there's no file-system 
polling, and services that depend on the clojurescript compilation can be 
started as soon as the compilation is complete.

One thing that lein-cljsbuild does really well is multiple build configs. 
I've decided to use a single build configuration, to keep implementation 
easier and a direct mapping to the clojurescript compiler, but of course 
you can add different builds by just adding (differently configured) 
components to the Jig config. This would benefit from being able to 
initialize and start components in parallel, where possible. Unlike 
cljsbuild, Jig components are started serially, in reverse dependency 
order. Does anyone know of existing algorithms that can walk a dependency 
tree in parallel?

Feel free to take Jig in different directions though, I'm just letting you 
know my current thoughts. The single REPL to multiple projects idea might 
have to be rethought - it seems the prevailing wind is in the direction of 
multiple REPL connections per editor/IDE.

On Thursday, 7 November 2013 01:09:53 UTC, frye wrote:
>
> Too right. 
>
> Yes, wrt the multi-project / classpath thing, running isolated test for a 
> particular project is only one aspect. I also have an eye to running a i) 
> browser-connected repl and ii) debugger for a particular project. So those 
> things, along with iii) running tests, make very high, the attractiveness 
> of having that isolation. 
>
> I'll try to put those in github issues. And also pick at the problem 
> myself when I get some cycles. I think it would add a powerful feature to 
> the tool. Anyways... :) 
>
>
> Tim Washington 
> Interruptsoftware.ca <http://interruptsoftware.ca/> / 
> Bkeeping.com<http://bkeeping.com/>
>  
>
>
> On Tue, Nov 5, 2013 at 4:33 AM, Malcolm Sparks <mal...@juxt.pro<javascript:>
> > wrote:
>
>> Hi Tim,
>>
>> The tests in JUXT accounting are using clojure.core.test. I'm fairly sure 
>> Midje's :autotest feature does something dynamic to determine the tests to 
>> run and that may not work with Jig's classloading approach. For example, if 
>> something uses (System/getProperty "java.class.path") it will just get the 
>> Jig source directories because, for external projects, Jig must load these 
>> using a child class-loader. I need to spend some time with Midje to work 
>> out what it's doing.
>>
>> Having multiple lein projects loaded in the same JVM, and integrated with 
>> each other, is not a common Clojure mode of usage today. However, the 
>> Immutant team (and others) have done a lot of the groundwork and I think 
>> the various caveats I've listed on Jig's README.md about 'external 
>> projects' are going to be ironed out over time as these issues become 
>> better understood. I expect that Brian never saw this as a use-case.
>>
>> In the absence of a mailing list right now, please log any issues you see 
>> as GitHub issues and I'll do my best to fix them.
>>
>> Thanks again for sending in this really useful feedback.
>>
>> Regards,
>>
>> Malcolm
>>
>>
>>
>>
>> On Monday, 4 November 2013 02:53:47 UTC, frye wrote:
>>
>>> Ok, some more feedback for Jig. 
>>>
>>> *A)* Testing - Let's say I have a multi-project jig, with dependencies 
>>> across projects. There doesn't seem to be a way to run tests (midje 
>>> :autotest) for a specific project. I tried creating a Midje component (see 
>>> https://www.refheap.com/20442)**. But when I *i)* put this into 
>>> config.edn, and *ii)* thread through my local project component, *iii)*this 
>>> only prints out the classpath directories under the 
>>> *jig* project. I'll want to be in the Classpath context of the project 
>>> that's being passed in. That way, I can :autotest for that project. Or 
>>> perhaps there's another way to run and autorun tests for a particular 
>>> project. I noticed that 
>>> Juxt-Accounting<https://github.com/juxt/juxt-accounting>has a test suite. 
>>>
>>> *B)* Ok, so there's just that and removing the *config/console.edn* and 
>>> *config/default.edn* **files when writing your jig. 
>>>
>>> *C)* And a raw *git clone g...@github.com:juxt/jig.git*, then *lein repl*, 
>>> then * (go)*, doesn't give working URLs ( http://<>:8091/readme , 
>>> http://<>:8001/server, etc )
>>>
>>>
>>> Let me know if you want me to log these as bugs, feature requests, etc. 
>>> Very excited about the kind of leverage that this project can yield. 
>>>
>>>
>>> Loving this tool. Thanks. 
>>>
>>> Tim Washington 
>>> Interruptsoftware.ca <http://interruptsoftware.ca/> / 
>>> Bkeepin**g.com<http://bkeeping.com/>
>>>  
>>>
>>>
>>> On Sat, Nov 2, 2013 at 8:18 PM, Timothy Washington <twas...@gmail.com>wrote:
>>>
>>>> Ok, I actually got the compojure example working. I just had to remove 
>>>> the *config/console.edn* and *config/default.edn* files in my jig. 
>>>> They must be disrupting the config that I put in. So that's my only 
>>>> feedback so far. 
>>>>
>>>> Ok, this is looking really good. Great work :)  
>>>>
>>>> Tim Washington 
>>>> Interruptsoftware.ca <http://interruptsoftware.ca/> / 
>>>> Bkeepin**g.com<http://bkeeping.com/>
>>>>  
>>>>
>>>>
>>>>
>>>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to