Running an application without Capstanfile

[penberg]

We could have something like:

$ capstan run app.war

and have Capstan detect that it's a WAR file and pull a base image that has a servlet container like Tomcat in it.

[tzach]

How would Capstan knows which servlet container to pull? there can be more than one
Other containers may expect the WAR file in a different location

This remind me of buildpacks, which are design for similar function:
define runtime support for your application
https://devcenter.heroku.com/articles/buildpacks

[nyh]

On Mon, Apr 28, 2014 at 5:26 PM, Tzach Livyatan notifications@github.comwrote:

How would Capstan knows which servlet container to pull? there can be more
than one
Other containers may expect the WAR file in a different location

We more-or-less solved this in the "modules" infrastructure, and Capstan
should follow suite.

Namely, you need to define a feature name, say "war-runner". A "war-runner"
is any package which knows how to run a war you put in /war (or whatever).
We can then have two modules, jetty and tomcat which both "provide" this
war-runner. Running a war "requires" war-runner. Now, somebody can build an
image from jetty plus a war, or an image from tomcat plus a war - or if you
try just a war without specifying either tomcat or jetty, it requires
"war-runner" - which may either complain that one wasn't chosen, or bring
up a default choice (say, tomcat).

I don't know what Capstan is planning to do similar to these "provides" and
"requires" feature. Perhaps use the similar capabilities of RPM?

This remind me of buildpacks, which are design for similar function:
define runtime support for your application
https://devcenter.heroku.com/articles/buildpacks

Reply to this email directly or view it on GitHubhttps://github.com//issues/82#issuecomment-41564279
.

Nadav Har'El
nyh@cloudius-systems.com

[dorlaor]

On Mon, Apr 28, 2014 at 5:51 PM, nyh notifications@github.com wrote:

On Mon, Apr 28, 2014 at 5:26 PM, Tzach Livyatan <notifications@github.com

wrote:

How would Capstan knows which servlet container to pull? there can be
more
than one
Other containers may expect the WAR file in a different location

We more-or-less solved this in the "modules" infrastructure, and Capstan
should follow suite.

Namely, you need to define a feature name, say "war-runner". A "war-runner"
is any package which knows how to run a war you put in /war (or whatever).
We can then have two modules, jetty and tomcat which both "provide" this
war-runner. Running a war "requires" war-runner. Now, somebody can build an
image from jetty plus a war, or an image from tomcat plus a war - or if you
try just a war without specifying either tomcat or jetty, it requires
"war-runner" - which may either complain that one wasn't chosen, or bring
up a default choice (say, tomcat).

I don't know what Capstan is planning to do similar to these "provides" and
"requires" feature. Perhaps use the similar capabilities of RPM?

Seems like it's a combination of Capstan and the module system.
There are also buildpacks by CloudFoundry. It certainty requires
investigation.

However, for running simple jar we could use a Capstan file but I was
interested in the most simple command line scenario where you only
have one liner and ZERO files/config.

Even if one day we'll implement buildpack, the above would still be
interesting.
Buildpack should be a different git hub issue

This remind me of buildpacks, which are design for similar function:
define runtime support for your application
https://devcenter.heroku.com/articles/buildpacks

Reply to this email directly or view it on GitHub<
#82 (comment)

.

Nadav Har'El
nyh@cloudius-systems.com

Reply to this email directly or view it on GitHubhttps://github.com//issues/82#issuecomment-41567492
.