Docs: Decouple the project manifest to a standalone page

pull/129/head
Oleg Nenashev 2016-11-26 01:28:42 +03:00
parent 7c3bd2d40b
commit 33efbdd7dd
2 changed files with 20 additions and 16 deletions

16
MANIFEST.md Normal file
View File

@ -0,0 +1,16 @@
Project manifest
===
Here is a cite from [Kohsuke Kawaguchi](https://github.com/kohsuke/), who is the original author of this project:
> Now, I think the first question that people would ask is, why another, when there's [Java Service Wrapper project](http://wrapper.tanukisoftware.org/doc/english/download.jsp) already available.
The main reason for writing my own was the license — Java Service Wrapper project is in GPL (so that they can sell their commercial version in a different license), and that made it difficult for [Jenkins](http://jenkins-ci.org/) (which is under the MIT license) to use it.
> Functionality-wise, there's really not much that's worth noting; the problem of wrapping a process as a Windows service is so well defined that there aren't really any room for substantial innovation.
You basically write a configuration file specifying how you'd like your process to be launched, and we provide programmatic means to install/uninstall/start/stop services.
Another notable difference is that winsw can host any executable, whereas Java Service Wrapper can only host Java apps.
Whether you like this or not depends on your taste, so I wouldn't claim mine is better.
It's just different.
> As the name implies, this is for Windows only.
Unix systems have their own conventions for daemons, so a good behaving Unix daemon should just be using `launchd/upstart/SMF/etc`, instead of custom service wrapper.

View File

@ -4,6 +4,10 @@ winsw: Windows service wrapper in less restrictive license
WinSW is an executable binary, which can be used to wrap and manage a custom process as a Windows service.
Once you download the installation package, you can rename `winsw.exe` to any name, e.g. `myService.exe`.
### Why?
See the [project manifest](MANIFEST.md).
### Download
Right now the project uses [Jenkins](https://jenkins.io/index.html) Maven repository as a main storage of release files.
Binaries are available [here](http://repo.jenkins-ci.org/releases/com/sun/winsw/winsw/).
@ -11,22 +15,6 @@ Binaries are available [here](http://repo.jenkins-ci.org/releases/com/sun/winsw/
Some releases (e.g. alpha- and beta-versions) can be also downloaded from the project's GitHub page.
This source of releases is not an **official one**.
### Why?
Here is a cite from [Kohsuke Kawaguchi](https://github.com/kohsuke/), who is the original author of this project:
> Now, I think the first question that people would ask is, why another, when there's [Java Service Wrapper project](http://wrapper.tanukisoftware.org/doc/english/download.jsp) already available.
The main reason for writing my own was the license — Java Service Wrapper project is in GPL (so that they can sell their commercial version in a different license), and that made it difficult for [Jenkins](http://jenkins-ci.org/) (which is under the MIT license) to use it.
> Functionality-wise, there's really not much that's worth noting; the problem of wrapping a process as a Windows service is so well defined that there aren't really any room for substantial innovation.
You basically write a configuration file specifying how you'd like your process to be launched, and we provide programmatic means to install/uninstall/start/stop services.
Another notable difference is that winsw can host any executable, whereas Java Service Wrapper can only host Java apps.
Whether you like this or not depends on your taste, so I wouldn't claim mine is better.
It's just different.
> As the name implies, this is for Windows only.
Unix systems have their own conventions for daemons, so a good behaving Unix daemon should just be using `launchd/upstart/SMF/etc`, instead of custom service wrapper.
### Usage
WinSW is being managed by configuration files: [Main XML Configuration file](doc/xmlConfigFile.md) and [EXE .config file](TODO).