MD
Sent from one of my many iDevices
I haven't played with it in a while, but I did post about it
http://www.markdrew.co.uk/blog/post.cfm/running-railo-in-cloudbees
Regards
Mark Drew
Yes I have had a breef look at Cloudbees, but have not tried it. I
have also tested Jelastic.
On 3 Nov, 10:06, Mark Drew <mark.d...@gmail.com> wrote:
> Have you looked at cloudbees?
>
> MD
> Sent from one of my many iDevices
http://stark-samurai-1774.herokuapp.com/railo-context/admin/web.cfm
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
-----Ursprüngliche Nachricht-----
Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von
Molnfront
Gesendet: Freitag, 4. November 2011 05:16
An: Railo
Betreff: [railo] Re: Is it possible to run Railo on Heroku?
This is *perfect* for cfdistro. You could have one build that has
debugging and whatnot on, for local testing, and another to configure
the heroku deployment (full caching, no debug, etc.).
You'd just set
war.target.dir=${src.dir}/main/webapp
server.sharedlibs=true
in build.heroku.properties, run "cfdistro build build.type=heroku", and
theoretically the only real things that would be created would be
railo-web.xml and railo-server.xml, and optionally an .rc file. Commit
those, and away we go.
But basically, without using cfdistro, you should be able to commit ONLY
the railo-*.xml files and any patches in lib/railo/patches, and ignore
the rest, and have your Railo server on heroku start up password
protected and configured how you like.
:Denny
--
Railo Technologies: getrailo.com Professional Open Source
Skype: valliantster (505)510.1336 de...@getrailo.com
GnuPG-FP: DDEB 16E1 EF43 DCFD 0AEE 5CD0 964B B7B0 1C22 CB62
Agreed! The maven repo has old libs, it would be nice to add 3.3. This
was actually the first I'd seen it, unless I'm mistaken... do we know
who's maintaining it?
> PS... how is the cfdistro documentation going :)
Piecemeal but there's a good bit actually, in my local wiki, which I'll
sync up with the public one Real Soon Now. :)
I'm *so* bad about getting stuff out there. I had a scare recently that
makes me VOW to change my ways! VOW! For someone who preaches VCS,
etc., I'm horrible about keeping stuff on one machine. It is BAD BAD!
Git that stuff out there, den!
I also use TimeMachine and restored my machine on Friday after a freak crash, no problems. Get a 1TB external disk and you are set.
Oh and I have been using https://bitbucket.org/ for my private git repos. Just saying.
MD
Sent from one of my many iDevices
Just treat them like zip files, I am sure we can quickly write a script to do this…
MD
I've been rectifying all of this, but it can't happen soon enough!
Messing with git ATM, which is still a bit of an adventure. Dangerously
powerful stuff. :)
:Denny
If you use your own maven repo (like the one on sourceforge) you don't
have to worry about versions, per se (you put whatever you need in it),
but this bypasses one of the main reasons to use Maven. :-P
There's no way to get around using our own repo, or creating one on a
public provider (I submitted a request to sonatype the other day), as
we've got dependencies you won't find in maven central.
Personally, I think the easiest option would be to have our own maven
repo (slap nexus on a server somewhere, something like dev.getrailo.org?
Or create another sourceforge one managed by the team), vs. trying to
get all our dependencies into maven central-- but there's no reason to
not get as much as we can from central. (caveat: I use maven for some
stuff but am not an expert).
The reason I like the idea of getting as much as we can from maven
central, is that we're using a lot of older versions of various libs,
and maven does make getting newer ones easier (depending on the lib!).
For things like heroku, a separate repository is fine IMO-- you're not
really building railo, you're building a Railo war.
:Denny
LOL. Did that-ish ages ago for a discussion on updating libs for 4.0:
Bit of an ugly thing, but it generates this, basically:
:Denny
MD
That it does!
Some of it is still a wee bit strange to me though. Take this for instance:
git fetch origin develop
git checkout -b test origin/test
git pull origin develop
git status
# On branch test
# Your branch is ahead of 'origin/develop' by 27 commits.
#
nothing to commit (working directory clean)
How am I ahead of origin/develop? Why did git pull, um, pull stuff that
git fetch+checkout didn't get?
...
Ah ha! git fetch doesn't do what I thought it did! When I added a
colon to git fetch origin develop:, it fetched more stuff.
Still seems a bit strange, but at least I know there's a difference!
You shouldn't have to keep the passwords in a public repo, but you will
need to commit it to a private one at least, which you push to heroku,
as that's how you get stuff into heroku.
Of course what you'll actually be committing will be the config files,
which will contain the passwords.
I'm pretty sure cfdistro would work to generate just the stuff you need
to commit (2 files or so). After I give the kid a bath I can give it a
quick spin. Good for the brain to do something different :)
https://github.com/denuno/railo-heroku-cfdistro
That one doesn't include cfdistro itself (it would be a lot of useless
stuff to push to heroku, and by default cfdistro is installed in the
user's home directory, vs being in with the project), but it should show
you one way of doing this that doesn't leave you with a lot to manage.
Check out the pom.xml, where I have it copy my src and pub directory
content into the WAR as part of the build up on heroku. This allows me
to keep my preferred project structure (the pub dir is usually the
DocumentRoot for apache, or static resources we'd put in S3, etc.).
Basically what this means is that I can use the same source files for
local development, deployment to a "normal" server, or heroku. And the
heroku stuff is contained in one folder (./heroku).
Check out what's in heroku/WEB-INF to see what I was talking about as
far as very little to actually commit.
The admin password is defined in build/build.properties, and when the
config files are generated they'll contain it (encrypted).
I generated the stuff in heroku/WEB-INF by doing:
./railo-heroku-cfdistro build build.type=heroku
(./railo-heroku-cfdistro is an alias for cfdistro executable)
Of course you'd need to slap cfdistro in your home directory to actually
try that part out, or I could add it to the git repo (but it would be a
waste of heroku space to do so for anything "real").
I see they're using jetty-runner too, which is slick (cfdistro uses
jetty-runner for localdev testing by default).
And it looks like .rc patches are getting loaded OK, but I believe any
jars you add to WEB-INF/lib would be overwritten by heroku's maven
build, but I didn't test that (besides seeing that you can use H2
databases if you put the path in as ./myh2db which is awesome!).
:Denny
On 11/6/11 3:26 PM, Molnfront wrote:
http://sharp-waterfall-9836.herokuapp.com/
And I did *not* set the passwords manually, those are coming from the
config files in heroku/WEB-INF/*/railo-*.xml that cfdistro generated.
Basically I just uploaded the generated stuff in ./heroku, after moving
the css/images from there into pub (it's pretty), and that's it.
No, that was just showing the code that was going to run (if you see the
date below, you know it's running).
The idea was to show that you don't have to stick to the heroku/maven
layout for your project.