Fork me on GitHub
#boot
<
2016-05-27
>
myguidingstar02:05:23

@martinklepsch: can you help explain the use of org.martinklepsch.boot-garden/processed atom and the var initial in boot-garden?

martinklepsch06:05:14

@myguidingstar: the task uses ns tracker to find changed namespaces - for the initial run this doesn't work so the task tracks if that information

martinklepsch06:05:51

@myguidingstar: If you can provide a repro I'm happy to take a look

dm309:05:12

what would be a good way to create and install/push several jars in one boot task? I'm deriving some nses from sources which have to appear in a jar with a different classifier. However, it seems that it has to be done in a different Boot Core as multiple invocations of pom task will clash, right?

alandipert12:05:16

@dm3: i think you can rm the pom in between invocations

alandipert12:05:43

or sift it out

alandipert12:05:00

that's what i would try first, anyway

dm312:05:34

hmm, that would work. I was thinking what would allow a truly composable solution for that

dm312:05:10

I'll also need to filter out all of the sources/resources except the generated ns file

alandipert12:05:35

sounds maybe like a case for parallel pipelines

alandipert12:05:39

but i haven't done that myself yet in anger

dm312:05:54

are there any docs for that?

dm312:05:34

I see there's runboot there

dm312:05:42

what I meant by a separate Boot Core

alandipert12:05:00

i think maybe the boot tests that were added

alandipert12:05:04

i think they're run like that

dm312:05:06

thanks! will try that

dm312:05:40

do you have any tasks that modify the build file itself (e.g. for release)?

alandipert12:05:53

no, altho i think if i did that i would keep my version in an separated edn/json

alandipert12:05:12

and edit it via separate process, like in jenkins or whatever

dm312:05:22

probably that's saner than what I did 🙂

dm312:05:44

works though parrot

alandipert12:05:57

idiomatic = works

alandipert12:05:24

lol i guess that's another weird case for boot-in-boot

alandipert12:05:33

a boot project that manages the version of an inner boot project that is the actual project

richiardiandrea14:05:45

@dm3 the only thing that prevents a fully boot-in-boot experience is that we should pass dependencies as a parameter from the caller of runboot . A simple change that I did not have time to implement but that would, for instance, enable fully parallel isolated tasks

richiardiandrea14:05:33

And I read your use case, and it would probably work if you use boot.parallel

dm315:05:22

@richiardiandrea: yeah, it seems the way to go if you need a separate pipeline. Hmm, now wondering if boot.parallel should really be boot.pipeline

richiardiandrea15:05:12

Imho no because what it does is basically to make a task run in parallel instead of serially

richiardiandrea15:05:37

Boot's normal behaviour is a pipeline right?

richiardiandrea15:05:03

But ok I haven't brainstormed the name too much so I might be wrong :))

dm315:05:14

I think the defining feature here is the ability to run multiple pipelines on segregated filesets/environments. If they're sequential or parallel doesn't matter as much - but I might be wrong too 🙂

richiardiandrea15:05:32

yeah in a way once you "fork" your execution to be in parallel, then the pipeline is executed sequentially again for all the "parallelized"-tasks

richiardiandrea15:05:39

so well...dunno 😄

richiardiandrea15:05:18

if you use it, please report bugs, boot.test is completely build on boot.parallel but there might be sharp edges