Fork me on GitHub
#boot-dev
<
2017-12-23
>
richiardiandrea01:12:37

Snapshots need manual deletion in .m2 last time I checked and therefore no good. I like the idea of using version modifiers like that, and probably -u should change accordingly.

richiardiandrea01:12:06

There is a nice package called boot-semver that handles version files pretty well 😉

flyboarder01:12:59

@martinklepsch can we build and package boot with boot?

richiardiandrea01:12:25

I was think about that

richiardiandrea01:12:52

@flyboarder at the moment it is built with Makefiles

martinklepsch11:12:04

@U0C8489U6 @flyboarder https://github.com/boot-clj/boot/pull/340 has the changes for building boot with boot. Also see the other referenced issue

richiardiandrea01:12:21

but with your new shiny boot-exec in theory we could use boot to build

flyboarder02:12:54

“bootception”

martinklepsch09:12:35

There’s a closed PR somewhere that built boot with boot

martinklepsch10:12:54

Seems that Maven gives some well known qualifiers special treatment so that boot -u issue might be a non issue https://stackoverflow.com/a/31482463/175920

martinklepsch11:12:48

I’m assuming Aether/Pomegranate use the same stuff as foundation? Also kind of curious what tools.deps does in this regard

martinklepsch11:12:05

Ah but I think the boot -u issue is still unclear. Depends on whether releases with -beta or similar are taken into account when specifying “RELEASE”

juhoteperi11:12:49

RELEASE has some problems, which is why it is rarely used

juhoteperi11:12:01

Don't remember properly, maybe it was that Maven has to check the repository every time if dependency uses RELEASE version

juhoteperi11:12:27

SNAPSHOT versions are cached for some duration, not sure about RELEASE

juhoteperi11:12:42

SLJ4J warning is from pomegranate/maven-resolver

juhoteperi11:12:18

Will be very hard to fix that unfortunately, we can't automatically add nop/simple logger as that would break projects using real loggers

juhoteperi11:12:52

Maybe we'll need code to check project deps and only add logger if there isn't one

juhoteperi11:12:33

Or maybe slf4-api has some method to check if logger is available... and then we can inject logger... if we can do that before it prints the warning, it would probably be most robust solution

juhoteperi11:12:50

If we can manage to run code before Maven-resolver classes are loaded, we can use java.util.ServiceLoader.load to check for SLF4JServiceProvider and if none is found, add nop/simple logger to classpath

martinklepsch11:12:17

@juhoteperi Could you open an issue for that?

martinklepsch12:12:33

@juhoteperi do you know if there’s a re-run button somewhere in AppVeyor?

juhoteperi12:12:32

"Re-build commit" under the build view

martinklepsch12:12:28

hm, I don’t think I have that option, maybe only the owner can do it? @juhoteperi

juhoteperi12:12:00

Hmm, I think AppVeyor permissions should depend on Github because there doesn't seem to be any way to configure them

juhoteperi12:12:26

Or hmm, it is under by account so it is possible

juhoteperi12:12:33

@martinklepsch Check now, I found option where I can give permissions based on Github organizations

juhoteperi12:12:54

Check again, I tuned the permissions a bit

juhoteperi12:12:17

And have you logged into appveyor with your github account?

juhoteperi12:12:23

or connected gh to your account

martinklepsch13:12:53

still not there 😄

martinklepsch14:12:49

well, I’ll just force push without edits then. Strange though.