Hi, Matt:
Your idea looks similar to my proposal. We agree put the kepler
instance as part of workflow run engine (web service) war file. We can
do this in the build.xml of webservice (workflow run engine).
I think we may put both workflow scheduler and workflow run engine to a
zip file as well. If we do this, what name should we call it?
Thanks,
Jing
On 07/20/2011 04:24 PM, jing wrote:
i just sent an email to ben but forgot to cc to kepler dev :(
Hi, Ben:
Thank you for the constructive suggestion.
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.
You suggestion gives me an idea:
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.
What do you think about this?
Thanks,
Jing
On 07/20/2011 03:44 PM, Matt Jones wrote:
Hi Jing --
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.
Matt
On Wed, Jul 20, 2011 at 2:28 PM, ben leinfelder
<[email protected] <mailto:[email protected]>> wrote:
Hi Jing,
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.
I don't think we should be performing SVN checkouts within code
for this particular packaging task.
Thanks,
-ben
On Jul 20, 2011, at 3:00 PM, jing wrote:
> Hi, devs:
>
> I am working on creating a kepler server version installer. It
will include kepler, workflow run engine and workflow scheduler.
>
> 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.
>
> 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 :
>
> http://svnkit.com/license.html
>
> Can we add the svnkit jar files into kepler/build-area/lib? If
we can't, does anybody have any other recommendation?
>
> Thanks,
>
> Jing
> _______________________________________________
> Kepler-dev mailing list
> [email protected]
<mailto:[email protected]>
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
