This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-23
Channels
- # beginners (22)
- # cider (6)
- # clara (1)
- # cljs-dev (77)
- # clojure (23)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-france (16)
- # clojure-nl (1)
- # clojure-poland (1)
- # clojure-russia (26)
- # clojure-spec (5)
- # clojurescript (120)
- # datomic (1)
- # events (1)
- # hoplon (158)
- # leiningen (5)
- # off-topic (2)
- # om (24)
- # onyx (19)
- # other-languages (1)
- # ring-swagger (4)
- # sql (1)
- # vim (1)
It's not necessarily the need for this for Project I'm just trying to configure my boot-profile to automate pushing to clojars.
@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
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
(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)))
push {:repo "earth-css"} pom {:project 'rojikkushisutemu/earth-css :version "0.1.0" :description "common css projects"}
that option should be the name of the repository where you want to push the artifacts to
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).
Messed up earlier while trying to push to it . I'll write back when I get it uploaded
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!
we could also use the http://waffle.io github integration
The GitHub project thing is rather simple I don't think it tracks status yet
Using http://waffle.io is probably a bit better
@micha are the versions for clojure, clojurescript and boot-cljs the โminimumโ supported version? And projects bump the versions from there?
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
always piques my interest
why would someone make an x11 version of me
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
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
gotta love govt
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
marriage? agree
i guess marriage gets sucked in when naturalization enters
but that should probably just be based on where you are physically born i guess
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
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.
The way we are deploying libs make that mandatory no? At least for libs using the manifest
option and including .hl
files.
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.
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
@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
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
@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.
@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
There is a preference between them if they overlap
But providers can make any attribute so they may not overlap at all
Right, now the behavior is different for some of them but they do the relative thing