search

sbt / sbt-native-packager

sbt Native Packager
https://sbt-native-packager.readthedocs.io/en/stable/
BSD 2-Clause "Simplified" License
1.6k stars 441 forks source link

windows installer #12

Closed imeredith closed 5 years ago

imeredith commented 11 years ago

Just fyi Jenkins uses https://github.com/kohsuke/winsw for installing itself, and its slaves as windows a windows service.

Not sure what else there is out there.

jsuereth commented 11 years ago

That actually looks nice. I am looking for a way to enable windows services soon. Ideally we'd get something for linux as well. If you have a chance to try this guy out, I'm more than open to pull requests. We're still in explore + abstract stage on this project, to some extent. Trying to get all the right hooks for the underlying natives right before expanding the simplicity of packaging.

imeredith commented 11 years ago

Thats cool. I'm interested in this from a PaaS pov mainly but I may look at doing this if I get some time.

From a PasS perspective (or at least mine as an employee of CloudBees) it would be great if every http server could support the same basic args and be called from the same script. I know there are various ways to do this, like herokus buildpacks, but it would be cool to be able to do it from sbt directly. I havent looked much as this plugins architecture, but I assume the user could configure the app to be a generic web server (which would work for play/ embedded jetty/spray).

jsuereth commented 11 years ago

Yep. we're actually investigating that for play/akka. Right now I'm mostly focused on how to let users configure custom packages for each target packaging platform. Now working towards genericizing that, so if you have a "simple" application type (like a web server), the plugin can autogenerate the packaging for you, given a few minimal inputs.

laguiz commented 10 years ago

I already used http://yajsw.sourceforge.net/ for a Play application but https://github.com/kohsuke/winsw looks very interesting. Any progress on this?

muuki88 commented 10 years ago

We didn't have time to come across this :(, but would be happy to help you with a pull request :)

laguiz commented 10 years ago

Thanks for feedback. I will see if I can find some times to look at it. Keep good work :)

laguiz commented 10 years ago

I manually tested WIX with winsw (https://github.com/kohsuke/winsw) and it works like a charm.

Note :

Files that work for me so far :

Add in WIX file line 44 Nothing related to Play here but only Windows Service description + reference to exe file.

      <DirectoryRef Id="bin97543xxxx">
            <Component Id="pmsi_service" Guid="8b912ebe-dece-4a75-a6c1-111222333444">
              <File Id="fl_pmsi_service" Name="pmsi_service.exe" DiskId="1" Source="bin\pmsi_service.exe" Vital="yes" KeyPath="yes">
              </File>
              <ServiceInstall Name="pmsi_service" ErrorControl="normal" Start="auto" Type="ownProcess" Vital="yes">
              </ServiceInstall> 
            </Component>
          </DirectoryRef>

Create bin\pmsi_service.xml Used by the exe to know what to do. The most difficult file to create to keep it generic (not only Play). In my case I reused pmsi.bat informations generated by Play. I added -Dpidfile.path="NUL" in the arguments to avoid to generate PID file (we don't need it since we use Windows Service).

<service>
  <id>pmsi_service</id>
  <name>pmsi_service</name>
  <description>This service runs Sample Winsw (sample application).</description>
  <env name="SAMPLE_WINSW_HOME" value="%BASE%"/>
  <executable>java</executable>
  <arguments>-cp "..\lib\pmsi.pmsi-1.0.jar;..\lib\org.scala-lang.scala-library-2.11.1.jar;  
[ ... others libs ... ] 
..\lib\pmsi.pmsi-1.0-assets.jar" -Dpidfile.path="NUL" play.core.server.NettyServer</arguments>
  <logmode>rotate</logmode>
</service>

bin\pmsi_service.exe Simply take the exe provided by winsw and rename it.

What works :

Todo for initial test integration :

What do you think about this approach? Let me know if i'm out of scope.

muuki88 commented 10 years ago

At first glance this looks awesome. You describe already the task/settings we need to add for the windows archetype.java_server.

I have the feeling that most of the work has to be done in the last point. If you need help providing a pull request feel free to ask any question.

jsuereth commented 10 years ago

that's actually super awesome. We should probably find some way to host the EXE we've tested with, but allow others to override. As such, we should probably download the EXE in our build and publish as a classified artifact (or something else) that can be resolved in windows builds.

We could also (I"d be ok with this) bundle the exe into our JAR file. What is the license for winsw?

Kudos for figuring out the wix stuff. Super awesome to hear it works. You may have just kickstarted our next major release :)

laguiz commented 10 years ago

License issue was the first motivation for @kohsuke. He wrote

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 (which is under the MIT license) to use it.

https://github.com/kohsuke/winsw/blob/master/LICENSE.txt

jsuereth commented 10 years ago

Awesome! MIT works well, we'll just have to list that we use it.

laguiz commented 10 years ago

Here is my first attempt. It's basically working but still not generic (tested with Play 2.3.x).

I added comments in the code to tell you where I have difficulties.

Feel free to give me any advice.

Simple question : I'm currently using publish-local to publish sbt-native-packager. I referenced this build into my current Play test application (luckily build number does not change every time). Do you know if I can skip this step (publish-local) by referencing plugin sources directly from my test project?

So far it's only working in the Windows scope so you have to build the MSI by doing windows:packageBin.

jsuereth commented 10 years ago

For testing, take a look at the test-project directory included with the native-packager checkout. YOu should be able to just run sbt in this project and every reload will recompile sbt-native-packager code for testing. Feel free to add windows configuration as needed for your purposes, I'm sure we'd all appreciate it :)

ghost commented 9 years ago

For what it's worth, you might consider using procrun from the commons-daemon project as an alternative to winsw. This is what tomcat uses. In fact, I'm not sure why Jenkins didn't use procrun since it's almost the same thing with a similar permissive license (apache).

Advantages include having the binary up on the maven repo, though it's not listed in a configuration in the pom anywhere so you have to manually pull it.

Another advantage would be that it's java specific so you can, for example, supply a stop() method that is called when the service is stopped.

muuki88 commented 9 years ago

Thanks for the suggestion! At the first look procrun looks pretty solid regarding features and maturity.

Do you have any time to start a initial pull request? If you need any help setting things up or a general idea how to implement, I'm more than happy to help.

schmitch commented 8 years ago

It would be great if somebody is willed to address this issue. Maybe I could ask my employer to raise some bucks for it.

muuki88 commented 8 years ago

There is still an open pull request. Maybe you could start there.

schmitch commented 8 years ago

actually I have zero experience with the codebase I doubt that I can't pull that off :(

muuki88 commented 8 years ago

If you take a look at #329 the changes are rather simple

The code alright is in a acceptable shape. It only needs some testing, maybe configuration tweaks and documentation.

schmitch commented 8 years ago

easier as said