new directories layout, crossover instead of cljx, dependencies updates

[magomimmo]

Hello Creighton, while learning your very interesting lib, I updated the deps and the plugins section. I even tried to restructure a little bit its directories layout.

• I updated the references to the cljsbuild plugin to "0.3.3" which, in turn, requires to update clojure to "1.5.1" release and to explicitly choose a CLJS release. I set the latest available (i.e. "0.0-1909"). the new cljsbuild release also require a min "2.1.3" lein version;
• I removed the cljx plugin, because when you have to deal with portable clojure code, I think the :crossovers option is much more comfortable (i.e. it requires much less configurations);
• I created the src/clj and src/cljs dirs under which I put the corresponding enfocus stuff
• I moved the macros.clj file under the src/clj/enfocus/ dir
• I moved the previous syntax.cljx file under the src/clj/enfocus/enlive dir as syntax.clj (because of the switch from cljx to the :crossovers option of cljsbuild

IMHO there are still things that could be improved regrading the project codebase organization, e.g.

• separation on concerns between source code and testing code (you have the testing.cljs code in the source dir and even the html directory)
• introduction of the clojurescript.test lib by Chas Emerick for unit testing
• inclusion of the ring stuff inside the dev profile hosted in the project/project.clj file.

But before eventually collaborate on that points, I'd like to know from you what do you thing about the proposed pull request.

My best

[ckirkendall]

Thank you for helping out. I plan to vet all of this, this evening. A few things I am worried about. I think I tried crossovers but it required the end users project file to know about my crossovers for their lein-cljsbuild to pick it up. Kevin's cljx gets around this by generating all the source when I am bundling the jar. This may not be an issue anymore and its easy to check by creating the deploy jar. I am also little leery of including the clojurescript and clojure versions you selected Enfocus is compatible with much lower versions and generally when you include these in a library it forces the end user to upgrade even when it may not be required. I have tested it with 1.5.1 but given several people use enfocus in production apps I don't want to force them to upgrade clojure when its not required. If someone sets their version to 1.5.1 lein will override my 1.4.0 for them. Same is true for clojurescript and led me not to declare it as a dependency.

I am working on moving all tests over the clojurescript.test. There are some challenges with this that Luke and I handle differently. The first problem is we need a visual representation of success because we need to test this in a lot of browsers. Luke uses selenium and a little test framework. I do it manually. I think we could easily extend clojurescript.test to also create valid test.html that could be easily validated in all the browsers. The second issue is testing animation affects. I don't have a good solution for this in clojurescript.test or any framework for that matter so I am very open to ideas.

Again thank you so much for getting involved!

[magomimmo]

On Oct 1, 2013, at 6:16 PM, Creighton Kirkendall notifications@github.com wrote:

I think I tried crossovers but it required the end users project file to know about my crossovers for their lein-cljsbuild to pick it up.

uhm. we should try. crossovers generates the cljs file under an overridable default directory (:crossover-path) and you can add the :crossover-jar option and set it to true. this way the generated cljs files are added to the jar.

but we should test it to be sure everything works as expected.

Kevin's cljx gets around this by generating all the source when I am bundling the jar. This may not be an issue anymore and its easy to check by creating the deploy jar.

probably is not an issue anymore. I am also little leery of including the clojurescript and clojure versions you selected Enfocus is compatible with much lower versions and generally when you include these in a library it forces the end user to upgrade even when it may not be required.

but it could use the :exclusions. Eventually we could even think about different profiles (for 1.4, 1.5. etc).

I have tested it with 1.5.1 but given several people use enfocus in production apps I don't want to force them to upgrade clojure when its not required.

sure, but at the same time if they could stay on the 1.0.1.

If someone sets their version to 1.5.1 lein will override my 1.4.0 for them. Same is true for clojurescript and led me not to declare it as a dependency.

probably we have to introduce the profiles for different cli/cljs release

I am working on moving all tests over the clojurescript.test.

great! There are some challenges with this that Luke and I handle differently. The first problem is we need a visual representation of success because we need to test this in a lot of browsers.

I envision two different kind of testing: unit testing and browser testing (the visual representation of success ). It seems to me they are two different kind of tests. Luke uses selenium and a little test framework.

it seems a good choice. I saw other using a similar approach. I do it manually. I think we could easily extend clojurescript.test to also create valid test.html that could be easily validated in all the browsers.

I agree. I think we could use the fixture features. I used it only in clojure.test, not in clojurescript.test. we should try with it. The second issue is testing animation affects. I don't have a good solution for this in clojurescript.test or any framework for that matter so I am very open to ideas.

that's seem very tuff (an annoying) to me to. I need some time to think about it.

Again thank you so much for getting involved!

You are very welcome.

— Reply to this email directly or view it on GitHub.

[ckirkendall]

• Completely missed the :crossover-jar when looking at crossover the first time. It looks like it is exactly what we needed.
• I think profiles would a great idea but the generated pom for deploy should included the lowest tested version. That way it clear to the user if they have to upgrade.
• Fixtures are exactly what I was planning on using. use-fixtures does exist in clojurescript.test so I think it won't be an issue. I was planning on trying it out on the domina code first and then porting it over.

Logistics on some of the changes. I am currently in beta for 2.0 so I am going create a 2.0.1-SNAPSHOT and merge this there. Thank you again for helping out.

[ckirkendall]

Ok, I merged this into the 2.0.1-SNAPSHOT branch. I made a couple of updates to make it generate the proper release jar.