replace ember.js with ember-rails gem about travis-assets HOT 10 CLOSED

Not sure what you missed, but I made a new pr for this #2

from travis-assets.

Hmm, looks like you right, there is something wrong with assets paths when loading engine in travis-ci app

from travis-assets.

The problem is travis-assets is not a real rails engine, so it will not add assets of required gems to assets path by it self.

@svenfuchs would it be a problem to declare a full engine so we can load assets files from other gems (engines) or is there a good reason to not to?

from travis-assets.

Nop, engine dose not help... I have no more ideas for the moment :)

from travis-assets.

@tchak Thanks for looking into the issue. Not sure if this helps or not, but when I a rake precompile:assets in travis-assets I am experiencing the same error.

$ rake assets:precompile
/Users/tanner/.rvm/rubies/ruby-1.9.2-p290/bin/ruby /Users/tanner/.rvm/gems/ruby-1.9.2-p290@travis-ci/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets
rake aborted!
couldn't find file 'ember'
  (in /Users/tanner/code/personal/ttdonovan-github/travis-assets/app/assets/javascripts/application.js:1)

Tasks: TOP => assets:precompile:primary
(See full trace by running task with --trace)
rake aborted!
Command failed with status (1): [/Users/tanner/.rvm/rubies/ruby-1.9.2-p290/...]

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

from travis-assets.

yeah i believe that a full engine would try to load all of the rails app environment (which then just crashes on the floor) I'm not sure if this current solution is the best to the problem (ie having both a rails app and an engine in the same repo), so feel free to propose other solutions.

maybe one alternative would be stripping out all the rails boilerplate stuff and just start a barebone metal controller app?

Sent from my iPhone

On Apr 19, 2012, at 14:00, Paul [email protected] wrote:

The problem is travis-assets is not a real rails engine, so it will not add assets of required gems to assets path by it self.

@svenfuchs would it be a problem to declare a full engine so we can load assets files from other gems (engines) or is there a good reason to not to?

---

Reply to this email directly or view it on GitHub:
#1 (comment)

from travis-assets.

@svenfuchs just for my understanding and clarity, the purpose of this engine/app is to serve the static front-end assets for the travis-ci. My understanding of this project is that all future JavaScript and CSS development and testing happens in the travis-assets repo and at some point those assets will be removed from the travis-ci repo. Example: Any changes or enhancements to the Ember.js app occur here with either the Jasmine or JUnit tests (not sure if any exists in the travis-ci).
To do front-end development/integration testing both the travis-ci and travis-assets will need to running.

from travis-assets.

the idea is to be able to deploy travis-assets to heroku as an asset host for production but use it as an engine in travis-ci for development

Sent from my iPhone

On Apr 19, 2012, at 23:16, Tanner [email protected] wrote:

@svenfuchs just for my understanding and clarity, the purpose of this engine/app is to serve the static front-end assets for the travis-ci. My understanding of this project is that all future JavaScript and CSS development and testing happens in the travis-assets repo and at some point those assets will be removed from the travis-ci repo. Example: Any changes or enhancements to the Ember.js app occur here with either the Jasmine or JUnit tests (not sure if any exists in the travis-ci).
To do front-end development/integration testing both the travis-ci and travis-assets will need to running.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

from travis-assets.

@svenfuchs I'm guessing this got fixed somehow, since travis-assets is in production now?

from travis-assets.

yeah, i guess so. closing this. thx :)

from travis-assets.