Fork me on GitHub
#boot
<
2016-12-14
>
domkm00:12:43

It looks like time inside a task doesn't output anything. How do you benchmark tasks?

martinklepsch06:12:09

(with-pass-thru _
    (time (Thread/sleep 1)))
@domkm this works for me

martinklepsch07:12:13

@domkm what in particular would you like to benchmark?

domkm07:12:17

@martinklepsch how much time is spent in each subtask or inside a macro that is called by a task. I'll try your code tomorrow. Thanks :)

abstruselyarcane08:12:36

Hi, I don't know why, but when boot-reload tries to reload stuff, it doesn't use the right path?

abstruselyarcane08:12:48

It's supposed to load from project-dir/target/main.out/stuff

abstruselyarcane08:12:58

But it loads from project-dir/main.out/stuff?

pesterhazy09:12:35

@martinklepsch by the way, why do you see sometimes (with-pass-thru _ ...) and sometimes (with-pass-through [_] ...)?

pesterhazy09:12:01

@abstruselyarcane it shouldn't read from target though

pesterhazy09:12:17

that's not how it's supposed to work

martinklepsch09:12:40

the binding form [_] vs _ is a legacy thing. Why there are two names for the same thing I don't know 😄

abstruselyarcane09:12:47

I'm using electron, and cljs is compiled with asset-path pointing to target/main.out

pesterhazy09:12:05

so _ is preferred?

pesterhazy09:12:24

@abstruselyarcane normally boot-reload reads from the resources and doesn't need to be made permanent in target/

pesterhazy09:12:45

not sure if electron makes things different

abstruselyarcane09:12:06

hmm, but I want it to reload the new js

abstruselyarcane09:12:19

and compiled js lives in target

martinklepsch09:12:32

The electron stuff is a bit different but really the main stuff shouldn't get reloaded @abstruselyarcane

abstruselyarcane09:12:32

wait, why would you be reading from resources?

abstruselyarcane09:12:52

Hmm, can you take a look at the electron-and-cljs project I just pasted and see why that works?

abstruselyarcane09:12:05

My boot file is pretty much the same with minor modifications

abstruselyarcane09:12:54

But the whole point of using reload is to reload the new js when there's new js

abstruselyarcane09:12:08

Or am I misunderstanding the whole buildchain entirely?

martinklepsch09:12:52

@abstruselyarcane in Electron theres a main process and the renderer

martinklepsch09:12:07

The renderer stuff gets reloaded the main stuff requires an electron restart.

abstruselyarcane09:12:29

Yeah, but the renderer, when reloading, reads from the wrong place

martinklepsch09:12:33

Can you paste a diff of your modifications? (if you create a snippet you can choose "Diff" for proper highlighting)

abstruselyarcane09:12:12

The only modifications I made are add a set nrepl port and devtools preload to the renderer

martinklepsch09:12:22

I just cloned the repo and it's all working as it should.

abstruselyarcane09:12:43

It's working on my machine too, I don't know why the exact same thing isn't working for this project

martinklepsch09:12:11

did you read the readme? It's important that you start electron like this electron target/

abstruselyarcane09:12:26

Yeah, I'm starting electron correctly

martinklepsch09:12:28

(i.e. don't omit the trailing slash)

abstruselyarcane09:12:34

Everything works except for reload

martinklepsch09:12:50

@abstruselyarcane if you can put your project up somewhere I can take a quick look

abstruselyarcane09:12:55

Wait, I'll push the latest version up

abstruselyarcane09:12:50

Hmm, adding :asset-path "target/main.out" to reload doesn't change anything

martinklepsch09:12:22

@abstruselyarcane try adding a boot.properties file

martinklepsch09:12:30

boot -V > boot.properties

martinklepsch09:12:42

and then make sure you use at least Clojure 1.8.0 and Boot 2.6.0

abstruselyarcane09:12:02

Hmm, I'm on boot 2.7

abstruselyarcane09:12:25

There shouldn't be any differences between those 2, as far as reload is concerend, right?

martinklepsch09:12:52

Shouldn't but 2.7 is relatively new so wouldn't hurt to try 2.6 just to be safe

martinklepsch09:12:06

Also are you 100% you don't have any uncommitted changes in your repo?

abstruselyarcane09:12:13

Wait, is there a global boot.properties somewhere that overrides everything eles?

martinklepsch09:12:36

project specific ones have highest priority

abstruselyarcane09:12:06

I just changed it properties to 2.6 but -V still reports 2.7

abstruselyarcane09:12:46

I found it, it's at ~/.boot/boot.properties

abstruselyarcane09:12:21

Are you kidding me? the local version is mispelled

martinklepsch09:12:43

local version?

abstruselyarcane09:12:04

Local to the project

martinklepsch09:12:59

That doesn't make it any clearer to me, sorry 😄

abstruselyarcane09:12:34

There's the global prop file at ~/.boot/boot.properties and the local at prj-dir/boot.properties

abstruselyarcane09:12:47

There was a typo in the local one

abstruselyarcane09:12:54

And yes, it seems like migrating to 2.6 fixed it

abstruselyarcane09:12:06

Lemme look thru the changelog for 2.7

abstruselyarcane09:12:06

Hmm, don't see anything that should change this behaviour in the changelog

abstruselyarcane09:12:21

I don't want to be stuck on 2.6 forever...

martinklepsch09:12:14

2.7 is out for less than 2 days, I think there will be a solution 😉

abstruselyarcane09:12:39

Should I file this under boot or reload?

abstruselyarcane09:12:55

It looks like it's reload's fault

martinklepsch09:12:44

@abstruselyarcane I'd also suggest filing under boot-reload

martinklepsch09:12:59

I can reproduce the issue with 2.7.0 btw

abstruselyarcane09:12:08

Good, it's not just my machine

abstruselyarcane09:12:17

Ty, I'll open an issue on reload

abstruselyarcane09:12:21

What's the difference between reload and figwheel?

martinklepsch09:12:42

@abstruselyarcane I also just reproduced with this repo which might be a more minimal case to provide in the issue: https://github.com/martinklepsch/electron-and-clojurescript

abstruselyarcane09:12:32

I also reproduced this with the electron-and-clojurescript

abstruselyarcane09:12:41

Oh, didn't know the bot reports on new issues

piotrek10:12:55

Hi, I noticed an issue with Clojure version after upgrading to 2.7.0

piotrek11:12:13

I had following boot.properties in my project dir:

BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.9.0-alpha14
BOOT_VERSION=2.6.0
and it was working well

piotrek11:12:52

After changing BOOT_VERSION to 2.7.0 now I am getting following warning: Classpath conflict: org.clojure/clojure version 1.8.0 already loaded, NOT loading version 1.9.0-alpha14 and 1.8.0 is used for my project

piotrek11:12:00

Any hints how to troubleshoot this issue?

abstruselyarcane11:12:08

What does -V say?

abstruselyarcane11:12:53

@piotrek what is the output for boot -V?

piotrek11:12:02

Hmm, that’s strange - with boot 2.6.0 I get clojure 1.8.0 too but without warning

piotrek11:12:20

boot -V (with 2.6.0):

BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.6.0

piotrek11:12:30

boot -V (with 2.7.0):

BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.0

piotrek11:12:02

So how can I change clojure version to 1.9.0-alpha14 (property from boot.properties doesn’t work apparently)

abstruselyarcane11:12:22

Hmm, if you change in the prop file -V still shows 1.8?

tcrawley11:12:34

https://github.com/boot-clj/boot/commit/9a66940c9d7afb6c1760e7c373476fbd4e24ddf3 introduced that warning message, and has two issues mentioned in the commit that may provide more context

tcrawley11:12:20

I have no knowledge of the issue, was just curious

abstruselyarcane11:12:42

@piotrek I think you can set the version thru environment variables; try looking at the docs

piotrek11:12:21

@abstruselyarcane env var works fine - but boot.properties doesn’t...

piotrek11:12:16

picard-facepalm I had env var set by my rc scripts...

piotrek11:12:30

and it was setting clojure version to 1.8.0

alandipert13:12:45

@piotrek it's just a new warning for an existing situation

alandipert13:12:10

It means that one of your dependencies wanted to bring in 1.9

alandipert13:12:41

Which could cause a problem if that dependency uses a feature of 1.9

alandipert13:12:39

You can figure out which dependency with boot show -p, and eliminate the warning with an exclusion

piotrek13:12:00

@alandipert It was a direct dep of my project

piotrek13:12:33

How could I configure hoplon and boot-cljs tasks to generate html/js files under a specific directory under target? I would like to server that sub-directory via http server in my clojure app in the same project and I don’t want to server everything from my classpath but only a specific dir

piotrek13:12:55

Is using a custom cljs build ID the proper solution?

micha13:12:11

@piotrek in hoplon you can just do something like (page "public/index.html" ...

piotrek13:12:53

oh, so hoplon task uses that for generating cljs.edn file for cljs task?

micha13:12:13

you can also just make a middleware that allows access only to HTML js, css, and images

piotrek13:12:02

OK, good, it works, but...

piotrek13:12:39

Whenever I save the hoplon page (with (page “public/index.html”)) and that page is reloaded in my browser, I can see an error in the console:

piotrek13:12:56

GET  
(anonymous) @ core.cljs:113
hoplon$core$merge_kids @ core.cljs:112
G__9737__2 @ core.cljs:4120
G__9737 @ core.cljs:4122
(anonymous) @ core.cljs:48
cljs.core.Atom.cljs$core$IWatchable$_notify_watches$arity$3 @ core.cljs:4246
cljs$core$_notify_watches @ core.cljs:675
cljs$core$reset_BANG_ @ core.cljs:4287
cljs.core.swap_BANG_.cljs$core$IFn$_invoke$arity$4 @ core.cljs:4306
cljs$core$swap_BANG_ @ core.cljs:4291
hoplon.core.set_appendChild_BANG_.this$.appendChild @ core.cljs:144
goog.net.jsloader.load @ jsloader.js:214
popAndLoadNextScript @ jsloader.js:133
goog.net.jsloader.loadMany @ jsloader.js:139
adzerk$boot_reload$reload$reload_js @ reload.cljs:47
adzerk$boot_reload$reload$reload @ reload.cljs:80
(anonymous) @ client.cljs:37
G__11572__3 @ core.cljs:10037
G__11572 @ core.cljs:10146
(anonymous) @ client.cljs:59
goog.events.EventTarget.fireListeners @ eventtarget.js:284
goog.events.EventTarget.dispatchEventInternal_ @ eventtarget.js:381
goog.events.EventTarget.dispatchEvent @ eventtarget.js:196
goog.net.WebSocket.onMessage_ @ websocket.js:426
reload.cljs:54 Load failed: Jsloader error (code #0): Error while loading script 

piotrek13:12:19

The content on the page is refreshing but I can see those errors on every save

piotrek13:12:04

My task def is following:

(deftask
  dev-repl
  "Dynamic dev repl"
  []
  (comp
    (repl :server true)
    (watch :verbose true)
    (notify)
    (hoplon)
    (reload :on-jsload 'page.index/reload)
    (cljs :compiler-options {:parallel-build true})
    (refresh)))

piotrek13:12:44

I run it, I connect to the repl server and start my app serving resources from “public” directory on classpath

micha14:12:07

@piotrek you will need to configure various other tasks to know about the public directory

micha14:12:38

that's why i myself prefer to make middlewre that just doesn't serve sensitive things

micha14:12:06

then all the tasks and tools can use the classpath naturally

micha14:12:13

and figure out how to configure themselves

piotrek14:12:20

I will try that

micha14:12:57

with hoplon especially there is not really a need to package the frontend in the same jar as the backend

micha14:12:07

since the frontend is completely static html/js/css/images

micha14:12:13

we just put them in a CDN

micha14:12:25

the only time we serve them from jetty is in dev

micha14:12:42

in which case we don't care about it serving other files because we already have them on the disk 🙂

piotrek14:12:09

But I would love the correct order of the following tasks: - repl - samestep/boot-refresh - watch - notify - hoplon - boot-reload - boot-cljs-repl - boot-cljs

micha14:12:33

looks good to me

micha14:12:43

not sure about boot-refresh

micha14:12:35

looks like you want to put that after watch

piotrek14:12:52

Well, I haven’t put them in the order I use them, let me paste my task 🙂

micha14:12:25

looks good to me

piotrek14:12:01

Getting the correct order is tricky 🙂

piotrek14:12:04

Looks like that “public” thing was causing the issue

piotrek14:12:30

I guess I would need to configure other tasks to handle it correctly or just use that middleware per your advise

micha14:12:00

how do you deploy your application?

micha14:12:07

like are you on AWS?

piotrek14:12:54

It’s very far from deploying 😉

piotrek14:12:07

So it’s only local development env now

micha14:12:31

in that case i wouldn't even worry about it

micha14:12:00

if you're going to be deploying your application to "the cloud" you won't want to serve the html and js and stuff from a jetty server anyway

micha14:12:15

you'll serve them from s3 via cloudfront or something like that

piotrek14:12:15

It will be rather small so I would like to keep it simple - so probably just a small jetty server with both backend and frontend

micha14:12:51

deploying to s3 is just a boot task really

micha15:12:02

i was about to link that too 🙂

piotrek15:12:21

I will check it out

piotrek15:12:49

For now thanks to @micha’s advice I was able to use :hoplon/page “public/index.html” along with ring resource middleware (with root set to “public”) and boot-reload task with :asset-path set to “public” - the warning is gone

mf15:12:52

Hi all, If I declare a dependency in my build.boot on org.clojure/clojure "1.8.0" and then also include a couple of 3rd party Jars that have a dependency on an older version of org.clojure/clojure, then I will have a dependency conflict (as beautifully displayed with boot show -p). If I include :exclusions ['org.clojure/clojure] in my build.boot then my understanding is that the version of org.clojure/clojure included with each of the 3rd party Jars will be excluded. My question is will the 3rd party Jars therefore use the version of org.clojure/clojure I have specified (1.8.0)?

alandipert15:12:57

@mf the answer is: yes

alandipert15:12:39

even without the exclusions, if you have a direct clojure dependency, it 'wins'

alandipert15:12:12

the difference is that you'll see some warnings. since it's frequently helpful to know that libraries you depend on expect a different version of clj, and so might behave differently or break when they run against the version of clj you specified

mf15:12:15

@alandipert that makes sense, thanks!

alandipert15:12:55

oh, the other related concept is the version of clj specified in boot.properties

alandipert15:12:07

that's what actually determines the version of clj that boot uses

alandipert15:12:33

which may or may not be relevant to your project... it depends on whether or not boot is the entrypoint to your application

alandipert15:12:50

but it will determine the version of clj that tasks use when you're in the 'build phase'

alandipert15:12:49

does that make any sense? i very probably need to improve how i describe that hehe

mf15:12:57

@alandipert Yes boot is the entry point for my project. So if I understand correctly the version of clj specified in boot.properties will supersede the version I specify in the build.boot file?

alandipert15:12:02

that's correct

mf15:12:02

but this is only the case if the entry point for the project is boot?

alandipert15:12:25

correct. the other situation is, you use boot to produce a jar

alandipert15:12:35

which runs in a non-boot environment like tomcat

alandipert15:12:16

tomcat doesn't have boot.properties or maven stuff, it just knows about the classes in your jar

mf15:12:28

that makes sense

alandipert15:12:35

and if you didn't specify a clojure dependency in your build.boot, it wasn't packaged in the jar, and so tomcat probably explodes

mf15:12:44

gottcha

mf15:12:02

Thanks heaps for the clarification, really helps!

alandipert15:12:35

and here's a trick to never really worry about it, and always just use whats in boot.properties or the boot default: (set-env! :dependencies [['org.clojure/clojure (clojure-version)]])

mf15:12:52

oh, that's nice

mf15:12:35

it removes the uncertainty about which version would win (boot.properties vs build.boot).

mf15:12:45

good to know

alandipert15:12:58

yeah. probably bad to do unless you have a project-local boot.properties, but that's always good to do

mf15:12:10

good point

mf15:12:20

I do have one in this project

dominicm15:12:57

Is there a lein-licenses for boot? Quick google didn't turn it up

micha16:12:34

looks like something that could be added to boot show perhaps

mf16:12:16

@alandipert Slightly more general dependency question if I may: If two 3rd party dependencies use different versions of a lib e.g. org.clojure/core.match and my boot project doesn't have an explicit dependency on org.clojure/core.match. Will each of the 3rd party Jars get their specified version of the lib?

alandipert16:12:43

@mf nope... 1 will win, and which one is nondeterministic

alandipert16:12:59

so you have 2 options in this situation, which is the worst one you can be in

alandipert16:12:10

the worst case is, neither is compatible with the other's dependency

alandipert16:12:14

in that case it's impossible to solve

alandipert16:12:21

and you need to send a PR to one of the projects

alandipert16:12:32

pods can be used, if boot is your entrypoint

alandipert16:12:38

pods let you run a set of dependencies in isolation

alandipert16:12:54

so then, you can use multiple dependencies, as long as they're used in different pods

mf17:12:23

Ok, yes havn't used Pods yet

mf17:12:38

have done some reading/listening to you talk about them though 🙂

mf17:12:20

So would you say it's pretty common for people to recognise a dependency conflict between Jars, and preemptively combat potential incompatibilities by using Pods?

alandipert17:12:52

i would say in most cases, i figure out how not to cause the problem

alandipert17:12:00

then next, i see if i can send a PR to one of the offending projects to fix it there

alandipert17:12:10

then pods, if i'm in a hurry or those didn't work

mf17:12:01

can you expand on: "figure out how not to cause the problem"

mf17:12:17

just so I'm on the same page

mf17:12:02

Take my example of core.match. Jar A may be dependent on a specific feature available in the latest version

mf17:12:27

but Jar B is dependent on an earlier version without the feature

mf17:12:44

given the non-deterministic nature of the conflict resolution

alandipert17:12:51

oh yeah, it's kind of a non-answer

mf17:12:59

either version could be used (if I understand)

alandipert17:12:59

but i meant like... figure out how to do what i want without using either A or B

mf17:12:08

oh right got you

alandipert17:12:40

the next step after that tho is to choose explicitly, by setting as a local dep, a version of core.match that satisfies both deps

alandipert17:12:52

pods come in when there isn't a version that works for both

mf17:12:00

gottcha

mf17:12:40

Do you have any OS projects in mind that you could point me to, that use Pods for handling this?

alandipert17:12:28

@mf i don't actually. i was in the predicament once, using a lib that dependened on AWS sdk, when i also depended on different version of AWS Sdk

alandipert17:12:37

it was an sqs veneer in clj

alandipert17:12:56

to fix i just called sqs apis directly instead of using the wrapper lib that brought in the problematic dep

alandipert17:12:09

i don't think there are any examples because this is something that happens in applications usually, not libraries

alandipert17:12:16

but you can learn the mechanics of pods from libraries that use them

mf17:12:30

@alandipert thanks for the info

mf17:12:47

helps me understand the usecases

mf17:12:47

@alandipert is there any way to declare that my app depends on a version of a lib greater than a specific version? e.g. > 0.8

micha18:12:56

@mf that's frowned upon in the maven world

micha18:12:00

but you can do it

mf18:12:43

I was thinking that it was useful from a Library builder perspective

mf18:12:01

i.e. to say that my Jar needs a version greater than x

micha18:12:20

yeah i don't think you want to do that

alandipert18:12:29

I can see it making more sense if you own the dependency and have a really amazing memory or something

micha18:12:33

it makes builds nondeterministic

mf18:12:43

you are right

micha18:12:53

also version ranges make rsolution veeeery slow

micha18:12:59

resolution

micha18:12:09

maven needs to go out and get info about all versions that exist

micha18:12:13

then drill down and pick one

micha18:12:21

that means downloading lots of pom.xml files

micha18:12:23

and so on

mf18:12:42

I was thinking similar to how bundler allows dependencies to be declared in Ruby

mf18:12:01

but I get your point about the build being non-deterministic

micha18:12:37

but it's definitely frowned upon to put a pom in a maven repo that has version ranges

micha18:12:55

nobody will care what you do with your own application though 🙂

mf18:12:12

Yeah I'm more interested in learning what the best practices are with regards dependencies

mf18:12:22

so your info if greatly appreciated

micha18:12:32

that's one really nice thing about maven vs. what i've experienced with ruby and npm etc

micha18:12:56

the dependency tree is basically a pure function

micha18:12:20

like if you resolve your dependencies today and you get some tree of dependency versions

micha18:12:38

you can resolve those same dependencies a year from now and get exactly the same tree back

mf18:12:42

yeah I like the sound of that

micha18:12:59

so if your thing builds and runs today it will build and run tomorrow without fail

micha18:12:07

or 10 years from now

mf18:12:31

sounds abit like the approach with https://nixos.org/nix/

mf18:12:39

although for system packages

micha18:12:41

also artifacts in maven repos are immutable

micha18:12:50

you can't change them once you upload them

micha18:12:53

or delete them

micha18:12:25

there are cases of course where an artifact needs to be deleted, like for legal reasons (intellectual property, etc)

micha18:12:32

but it's exceedingly rare

micha18:12:12

so if your program works with some library of version X today, it will get the same artifact when it resolves version X next year or 10 years from now

mf18:12:43

yeah sounds very nice

micha18:12:01

also because of this you don't need version ranges so much

micha18:12:09

because if your program works it works

mf18:12:11

you have sold me on the evils of the range approach 🙂

micha18:12:20

and you don't need to chase the latest version of everything

mf18:12:39

removes alot of complexity really

micha18:12:00

yeah i think they did a great job engineering the maven repository system

micha18:12:46

i haven't had any dependency hell situations in a long time

mf18:12:58

that's a nice situation to be in

micha18:12:07

pods + maven solves everything for me now

mf18:12:19

Yeah I have to wet my feet with Pods

mf18:12:41

Thanks @alandipert @micha for the excellent info

micha18:12:49

most of the dependency hell situations arise from build-time dependencies conflicting with project dependencies

micha18:12:57

that's where pods come in

mf18:12:09

yeah I follow

mf18:12:40

will look to give them a go

micha18:12:48

maven is a joy compared to the other things i work with

mf18:12:20

Thats nice to hear, To be honest I was seeing Maven as Java eco-system component to be afraid of

micha18:12:40

the best part of it is that it doesn't try to be clever

micha18:12:55

when there is a dependency conflict it chooses the simplest resolution strategy

micha18:12:14

which is to just pick the one that has the shortest number of transitive "hops"

richiardiandrea18:12:21

I wonder why maven is so slow compared to boot...really...isn't dep resolution the same (both using aether)?

micha18:12:39

@richiardiandrea boot aggressively caches aether results

micha18:12:52

because resolution is immutable

richiardiandrea18:12:00

oh ok that makes total sense

micha18:12:03

so most of the time boot doesn't actually need to call out to aether

richiardiandrea18:12:35

you know I am pondering whether I can actually write a aether server using boot

richiardiandrea18:12:24

it would be useful also for builds that are faster to startup, like cljs builds, but still need to resolve dependencies

micha18:12:38

you can preresolve dependencies

micha18:12:43

write them to a file

richiardiandrea18:12:50

yep I actually do this all the time

micha18:12:51

that's in 2.7.0 now

richiardiandrea18:12:00

using boot-cp before

micha18:12:08

yeah the with-cp stuff is in 2.7.0

richiardiandrea18:12:58

there is a tool called calvin-cljs for node.js builds that has a very interesting approach, all javascript 😉 https://libraries.io/npm/calvin-cljs

richiardiandrea18:12:31

I tried it, but dep resolution is not actually faster

richiardiandrea18:12:50

so I was wondering whether a server with aggressive caching would be beneficial

micha18:12:10

does plexus do that?

richiardiandrea18:12:37

uhm, maybe, not very familiar with that, I will explore the option 😉

micha18:12:17

boot doesn't ever expire the aether cache btw

micha18:12:23

it's done via memoization

micha18:12:43

it's assumed that you don't care about new versions of things that appear while boot is running

micha18:12:19

like if you have a boot repl and you resolve some deps, it'll cache that so you would not "see" a new version that is pushed to maven

micha18:12:27

until you restart boot

richiardiandrea18:12:54

oh got it, that's good to know

richiardiandrea18:12:16

not that it matters during dev time I guess actually, so the choice seems sound to me..

richiardiandrea18:12:33

so ok the proxy server is Nexus 🙂

richiardiandrea18:12:56

as many Java things it looks blooooated ah ah

micha18:12:11

naturally

richiardiandrea18:12:07

so there is a redeploy, but needs to be explicitly enabled it seems

micha18:12:39

neither maven central or clojars supports such things

micha18:12:42

as far as i know

micha18:12:53

of course if you own the repository you can do whatever you want

micha18:12:07

that's why your local .m2 can be mutated

micha18:12:49

i wonder why the repository isn't part of the dependency coordinates

micha18:12:20

they must have a reason, but it seems to cause a lot of issues

micha18:12:04

the _maven.repositories file

micha18:12:09

that can get weird

richiardiandrea18:12:09

also, I really don't like all this output in the console, and I wonder if you can disable it

micha18:12:03

the maven output in boot?

richiardiandrea18:12:23

oh there is a mvn -q, still very verbose 😄

richiardiandrea18:12:56

no no I am unfortunately dealing with maven

tcrawley19:12:39

@richiardiandrea: redeploy is used when you have staging repos. That's how http://oss.sonatype.org works - you deploy, and it goes to a staging repo. You can then redeploy to that staging repo as much as you want, but must explicitly depend on that repo if you want to use those artifacts. Once you are happy with what you have in staging, you "release" it to maven central, where it becomes immutable

richiardiandrea19:12:31

yes I was familiar with that part, I was just wondering if it makes sense to create an alternative server for faster resolution from JS

richiardiandrea19:12:12

trying to understand how much work would be to have a node.js build tool

tcrawley19:12:03

ah, I didn't read any of the backlog before your http://sonatype.com link, sorry :)

alandipert20:12:50

@erwin hey thanks for the windows fixes! were you able to test on windows?

erwin20:12:34

not yet 😕 sort of tested it by swapping the code a bit around and relied on the appveyor build. If you want, i can test it on Windows, but I will have to create a VM or use AWS. Probably can do that tomorrow in the morning.

erwin20:12:12

(which is in 9 hours ...)

alandipert20:12:12

yeah, or maybe we can find someone with windows at hand to try it

alandipert20:12:21

it would just be really nice for a human with windows to actually see it not explode

alandipert20:12:33

of course, it's exploding now, so

alandipert20:12:48

perhaps we just merge and make 2.7.1 and then see

erwin21:12:25

I can make something happen tomorrow, I actually have a new colleague now with a windows laptop and we use boot in our build so I think its work(tm)

erwin21:12:57

so a check with a real human 👯

alandipert21:12:42

that would be awesome

juhoteperi21:12:29

I previously thought that the CI configuration was broken

juhoteperi21:12:30

Ah, and the appveyour status is shown on github, cool

alandipert22:12:54

@juhoteperi excellent, where do you see it displayed on github?