got, i can remove all s4 and other packages when deploy,but include s4 lib in
build ,thanks
----- 邮件原件 -----
发件人: Matthieu Morel <mmo...@apache.org>
收件人: "s4-user@incubator.apache.org" <s4-user@incubator.apache.org>
发送时间: 2013-6-10 20:30
主题: Re: About Adapter Deployment
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<mailto: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 �Cc=cluster2)
java -cp `cat classpath_rename.txt` org.apache.s4.core.S4Node �Cc=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<mailto: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
