Looks pretty good. A couple of things.

1. I would not put the core or utilities files as options since they are always needed for any build.

2. I would not have the base files (Auth, DataManager, Pipeline) files as options either. Really what they are selecting are the adapters they want. The base files should just come along with the chosen adapter(s).

3. With #2, then you only need the "Select All" boxes on DataManager and Pipeline
4. Maybe a link below the "Build My Download" button for "Full Download" or something like that which would just download a zip of the full AeroGear.js and min files without a build (stored on the site?)

On Jan 8, 2013, at 2:32 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:

so i was thinking something like this for the site

http://blog.lholmquist.org/img/custom_web.png

not finished yet,  but close

On Jan 8, 2013, at 11:24 AM, Kris Borchers <kris@redhat.com> wrote:

+1

On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui@redhat.com> wrote:

+1 to that,  i think as long as we say on the client side what "version" it is, would should be fine

On Jan 8, 2013, at 11:20 AM, Kris Borchers <kris@redhat.com> wrote:

I thought about this more and I think manually updating the source files is not a bad thing. We only want the builder to build the current release, right? We don't want it building from master so I think only updating when we do a release is ideal. We could also probably set up something in our CI to watch for new tags and automate that source file update as part of our release which would be cool.

On Jan 8, 2013, at 10:15 AM, Lucas Holmquist <lholmqui@redhat.com> wrote:

from this gist:https://gist.github.com/4485018

Custom Aerogear.js Builder

Prototype here: http://aerogearjsbuilder-lholmqui.rhcloud.com/

myrepo: git@github.com:lholmquist/aerogearjsbuilder.git

There is still a couple of minor tweaks that i need, like better error handling and CORS support possible. although it uses an iframe, so maybe not

This is the way it works.

client side

once you submit, the code builds the query params, then sends it to the server( duh ) using an iframe( atm )

Server side

Server side is a node.js server running on option shift

There is a "base" grunt.js file that has "markers" for the src and destination, This gets read in, replacements are made and then saved( customhash.js ) to a temporary directory( date in millis ). Then a node child proccess, runs grunt using this new custom grunt file, while overiding the "base", where the src files are, and the "config", where the custom grunt file is

once grunt is finished creating the files, the server then zips them up and sends that back to the client.

and then deletes the temporary directory

Src File Storage

The src files are currently stored in the OPENSHIFT_DATA_DIR, this is used for persistent storage and doesn't get recreated after every build.

Currently i need to ssh on to the server and do a git pull to update the repo in this directory.

Not really sure if there is a better way, perhaps a cron, or something.

Originally i had the src files in the project itself, but then moved them out to this persistent directory.

Another idea could when the user does a submit to get the file, it checks to see if the repo is up to date, then if not, updates it. Probably have a time aspect to it, so it only does it everyday for instance

looking for idea's here for the src files

-luke

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev