Re: [aperi-dev] Install & runtime discussion...

["Robert Wipfel" <rawipfel@xxxxxxxxxx>]

Hi,

Top posting...

For Linux, maybe package Aperi into a set of RPMs...
with common RPMs shared by all services,
and other RPMs for each service
(e.g. aperi-common.rpm, aperi-agent.rpm, 
aperi-data-server.rpm, aperi-device-server.rpm)
and install into Linux Standards Base (LSB) directories
e.g. /opt/aperi, /var/opt/aperi etc,
and provide init scripts for service start, stop, check

For Windows, package into an MSI?
and create Windows services for each component...
(not really my area)

The R0.3 release provides Aperi software
in a non-OS packaging specific format, so to speak...

Afaik there are no issues with packging into
RPMs - that's the open source way. And I think it's
permissible to package open source code into MSIs too,
but am not an expert on that.

Hth,
Robert

>>> Todd Singleton <toddsing@xxxxxxxxxx> 05/25/07 6:26 PM >>>
Comments in blue.  Thanks for your response. 

Todd Singleton
Software Engineer, Tivoli, IBM
Menlo Park, CA
email: toddsing@xxxxxxxxxx




Khan M Tasinga/San Jose/IBM@IBMUS 
Sent by: aperi-dev-bounces@xxxxxxxxxxx
05/25/2007 03:40 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>


To
Aperi Development <aperi-dev@xxxxxxxxxxx>
cc

Subject
Re: [aperi-dev] Install & runtime discussion...







Hey Todd, 

That looks like a pretty good list of problems and potential solutions. 
Off top, some questions / thoughts... 

- If someone wanted to build a commercial offering on top of Aperi, might 
there be some licensing issues related to the use of Java Service Wrapper? 
I recall running into problems when trying to use it on another project, 
in the past. If using Java Service Wrapper might present problems down the 
line, are there any reasonable alternatives.  In Aperi, the installer 
optionally downloads some third-party software.  If JSW were used, it 
would be something downloaded at install time, not something distributed 
with the Eclipse license - not something intermingled with the core code. 
As such, the solution would not be imposed on commercial adopters, or 
anyone for that matter.  So the question is - does such a tool better the 
"first impression" of Aperi?  Does it increase usability?  That's what we 
seek to address.  This is one of a few possible options.  

- The five command windows popping-up on Windows... I think that's due to 
the fact that we use java.exe instead of javaw.exe to launch the various 
processes, so that we have a way to kill them (Ctrl-C). An alternative 
that wouldn't require something like Java Service Wrapper... Switch to 
javaw.exe to launch the various processes and create small command-line 
utilities to communicate with them (TCP/IP) for graceful shutdown. A 
similar approach could be applied on Linux, where we already launch 
processes in the background. Yes, that's also an option.  

- Right now, uninstall = delete Aperi directory, no? I kind of like that. 
Hopefully, it doesn't have to go. I agree, that's nice and simple.  If 
Aperi ever runs as an NT service or Unix daemon, it will need to have a 
simple uninstall.  Followed by a manual 'delete' would complete the 
uninstall.

- With respect to OS integration, do you have anything else in mind beyond 
the creation of services? On windows, maybe a nice little icon on the 
System Tray. 

Regards, 
Khan Tasinga
IBM Tivoli Software Engineer (Storage Management Development)




Todd Singleton/San Jose/IBM@IBMUS 
Sent by: aperi-dev-bounces@xxxxxxxxxxx 
05/25/2007 02:35 PM 

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>


To
aperi-dev@xxxxxxxxxxx 
cc

Subject
[aperi-dev] Install & runtime discussion...









Craig and I came up with the following list while we brainstormed 
enhancements to our installer and runtime (start/stop) process.  Please 
feel free to comment.  He and I will continue to discuss.  We'll use the 
Wednesday design meeting to go into more depth as things evolve.   

Install Issues 

Problems 
No gui 
Complicated downloads around dojo and birt toolkit 
Ease of development & development scalability 
Current technique is home grown 
jh.jar requires a manual download from the sun site   ( <--- no simple 
solution in site) 
No uninstaller 
No OS integration 

Candidate Solutions 
Place Icon on the system tray 
Use Ant Installer to address gui and development issues 
Add dojo and birt into download.xml (requires additional development) 
Download & integrate with Java Service Wrapper (OS service and daemon 
integration) 

Runtime Issues 
Problems 
5 command windows pop up on windows 
No solution for a graceful shutdown 
Unix requires that each process be killed with cryptic command (go job 
hunting) 
An agent scanner process may shut down when we just kill the aperi java 
process 
Have to restart process every time the machine reboots 

Candidate Solutions 
If we launch process from system tray (or some tool in the OS), we get rid 
of the command windows 
Using java service wrapper gets free nt services and unix shell along with 
process robustness 

Todd Singleton
Software Engineer, Tivoli, IBM
Menlo Park, CA
email: toddsing@xxxxxx.com_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev