5:15 p.m.
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
5:20 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:23 p.m.
+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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:24 p.m.
+1
On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:32 p.m.
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(a)redhat.com> wrote:
+1
On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:34 p.m.
+1
On Tue, Jan 8, 2013 at 9:32 PM, Lucas Holmquist <lholmqui(a)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(a)redhat.com> wrote:
+1
On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:35 p.m.
+1
On Tue, Jan 8, 2013 at 6:34 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
+1
On Tue, Jan 8, 2013 at 9:32 PM, Lucas Holmquist <lholmqui(a)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(a)redhat.com> wrote:
>
> +1
>
> On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:41 p.m.
Looks pretty good. A couple of things.
I would not put the core or utilities files as options since they are always needed for
any build.
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).
With #2, then you only need the "Select All" boxes on DataManager and Pipeline
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(a)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(a)redhat.com> wrote:
> +1
>
> On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:45 p.m.
On Jan 8, 2013, at 3:41 PM, Kris Borchers <kris(a)redhat.com> wrote:
> On Jan 8, 2013, at 2:32 PM, Lucas Holmquist
<lholmqui(a)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(a)redhat.com> wrote:
> >>> +1
>> >>> On Jan 8, 2013, at
10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >>>>>
_______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>>>
_______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>
_______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
Looks pretty good. A couple of things.
I would not put the core or utilities files as options since they are always needed for
any build.
I think i based this off of what JQM was doing, but yea. it doesn't make sense to
have them there
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).
yea, it always felt a bit odd having the base files there.
With #2, then you only need the "Select All" boxes on
DataManager and Pipeline
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?)
+1
8:06 a.m.
Looks nice!
-M
On Tue, Jan 8, 2013 at 9:32 PM, Lucas Holmquist <lholmqui(a)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(a)redhat.com> wrote:
+1
On Jan 8, 2013, at 10:23 AM, Lucas Holmquist <lholmqui(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:32 a.m.
Looks great!
Den 9 jan 2013 08.07, "Matthias Wessendorf" <matzew(a)apache.org> skrev:
Looks nice!
-M
On Tue, Jan 8, 2013 at 9:32 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
so i was thinking so...
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.o...
4:59 p.m.
https://github.com/aerogear/aerogear.org/pull/24
i've sent a PR for this to be include on the site, it has picks of what it looks like
now.
On Jan 9, 2013, at 2:32 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com> wrote:
Looks great!
> Den 9 jan 2013 08.07, "Matthias Wessendorf" <matzew(a)apache.org>
skrev:
>
> Looks nice!
>
> -M
>
> On Tue, Jan 8, 2013 at 9:32 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
> > so i was thinking so...
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.o...
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4133
days inactive
4134
days old
11 comments
6 participants
participants (6)
-
Daniel Bevenius -
Daniel Passos -
Kris Borchers -
Lucas Holmquist -
Matthias Wessendorf -
Sebastien Blanc