ClientLib Bootstrapper

[justinedelson]

Client library creation seems to follow a defined pattern, but I frequently forget some of the details. For example, I forget if it is depends vs. dependencies or embed vs. embeds.

I imagining a simple form to collect the parent path, name, categories, embeds, dependencies, checkboxes for JS/CSS.

Going a step further, we should be able to bootstrap (no pun intended) bootstrap-based client libraries, i.e.

• There's a checkbox saying "Include bootstrap"
• And a version selector (which gets data from the GitHub REST API)
• We fetch the ZIP and unzip it to the newly-created client library
• Set up css.txt and js.txt specifically to point to the LESS and JS files.
• Create a custom.less file, add it to bootstrap.less.
• (if necessary) change variables.less

Presumably we could do this for other frameworks, at least if they are based on LESS, but I don't think it is worthwhile doing this in a pluggable fashion. At least not for now.

[davidjgonzalez]

I have IDE templates for the common node defs with all (or the 80%) of options enumerated, which I fill out or remove. So for me IDE file template is faster and more effective.

I do like the idea of bootstraping the FE assets for a project; its annoying to hunt them down project to project. I'd like to be able to pull down "simple" (single file) deps like modernizr, respond.js, jquery (latest), along w BS3. It would be nice to wrap any normalizing CSS as well - ex BS3's resets disturb dialog elements under #CQ.

Im not sure I follow the 2nd bullet around version selector and the GitHub REST API though; would the ACS repo be hosting these assets? Or would they be pulled for various "vendor" repos? Curating versions of other projects doesnt seem fun.

[justinedelson]

I agree that without doing intelligent things with frameworks (bootstrap in my description), this is something you can do within your IDE. So consider basic clientlib bootstrapping to be the minimal thing you do.

For Bootstrap (and there's no reason this couldn't be done for other frameworks, just not sure it makes sense to try to generalize this into a plugin architecture right now), what I mean about the version selector is to use the GitHub API to download the list of BS releases. That way, we don't need to do a new release when 3.0.4 comes out (or whatever). Based on your selection, the source ZIP is downloaded and then inserted into the created clientlibrary.

Make (slightly?) more sense now?

[davidjgonzalez]

Like a bell! I like it.

This feels like a great compliment to the project archetype/bootstrap we discussed over on ACS Commons.

[justinedelson]

There's a basic implementation here: https://github.com/justinedelson/acs-aem-tools/tree/feature/client-lib-bootstrapper. It's not quite pull request ready yet, but should illustrate the basic concept.

[justinedelson]

updated in-progress version to include support for semantic.gs instead of (or in addition to Bootstrap).

[davidjgonzalez]

This looks sweet! Any chance you could commit the .tld to your repo so I could play around w it? :)

[justinedelson]

The tld? It should be built automatically.

[davidjgonzalez]

Oh, nice to know :) ... though odd as the uri for the taglib isn't available when I build and install the package (0.0.3-SNAPSHOT active)

The absolute uri: http://www.adobe.com/consulting/acs-aem-tools/clientlib-bootstrapper cannot be resolved in either web.xml or the jar files deployed with this application

I pulled your latest and the tld's in the bundle's target/META-INF, but its named "clientlib-bootstrapper.tld.tld" .. not sure if thats the problem?

Either way, no biggie; I can wait for PR to play around w it.

[justinedelson]

That's weird. I dont't think the double tld thing should matter, but I fixed it anyway.