Great thought, Jesse. It was a nested /node_modules directory that was the bulk of the size. I added that to .cfignore. Thanks.

The cf CLI also respects a .cfignore file in the top level of your repo, if
there's stuff you'd like to explicitly exclude from push.

It's the cf cli that does this. It looks through your JAR / WAR or push
path for files and then uses the resource matching endpoint to ask the
server what it needs to upload. Then it uploads just those files. I
believe the algorithm works based on file hashes, someone else might be
able to add more detail if you need it.

Dan

On Tue, Apr 19, 2016 at 9:44 AM, Matthew Tyson <matthewcarltyson(a)gmail.com>
wrote:

It does help -- thanks guys. I looks like Heroku has a buildpack that
does this also (https://github.com/heroku/heroku-buildpack-java).

The question I am coming up with is this: How does cloud foundry identify
what files to upload? I know the detect script determines what buildpack
to use, but what determines what all to upload?

It does help -- thanks guys. I looks like Heroku has a buildpack that does this also (https://github.com/heroku/heroku-buildpack-java).

The question I am coming up with is this: How does cloud foundry identify what files to upload? I know the detect script determines what buildpack to use, but what determines what all to upload?

On Sat, Apr 16, 2016 at 11:30 PM, Josh Long <starbuxman(a)gmail.com> wrote:

I'm not sure if this is the right forum. I doubt it.

* you could achieve what you want by forking the buildpack used. If you're
using the Java buildpack then it's
https://github.com/cloudfoundry/java-buildpack. the `cf push` command
supports providing an override URL for the buildpack.

As an experiment, I created a build pack that would do this. It hasn't
been updated in a while, I don't plan to update it and it was never very
solid to begin with. It was more to just see if I could make it work. It
did, but the benefit was very small. I wouldn't recommend using it, but
it's there if you want to look at it.

https://github.com/dmikusa-pivotal/cf-maven-buildpack

* that said, this is a TERRIBLE idea. Instead, prefer that one build be
promoted from development to staging, QA, and production. Ideally, that
promotion should be automatic, the result of a continuous delivery pipeline
that sees code committed to version control, then run through continuous
integration, then pushed to a testing environment where it's certified and
smoke-tested, validated by QA, and ultimately promoted to production. You
can support this process with continuous integration tools like Jenkins,
Travis, Spinnaker, or Concourse.CI, which will monitor version control and
can be scripted to package and cf push code..

+1 - It's also worth mentioning that when you `cf push` something, your
platform will cache any resources that are larger than 65k (default
threshold, your platform's actual value may differ). The cache is global
so it's not just per app or per user. Once any user pushes a file, it will
be cached. This helps a ton with Java apps since JAR files are generally
over the threshold and the same JAR files are used across many users &
apps. Long story short, when you go to push your app you likely won't need
to upload as much data as you think.

Hope that helps!

Dan

On Sat, Apr 16, 2016 at 7:15 PM Matthew Tyson <matthewcarltyson(a)gmail.com>
wrote:

Please let me know if there is a more appropriate forum for this type of
question.

I'm not sure if this is the right forum. I doubt it.

* you could achieve what you want by forking the buildpack used. If you're
using the Java buildpack then it's
https://github.com/cloudfoundry/java-buildpack. the `cf push` command
supports providing an override URL for the buildpack.
* that said, this is a TERRIBLE idea. Instead, prefer that one build be
promoted from development to staging, QA, and production. Ideally, that
promotion should be automatic, the result of a continuous delivery pipeline
that sees code committed to version control, then run through continuous
integration, then pushed to a testing environment where it's certified and
smoke-tested, validated by QA, and ultimately promoted to production. You
can support this process with continuous integration tools like Jenkins,
Travis, Spinnaker, or Concourse.CI, which will monitor version control and
can be scripted to package and cf push code..

On Sat, Apr 16, 2016 at 7:15 PM Matthew Tyson <matthewcarltyson(a)gmail.com>
wrote:

Please let me know if there is a more appropriate forum for this type of
question.

Please let me know if there is a more appropriate forum for this type of question.

Is anyone aware of a way to deploy a maven application via cloud foundry that will:

1) Take only the application bits and upload them

2) Run the maven build based on the pom.xml

3) pull down the defined dependencies on the platform

Thereby NOT uploading the dependencies from the client to the platform?