<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
i just sent an email to ben but forgot to cc to kepler dev :(<br>
<br>
Hi, Ben:
<br>
<br>
Thank you for the constructive suggestion.
<br>
<br>
I already packed the two war files - workflowrunengine and
workflowscheduler. Our goal is minimizing the the steps for the
installation. Hope it can be as easy as just dropping the two war
files into tomcat webapps. We don't want to user to install the
kepler in the server and configure its path in the properties file.
So it is better to include the kepler installation in the
workflowrunengine.war since it can eliminate the installation of
kepler.
<br>
<br>
You suggestion gives me an idea:
<br>
<br>
Yeah, we don't need a kepler server version. We can download Kepler
from a tag (e.g. 2.3) during packing workflow run engine war file.
So we change the packaging from kepler system to workflow run engine
system. Make the kepler as part of workflow run engine release.
Still in workflow run engine component, we can have a target to
create something like workflow-scheduler-run-engine-1.0.zip (or
other name) release. This zip file has to war files -
workflowscheduler.war and workflowrunengine.war.
Workflowrunengine.war includes a release version of kepler. User
just unzips the file and drops the two war files into tomcat
webapps. Then everything will work. If user doesn't want the
workflowrunengine to use the default kepler coming with it, he/she
can install a kepler in the server by itself and modify the property
to point to its custom version.
<br>
<br>
What do you think about this?
<br>
<br>
Thanks,
<br>
<br>
Jing
<br>
<br>
On 07/20/2011 03:44 PM, Matt Jones wrote:
<blockquote
cite="mid:CABHpJO0_H0VkL102g6o_-dCOdWYqysAoyX58J5Et0S1GT3Jpyg@mail.gmail.com"
type="cite">Hi Jing --
<div><br>
</div>
<div>I think Ben's right -- should be a packaged install,
preferably a WAR file that contains everything someone would
need. So maybe you could add the Kepler instance directly in
the WAR file with the web service so that all an admin would
need to do is drop it in tomcat's webapp directory and the y
would be set to go.</div>
<div><br>
</div>
<div>Matt<br>
<br>
<div class="gmail_quote">On Wed, Jul 20, 2011 at 2:28 PM, ben
leinfelder <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:leinfelder@nceas.ucsb.edu">leinfelder@nceas.ucsb.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hi Jing,<br>
I think it would be better to use a standard Kepler
installer (soon to be 2.2?) on the server and package the
other services (axis and scheduler war files) separately.
Then we would have a standard installation of Kepler
deployed on the remote execution server without worrying
about maintaining releases for both a "client" and "server"
version of Kepler. Can you just bundle the axis2/webservice
war and the scheduler war into an archive that is easily
deployed and configured on the server? I believe the target
audience for the scheduling system is small and mostly
comprised of system administrators who should be able to
unpack the bundle.<br>
I don't think we should be performing SVN checkouts within
code for this particular packaging task.<br>
Thanks,<br>
-ben<br>
<div>
<div class="h5"><br>
On Jul 20, 2011, at 3:00 PM, jing wrote:<br>
<br>
> Hi, devs:<br>
><br>
> I am working on creating a kepler server version
installer. It will include kepler, workflow run engine
and workflow scheduler.<br>
><br>
> Building the installer will involve the svn
command, e.g. checking out workflow scheduler and run
engine components from svn repositories. To my
understanding, the jobs of kepler build system are done
by java classes, not in the build.xml. So we need a java
library to handle the svn actions. The library will
provide a SVN API for the java class which builds the
installer.<br>
><br>
> I looked a around and found a pure java toolkit -
SVNKit. It has dual licensing - TMate Open Source
License and Commercial License. The TMate Open Source
License permits you to use SVNKit at no charge under the
condition that if you use the software in an application
you redistribute, the complete source code for your
application must be available and freely redistributable
under reasonable conditions. It is similar to GPL
license. The details can be seen at :<br>
><br>
> <a moz-do-not-send="true"
href="http://svnkit.com/license.html" target="_blank">http://svnkit.com/license.html</a><br>
><br>
> Can we add the svnkit jar files into
kepler/build-area/lib? If we can't, does anybody have
any other recommendation?<br>
><br>
> Thanks,<br>
><br>
> Jing<br>
</div>
</div>
> _______________________________________________<br>
> Kepler-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Kepler-dev@kepler-project.org">Kepler-dev@kepler-project.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev"
target="_blank">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev</a><br>
<br>
_______________________________________________<br>
Kepler-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Kepler-dev@kepler-project.org">Kepler-dev@kepler-project.org</a><br>
<a moz-do-not-send="true"
href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev"
target="_blank">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>