It always indicates that I'm missing jar / repo not found

It's not necessarily the need for this for Project I'm just trying to configure my boot-profile to automate pushing to clojars.

I'm running into complications

@jondejung can you paste the exception you get please?

clojure.lang.ExceptionInfo: missing jar file or repo not found data: {:file "/tmp/boot.user5334880196296361713.clj", :line 21} java.lang.Exception: missing jar file or repo not found

can you paste the stack trace also?

Yeah, sorry about that

java.lang.Exception: missing jar file or repo not found boot.task.built-in/fn/fn/fn/fn built_in.clj: 867 boot.core/run-tasks core.clj: 938 boot.core/boot/fn core.clj: 948 clojure.core/binding-conveyor-fn/fn core.clj: 1916

ah right, ok

weird, that error is originating with the push task

not the install task

but your build.boot file doesn't reference the push task at all

are you sure that's the right build.boot file?

(task-options! push {:repo "earth-css"} pom {:project 'rojikkushisutemu/earth-css :version "0.1.0" :description "common css projects"} speak {:theme "woodblock"}) (deftask build-jar [] (comp (pom) (jar))) (deftask install-jar [] (comp (build-jar) (install)))

Yeah I have it listed above

along with the set-env credentials

Maybe I' haven't followed instructions on how to push correctly

and the .gpg file I have is not set up correctly

i don't see push anywhere in what you pasted though?

ahh

you are doing like boot build-jar push at the command line?

push {:repo "earth-css"} pom {:project 'rojikkushisutemu/earth-css :version "0.1.0" :description "common css projects"}

is that not correct?

the :repo option should be "clojars" in your case

oh,

sorry

that option should be the name of the repository where you want to push the artifacts to

if you do (get-env :repositories) in the repl you can see the default repos

or you can do boot show -e and look for the :repositories key

Thanks a Million, Micha!

it's working?

yes

it worked

awesome!

>.<

org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: https://clojars.org/repo/earth-css/rojikkushisutemu/earth-css/maven-metadata.xml, ReasonPhrase: Forbidden - the group in the pom (rojikkushisutemu) does not match the group you are deploying to (earth-css.rojikkushisutemu).

I'll fix it don't worry, Thanks A Million!

Messed up earlier while trying to push to it . I'll write back when I get it uploaded

great, good luck 🙂

hey @micha does/could hoplon do anything like this? https://github.com/wilsonpage/fastdom

@alandipert thanks for the link. it was fascinating indeed. the second part of the article is quite though provoking regarding what identity is http://www.japantimes.co.jp/community/2016/07/10/issues/japans-discriminatory-koseki-registry-system-looks-ever-outdated/#.WAxuf6Nh1E4

😬 so many things!

strange, i merged PRs and the cards remain in the project view

shouldn't they transition to "done" or something?

we could also use the http://waffle.io github integration

as an alternative

The GitHub project thing is rather simple I don't think it tracks status yet

Using http://waffle.io is probably a bit better

thre we go, boot-hoplon back in hoplon

👏

@micha are the versions for clojure, clojurescript and boot-cljs the “minimum” supported version? And projects bump the versions from there?

yes

so if something is broken people can look at hoplon's clojurescript dependency for example

anyway you really need to have an explicit dependency on clojure and clojurescript in your project

or some random dependency will pull in a random version of it transitively

btw it looks like the tests aren't actualyl testing anything?

i changed the build.boot to explicitly test the hoplon.app-test namespace

not sure how that's going to go down on travis, since it needs firefox and stuff

i guess we'll find out soon 😉

lol xalan-2.7.2.jar

always piques my interest

why would someone make an x11 version of me

x@7@n

the command line version works just great

@tbrooke the appeal of the koseke idea to me is that it's less like a transaction log, and more like a value in a cell

wow tests run in travis no problem

https://travis-ci.org/hoplon/hoplon/builds/169961663

if anything the US system is transaction-log like, in thta the govt maintains events, not values. 3rd parties must spin through and piece together the events to arrive at a status value like married

but as per the 2nd part of the article, maybe it's good that there are inefficiencies like these. and that it's not all federalized

maybe, but there is also the possibility that they use that to create unequal access to the data that way

so it's easier for them to tiece it together than it is for you and your lawyer to do it

so they can selectively apply the fuckdown

gotta love govt

you should probably have both - event log + the latest (snapshot) state

also known as event sourcing 🙂

an interesting aspect of the event log way is that it allows multiple interpretations

so a different jurisdication can honor the event log and still arrive at a different status

it would be nice if the govt just stayed out of that whole area of life

marriage? agree

everything other than taxes i guess

birth death taxes

i guess marriage gets sucked in when naturalization enters

dassit

but that should probably just be based on where you are physically born i guess

yeah i'm not sure that marriage should be a factor for immigration

like why shouldn't i be able to sponsor some random person who is important to me, why do i need to marry them

yeah with a rate limit

naturally

i'd let the church or whatever handle marriages

Wow, lots of things happening.

Is it only me that liked when .hl files an application concern and not present in hoplon libs? With that boot-hoplon was completely optional.

it's still optional, no?

you don't need to use it, it's just packaged in the same jar now

to prevent issues with different versions of hoplon and boot-hoplon

The way we are deploying libs make that mandatory no? At least for libs using the manifest option and including .hl files.

Yeah, I understand why make it a hoplon dependency.

oh you mean like for jars that contain .hl files?

not hoplon itself?

Yes

i think you're probably right there

how many libraries are there that include .hl files, i wonder?

But there is a reason for that, it was because of the refering of vars that later were removed from hoplon.core, which broke compiled cljs files.

right

I don't think there are many of those but certainly a few.

but we could say that libraries need just .cljs files and not .hl files

and you need to do your :refer and stuff explicitly in your namespace

I'm in favor of that but would like to know what other people think. It kind of make it a little bit harder.

That's what I did: https://github.com/mynomoto/hoplon-spectre.css

@mynomoto I think if you are using a hoplon based lib it should include the hl files. After all the lib is for hoplon not just cljs

Like https://github.com/degree9/material-hl

or https://github.com/degree9/semui-hl

@flyboarder I think that should be the end user decision. If hoplon itself doesn't require it, why would hoplon libraries do that?

Hoplon is perfectly usable without .hl files unless we have libraries shipping them. It couples using hoplon with using boot-hoplon.

right, i see what you mean, although it is usable without the boot task, the task is also part of the hoplon ecosystem, I think it makes sense for things to ship with the understanding that if you want all the convenience of the hoplon ecosystem you would use the built-in tools

I'm only arguing that someone could be part of the ecosystem having all benefits of it without boot-hoplon if we don't include .hl files on libraries. It used to be that way before the changes in hoplon.core broke those libs and the way to do it became manifest files to tell boot-hoplon which files to compile from jars. It allows people that use lein to be part of the ecosystem.

@mynomoto right I see what you mean, there is more to include in the cljs files if you arnt using the hoplon task now, but a lein plugin also isnt out of the realm of possibilities

@mynomoto other than the hoplon.jquery namespace, are there other changes that break using the library without the boot task?

maybe for hoplon lib authors we can write another task that does the requires for us and spits regular cljs files?

thats basically only half of the existing task anyway right?

We used to rely on the hoplon task itself for generating the cljs files but I think that would cause hoplon jquery or gcl being picked for you now right?

Correct

However you can prevent that

So the last time things broke because of refer-all. Some vars were removed from core and boom. If we could only refer things that are used it would be better.

Yeah an empty refers option to boot task will prevent auto including jquery

You should be able to generate cljs files that way that include the things from core that are needed, core still has defaults for everything that was moved to hoplon.jquery

But it will include all things from core no? That was the problem last time.

org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.clojure:clojurescript:jar:1.7.122 in clojars (https://clojars.org/repo/)

😕

@mynomoto: I think so, but those things should mostly all need to be there now, the modular parts have been split out now, so things should be less likely to cause breaking changes for hoplon libraries in the future

@flyboarder true if there were no experimental things there right?

@jondejung: clojurescript isn't on clojars but on maven instead

AH, Thank You

how foolish of Me

@mynomoto: right so as long as you aren't using anything experimental your chances of breaking are much lower now, i think that also come with the territory of experimental ;)

But if things do break or move out of core you just need to require it in your library manually

Oh, what I mean is that the requires are done at compilation time, when the ,cljs file is created from the .hl file. And as clojurescript doesn't have :refer-all we do it by listing all vars inside :refer. If the var is removed this will break the cljs compiler.

Ah I get it now, yes you are totally on point with that, I think the next version will mitigate that a bit more with the new structure

We may want to have a experimental ns and only move solid things to core. That should also help to mitigate those kind of problems.

Agreed, we are heading in the right direction for that, that's what the brew repo is for

I think after the next release any feature changes should be developed there, this will also keep the hoplon repo in a much better LTS state

@micha @alandipert : @mynomoto makes a good point about not using boot with hoplon, do you think including the task couples hoplon to boot too much?

@flyboarder I don't think adding boot-hoplon as a dep to hoplon couples things, only shipping libraries jars with .hl files.

There is a pr to deprecate the boot-hoplon repo and merge it

shipping .hl files in libraries seems not good, is there a reason to do it?

ie it's better to ship cljs w/ a hoplon runtime dependency

@flyboarder I see no problem with merging. I don't like to have to use it to be able to use libs.

@alandipert I think that's implicitly the recommended way right? That's what the manisfest option of the hoplon task is for I think.

Also another thing that came to mind: we may have fragmentation problems with the new gcl impl. Some hoplon libs are jquery plugins, that will be not optimal for someone using gcl impl.

Yeah pre compiling hl to cljs has problems

You need to either ship hl or not use it and manually reference hoplon

@flyboarder if the lib has a dep on hoplon it should work out of the box I believe. Except for the dom manipulation impl I think.

After alpha17 I mean.

@mynomoto: I made the gcl version feature compatible to the jquery version but really attribute providers could provide anything and you should refer to the provider you want since they can be mixed

What happens when you load 2 providers?

There is a preference between them if they overlap

But providers can make any attribute so they may not overlap at all

But they do overlap for everything in core right?

Right, now the behavior is different for some of them but they do the relative thing