[kepler-dev] SVNKit

[jing]

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 
>> <leinfelder at nceas.ucsb.edu <mailto:leinfelder at nceas.ucsb.edu>> 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
>>     > Kepler-dev at kepler-project.org
>>     <mailto:Kepler-dev at kepler-project.org>
>>     > http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>>     _______________________________________________
>>     Kepler-dev mailing list
>>     Kepler-dev at kepler-project.org <mailto:Kepler-dev at kepler-project.org>
>>     http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20110720/b7e1343a/attachment.html>