On Jun 7, 2013, at 10:03 , Sky Zhao wrote:

Yes, absoultely Matthieu, I tried this way(adapter.s4r) and can run normally too. Thank you very much your good suggestion.
It would be better if s4r file is bit small(now 8M a bit large), since the build.gradle template import too many s4 dependency jars, so donít sure which jars I can remove?

By default, all dependencies are included in the s4r, including platform ones. This is mostly for historical reasons (and because updating gradle scripts can be tricky). In reality, provided there are not conflicts/compatibility issues, you only need to add the actual dependencies needed for your application.

For instance for the twitter adapter application, you only need to include the app code and the twitter dependencies, all other dependencies are superfluous.


aopalliance-1.0.jar               commons-codec-1.4.jar          gson-1.6.jar                  jline-0.9.94.jar            minlog-1.2.jar                   s4-comm-0.6.0-incubating.jar
asm-3.1.jar                       commons-collections-3.2.1.jar  guava-13.0.1.jar              junit-3.8.1.jar             s4-core-0.6.0-incubating.jar
asm-4.0.jar                       commons-configuration-1.6.jar  guice-3.0.jar                 kryo-2.20.jar               netty-3.5.11.Final.jar           slf4j-api-1.6.4.jar
cglib-2.2.1-v20090111.jar         commons-digester-1.8.jar       guice-assistedinject-3.0.jar  log4j-1.2.15.jar            objenesis-1.2.jar                zkclient-0.1.jar
collections-generic-4.01.jar      commons-io-2.4.jar             javax.inject-1.jar            logback-classic-0.9.29.jar  zookeeper-3.3.3.jar
commons-beanutils-1.7.0.jar       commons-lang-2.6.jar           jcip-annotations-1.0.jar      logback-core-0.9.29.jar     reflectasm-1.07-shaded.jar
commons-beanutils-core-1.8.0.jar  commons-logging-1.1.1.jar      jcommander-1.25.jar           metrics-core-2.1.3.jar      s4-base-0.6.0-incubating.jar
From: Matthieu Morel [mailto:mmorel@apache.org] 
Sent: Thursday, June 06, 2013 4:11 PM
To: s4-user@incubator.apache.org
Subject: Re: About Adapter Deployment
Again, the "s4 adapter" command is for testing purposes only. Resolving the classpath from the current project is a hack that is only for avoiding deployment and easing testing, that's why it's not suitable for normal deployment. 
You should follow the usual way to deploy the adapter as an app: "use the packaged adapter app (as .s4r) and deploy it, as in the twitter example."
On Jun 5, 2013, at 11:04 , Sky Zhao wrote:

I tried and got not simple answer:
1.      wrap all project classes into one jar
2.      rename new classpath.txt(since source folder already has), and add the jar path into class list
Check the my project s4 file, the content is
               /home/notroot/apache-s4-0.6.0-incubating-src/gradlew cp
               java -cp `cat classpath.txt` org.apache.s4.core.S4Node $@
So only run one command in s4 source folder (replace #@ with Ėc=cluster2)
java -cp `cat classpath_rename.txt` org.apache.s4.core.S4Node Ėc=cluster2
then works, donít know whether exists better way.
From: Sky Zhao [mailto:sky.zhao@ericsson.com] 
Sent: Wednesday, June 05, 2013 12:16 PM
To: s4-user@incubator.apache.org
Subject: About Adapter Deployment
S4 Walkthrough page said
./s4 adapter -c=cluster2
The adapter command must be run from the root of your S4 project (myApp dir in our case).
I want to deploy adapter for new machine, not development environment, using this above way, I have to copy the many classes to new machine,
But if I use simple .s4r file, can it deploy directly ? And how to do this?  Or other more simpler way  clean deployment for adapter.