Henrik, can you make a github repo with what you were trying to do in your
second question? It would help to be able to see your whole setup.
The add-src task is perhaps confusingly named (Names Are Hard). Its purpose
is to shuffle files around in the file set, moving files that would
normally be considered “source” files into the stream of artifacts that end
up being packaged. It’s roughly equivalent to setting Leiningen’s
:omit-source key to false (but it’s a composable task, not a global
setting).
I’ll try to explain how this works. To model all the filesystem side
effects that building software entails we must establish some types of
files, aligned along some basis of user intent. We ended up with two
categories: input and output files (again, Names Are Hard, so please bear
with me).
-
*input* – files that MUST be processed further before being packaged or
emitted to the project target directory (eg. Java source files, CLJS source
files, etc.)
-
*output* – files that MAY be processed further, but can be included in
the packaged artifact or emitted to the project target directory (eg.
compiled JavaScript, Java bytecode, etc.). Note that this also includes
files that might pass through the build system completely unmolested to end
up in the final result, like your index.html file for instance. These
are also called “resources” in Java parlance, I believe.
A major concept in boot has that the output of a task is always part of the
input of subsequent tasks. Tasks shouldn’t know or care what is to be done
to the artifacts they emit; they shouldn’t know or care who or what might
be further processing them. Thus, both input and output files are on the
classpath. This means that both types serve as input for tasks, which is, I
admit, somewhat confusing.
When you set up your environment in boot you use the :src-paths and
:rsc-paths arguments to set-env!. The :src-paths denote *input* dirs,
:rsc-paths *output* dirs.
This brings us to tempdirs. Tasks that emit files do so in anonymous temp
dirs they obtain from boot core. These temp dirs come in a few flavors, but
there are two main classes of temp dir a task may create: *input* or
*output*, naturally. The choice is left to the task writer, who decides
based on his intent. For example, the cljs-repl task emits a CLJS namespace
containing the websocket connection code the client needs to run to connect
to the REPL server. This namespace is emitted into an *input* type temp
dir. Thus the CLJS namespace is compiled into the application JS file, but
the CLJS source does not appear in the app webroot.
Finally, we arrive at add-src. This task creates a temp dir of the *output*
type. It then obtains a list of *input* type files from boot core and moves
them into this dir. Then when the jar task for example runs later in the
pipeline, these source files will be included in the jar.
I’m not sure how clear this is, I’m trying to figure out the best way to
explain this stuff and this is one of the first iterations :)
--
Micha Niskin
On Fri, Nov 7, 2014 at 6:46 AM, Henrik Eneroth <henrik.ener...@gmail.com>
wrote:
> Agreed, because it seems like a good tool. :-)
>
>
> On that vein; what's the syntax for add-src?
>
> I'm trying to include helper.cljs in the project, a file with a bunch of
> convenience functions that I use. However, I get the following error:
>
> << stopping Jetty... >> clojure.lang.ExceptionInfo:
> clojure.lang.ExceptionInfo: Could not locate helpers__init.class or
> helpers.clj on classpath: at line 1 {:tag :cljs/analysis-error, :file
> nil, :line 1, :column 1}
>
> It seems enamoured with the idea that the file should end with ".clj". I'm
> guessing that boot has to be told of the existence of the file, but I'm not
> sure how to do this. For the purposes of this experiment, the namespace of
> helpers.cljs is simply (ns helpers).
>
>
> On Friday, November 7, 2014 12:01:14 PM UTC+1, Laurent PETIT wrote:
>>
>> Really looking forward to a couple more blog posts:
>>
>> - an instructive / provocative one which could be named after "how to
>> replace leiningen with boot 2". Would be very practical, showing how all
>> major usecases done with lein translate to boot.
>> - an tutorial / documenting one on how to write new task and be good
>> citizens of boot (what to do, what not to do, and then how)
>>
>> :-)
>>
>>
>> 2014-11-07 10:16 GMT+01:00 Henrik Eneroth <henrik....@gmail.com>:
>>
>>> I tried now, just running boot -u, and it worked perfectly. It's was
>>> probably some caching thing with Clojars. Currently at pre21
>>>
>>> Now the command runs without errors, but it also doesn't seem to do all
>>> that much.
>>>
>>> Running
>>> > boot -d reagent/reagent:0.4.3
>>> gives the exact same output as running
>>> > boot -h
>>> currently.
>>>
>>>
>>>
>>> On Friday, November 7, 2014 12:18:41 AM UTC+1, Micha Niskin wrote:
>>>>
>>>> It looks like Clojars is doing what I thought it would do:
>>>> https://clojars.org/repo/boot/boot/maven-metadata.xml
>>>>
>>>> <release>2.0.0-pre20</release>
>>>>
>>>> On Thursday, November 6, 2014 5:50:14 PM UTC-5, Henrik Eneroth wrote:
>>>>
>>>> Thanks for looking into it, Micha!
>>>>>
>>>>>
>>>>> I'm getting -pre19 with boot -u, though. Did you forget to cut a
>>>>> release or should I set BOOT_CHANNEL to dev?
>>>>>
>>>>>
>>>>> On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>>>>>>
>>>>>> Hi Henrik,
>>>>>>
>>>>>> You found a bug! We just fixed it though. Boot was confused by
>>>>>> `reagent/reagent` when it tried to match that against the artifact ids
>>>>>> returned by Pomegranate, because Pomegranate collapses it to just
>>>>>> `reagent`
>>>>>> in that case. If you do `boot -u` you should be updated to boot version
>>>>>> `2.0.0-pre20`, and your command line will work.
>>>>>>
>>>>>> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>>>>>>>
>>>>>>> Hello Micha!
>>>>>>>
>>>>>>>
>>>>>>> I'm trying to tuck Reagent in there to take it for a spin, and it
>>>>>>> seems reluctant to comply:
>>>>>>>
>>>>>>> boot -d reagent/reagent:0.4.3
>>>>>>> java.lang.NullPointerException:
>>>>>>> boot.main/dep-ns-decls main.clj: 36
>>>>>>> boot.main/export-task-namespaces/fn main.clj: 49
>>>>>>> clojure.core/map/fn core.clj: 2557
>>>>>>> ...
>>>>>>> clojure.core/seq core.clj: 133
>>>>>>> clojure.core/apply core.clj: 624
>>>>>>> clojure.core/mapcat core.clj: 2586
>>>>>>> ...
>>>>>>> boot.main/export-task-namespaces main.clj: 51
>>>>>>> boot.main/-main main.clj: 111
>>>>>>> ...
>>>>>>> boot.App.runBoot App.java: 217
>>>>>>> boot.App.main App.java: 309
>>>>>>>
>>>>>>>
>>>>>>> Any feedback on what I (or it) may be doing wrong?
>>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Henrik
>>>>>>>
>>>>>>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:
>>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> Boot (http://github.com/boot-clj/boot) is a build tool for
>>>>>>>> Clojure. We've pulled together lessons learned from a year or so using
>>>>>>>> boot
>>>>>>>> v1 in production and are now getting ready to release v2. To show what
>>>>>>>> boot
>>>>>>>> can do we present a very streamlined and awesome boot-based
>>>>>>>> ClojureScript
>>>>>>>> development workflow (http://adzerk.com/blog/2014/1
>>>>>>>> 1/clojurescript-builds-rebooted/).
>>>>>>>>
>>>>>>>> Try it out, maybe you'll like it! We're hoping to get some feedback
>>>>>>>> before committing to a stable release, so please if you have any
>>>>>>>> comments
>>>>>>>> or questions we'd be happy to hear them. Have fun!
>>>>>>>>
>>>>>>>
>>>>
>>> --
>>> 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
>>> 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
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Laurent Petit
>>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/YAckwMSfZkY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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/d/optout.
