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. Matthieu > > > > > 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 > > /Sky > > From: Matthieu Morel [mailto:mmo...@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." > > Matthieu > > 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 > 3. > > 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. > > /Sky > > From: Sky Zhao [mailto:sky.z...@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. > > /Sky
