Ahh, ok, so the rest server will want to take over the whole url
space of the webapp, hence 1 servlet.
We can almost certainly do profiles in the server. In the patch I did
I simplified everything to make it all build and run from the base of
the source tree using profiles at the moment
in that patch (*not* current trunk)
cd shindig-trunk
mvn package
mvn -Prun
build and runs the server
it would be relatively easy to add other profiles.
eg,
mvn -Prun-social
mvn -Prun-social-rest
mvn -Prun-gadgets
mvn -Prun-full
again all in the base level.
I havent done this yet, but it is quite easy to do.
Ian
On 24 Apr 2008, at 22:46, David Primmer wrote:
On Thu, Apr 24, 2008 at 2:34 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
------------------------------------
Having just uploaded a patch for the maven build (which removes the
gadges.war and social-api.war packaging, leaving the jars. )I have a
question.
Is there a reason why you would want to run just the social-api
or just the
gadgets servlet in a test jetty, rather than a test jetty with
both of them
mounted ?
The reason I ask, is that if we build wars for all the jars we are
duplicating the build operation, web.xml's and other things.
Putting them
all in 1 server a) gives an example of deployment b) means that
there is 1
place where the web.xml runs.
Thanks for all the mvn edu! My feeling about the separation of the
servers is mostly that we'll be working to separate the dependencies
at the jar level and we're not there yet. Once they're separate at the
jar level, why would we only produce one server deployment? I know it
doesn't make much difference to someone who has to design their own
servlet deployment. They'll pull the whole thing apart are re-arrange
it anyhow. But having separate web.xml's will at least make that
process more clear for people. My own bias when working on the Rest
server is that it's a pain to continually depend on the gadgets server
instead of some more stable/smaller common jars. The main trick when
anticipating a monolithic server is to make sure that our servlets are
mounted in a way that they don't conflict and don't mandate
implementers have huge urls. This has yet to be fully
discussed/decided.
Ian
On 24 Apr 2008, at 22:22, David Primmer wrote:
Ahh, thanks ian. I was using some cassie instructions that said mvn
package. makes sense. I didn't do a mvn clean since in all my
efforts,
in order to make sure i tested your build, i did a fresh svn
checkout
and then ran the instructions to build and run the server. (only
exception being i just wanted to run social-api and not server).
I haven't run the gadgets server much lately. Are the only jetty
servers social-api and server ? So you can just run social-api if
you
just want a rest server but if you want a gadgets server, you
have to
run server? and if you want both you have to run server?
thanks again.
On Thu, Apr 24, 2008 at 1:32 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
try
cd java
mvn clean install
which will build common, gadgets, socia-api, and build the
server war.
The last message should be something like this...
INFO] Copy webapp webResources to
/Users/ieb/Caret/sakai22/devcode/shindig-trunk/java/server/
target/server
[INFO] Generating war
/Users/ieb/Caret/sakai22/devcode/shindig-trunk/java/server/target/
server.war
[INFO] Building war:
/Users/ieb/Caret/sakai22/devcode/shindig-trunk/java/server/target/
server.war
[INFO] [install:install]
[INFO] Installing
/Users/ieb/Caret/sakai22/devcode/shindig-trunk/java/server/target/
server.war
to
/Users/ieb/.m2/repository/org/apache/shindig/shindig-server/1-
SNAPSHOT/server.war
[INFO]
[INFO]
[INFO]
-------------------------------------------------------------------
-----
[INFO] Reactor Summary:
[INFO]
-------------------------------------------------------------------
-----
[INFO] Apache Shindig Project Parent .........................
SUCCESS
[2.767s]
[INFO] Apache Shindig Java Common Code .......................
SUCCESS
[1.169s]
[INFO] Apache Shindig Java Gadget Server .....................
SUCCESS
[16.878s]
[INFO] Apache Shindig Java REST API Server ...................
SUCCESS
[3.990s]
[INFO] Apache Shindig Java Gadget Server .....................
SUCCESS
[3.773s]
[INFO]
-------------------------------------------------------------------
-----
[INFO]
-------------------------------------------------------------------
-----
[INFO] BUILD SUCCESSFUL
[INFO]
-------------------------------------------------------------------
-----
[INFO] Total time: 29 seconds
[INFO] Finished at: Thu Apr 24 21:23:06 BST 2008
[INFO] Final Memory: 26M/161M
[INFO]
-------------------------------------------------------------------
-----
Then
cd server
mvn jetty:run
which will run the contents of
server/target/server
as a jetty webapp, mounted at /
the browse to http://localhost:8080
----------------------------------
mvn package
will just build all the artifacts but *not* put them in the
repository
(~/.m2/repository )
social-api
depends on common and gadgets, and so when you try and run
maven after
a
package on social-api alone, it cant find gadgets.jar and
common.jar
because
they are not in the local maven repo.
I hope that makes sense ?
IMHO, I would recommend that you do not run package unless yo
really
don't
want the artifacts in your local repo.... because you are likely
to get
a)
out of sync b) quite confused about which is the jar being used.
At the moment, this is not exactly what the README says, and I
really
don't
want to create any further confusion.
Ian
On 24 Apr 2008, at 20:10, David Primmer wrote:
I've been trying with no unix
-r650840 which is just after jira 209.
my experience today trying to follow the build instructions:
cd java
mvn package
...blah. works fine
cd social-api
mvn jetty:run-war
[ERROR] BUILD ERROR
[INFO] ---------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.apache.shindig:gadgets:jar:1-SNAPSHOT
2) org.apache.shindig:shindig-common:jar:1-SNAPSHOT
don't know why it wouldn't find them since they're supposed to be
installed in my local repo.
cd ../gadgets
mvn install
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.apache.shindig:shindig-common:jar:1-SNAPSHOT
huh!!!
cd ../common
mvn install
this works!
so i mvn install gadgets, mvn jetty:run-war in social-api and
it all
works
davep
On Thu, Apr 24, 2008 at 5:38 AM, Cassie <[EMAIL PROTECTED]> wrote:
Are you following this process exactly?
cd <shindig>
cd java
mvn package
cd gadgets
mvn jetty:run-war
- Cassie
On Thu, Apr 24, 2008 at 1:48 AM, Jason Burgess
<[EMAIL PROTECTED]>
wrote:
I've been trying to get the trunk to build when running mvn
package
for the
last few days. It will build inside of /java/common, but not
under
/java/gadgets (either from mvn package in /java or after running
mvn
install
on /java/common).
I've tried clearing out my repository, and I've tried trunk at
several
different points in time from the last several days.
The message is sometimes different, depending on the
revision, but
it
always
takes the form of: (I'm including a full dump at the bottom of
this
email)
[INFO] Compilation failure
could not parse error message: incorrect classpath:
/not_a_directory
----------
1. ERROR in
/usr/local/src/shindig/java/gadgets/src/main/java/org/apache/
shindig/gadgets
/spec/View.java (at line 1)
/*
^^
Prior to trying to build this, I did not have a JDK or maven
installed.
The
system is Fedora Core 6 (2.6.20-1.2962.fc6). I'm using JDK
1.6.0_06
and
Maven 2.0.0.9.
Please let me know if I'm just doing something wrong, or if you
can
point
me
a specific revision that's more stable (or should build
properly).
I
saw
there has been quite a bit of flux in the tree lately.
Thanks for
any
help
you can provide.
Jason Burgess
[EMAIL PROTECTED]
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/
samplecontainer/sta
te.opt.dtd is younger than original, use 'force' option or clean
your
target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/container/
cookiebas
eduserprefstore.opt.js is younger than original, use 'force'
option or
clean
your target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/container/
gadgets.o
pt.js is younger than original, use 'force' option or clean your
target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/container/
util.opt.
js is younger than original, use 'force' option or clean your
target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/container/
gadgets.o
pt.css is younger than original, use 'force' option or clean
your
target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/files/container/
cookies.o
pt.js is younger than original, use 'force' option or clean your
target
[INFO] nothing to do,
/usr/local/src/shindig/java/gadgets/target/classes/config/
oauth.opt.json
is
younger than original, use 'force' option or clean your target
[INFO] nb warnings: 0, nb errors: 0
[INFO] [compiler:compile]
[INFO] Compiling 86 source files to
/usr/local/src/shindig/java/gadgets/target/classes
[INFO]
-------------------------------------------------------------------
-----
[ERROR] BUILD FAILURE
[INFO]
-------------------------------------------------------------------
-----
[INFO] Compilation failure
could not parse error message: incorrect classpath:
/not_a_directory
----------
1. ERROR in
/usr/local/src/shindig/java/gadgets/src/main/java/org/apache/
shindig/gadgets
/spec/View.java (at line 1)
/*
^^
no more tokens - could not parse error message: The type Enum is
not
generic; it cannot be parameterized with arguments
<View.ContentType>
----------
----------
2. ERROR in
/usr/local/src/shindig/java/gadgets/src/main/java/org/apache/
shindig/gadgets
/http/JsonRpcHandler.java (at line 129)
private class Job implements Callable<JSONObject> {
^^^^^^^^
[INFO]
-------------------------------------------------------------------
-----
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLife
cycleExecutor.java:579)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle
(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifec
ycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFail
ures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(Defa
ultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycle
Executor.java:142)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:
375)
Caused by: org.apache.maven.plugin.CompilationFailureException:
Compilation
failure
at
org.apache.maven.plugin.AbstractCompilerMojo.execute
(AbstractCompilerMojo.ja
va:516)
at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManage
r.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLife
cycleExecutor.java:558)
... 16 more
[INFO]
-------------------------------------------------------------------
-----
[INFO] Total time: 10 seconds
[INFO] Finished at: Wed Apr 23 16:33:12 MST 2008
[INFO] Final Memory: 17M/30M
[INFO]
-------------------------------------------------------------------
-----
