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

@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

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

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?

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

or sift it out

that's what i would try first, anyway

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

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

sounds maybe like a case for parallel pipelines

but i haven't done that myself yet in anger

are there any docs for that?

ah

I see there's runboot there

what I meant by a separate Boot Core

i think maybe the boot tests that were added

i think they're run like that

thanks! will try that

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

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

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

probably that's saner than what I did 🙂

works though

idiomatic = works

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

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

@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

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

@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

🙂

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

Boot's normal behaviour is a pipeline right?

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

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 🙂

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

so well...dunno 😄

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