[NPMCLI-58] Easy start, stop, and logging of Magnolia Created: 29/Nov/16  Updated: 02/Feb/17  Resolved: 30/Jan/17

Status: Closed
Project: Magnolia CLI
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0

Type: Story Priority: Major
Reporter: Christopher Zimmermann Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: CLI: Help users get started
Sprint: Basel 80, Basel 81
Story Points: 5

 Description   

Its clunky to start and stop the magnolia server. mgnl makes it easy to download and install, but starting the server is a more complicated step.

It should be easy to start, stop and log, on windows, osx and linux.
For example, something like "mgnl start" should start the nearest server in a new terminal window/tab with logging.

How this is handled exactly must be researched.

UPDATE
During scrum we briefly discussed the open new tab issue and, since writing a cross-platform solution to it may be far from trivial, we decided to go for a simpler approach and run starting tomcat and tail (the latter if available) as a background process without leaving the current terminal.
SOLUTION

A new sub-command start has been made available. By default it will

Start up Magnolia and display the logs. Magnolia CLI looks in the current working directory or parent directories for the nearest folder starting with "apache-folder".

To stop magnolia and tail, one needs to enter CTRL+C which will try to stop Magnolia gracefully with the magnolia_control.* stop script.



 Comments   
Comment by Robert Kowalski [ 19/Jan/17 ]

"should start the nearest server in a new terminal window/tab with logging"

we could walk the directory tree down and search for the folder, i'm afraid walking it recursively up could become very resource intensive (imagine a mgnl server start at '/').

we could implement configuration files into mgnl. on mgnl jumpstart it saves the path to the light-dev-environenment to ~/.mgnlrc

for multiple jumpstart runs:

if there is a config with server it errors with informing the user:

[ERR] already a default server defined. aborting.
[ERR] to overwrite the location of the default light-dev environment, run mgnl jumpstart -f

Comment by Christopher Zimmermann [ 19/Jan/17 ]

Not a fan of the ~/.mgnlrc because it's common to have multiple projects running at the same time. Also - by the way - there already is the "global" config which is stored in the node_modules mgnl global install directory. (for better or worse) See the files in here: https://git.magnolia-cms.com/projects/BUILD/repos/npm-cli/browse/lib/config

It's ok if this does not work in all cases, but just the most common one - if it cannot find the apache (or configured server) it can fail and ask the user to provide the path to the server.

If we assume that the project is created with the CLI - then it should be possible to come up with a reasonable strategy.
Most typically dev is in the directory where they ran mgnl jumpstart, or they are in one of the light modules.
For conversation, lets call the place where jumpstart was ran as "jumpstart-directory".
Just brainstorming:

  • search current directory and up to find the jumpstart-directory (a dir that contains "apache-tomcat")
  • if found - act on the apache-tomcat/bin directory.
  • else error - and ask for path to server directory.

Probably there is not a need to search down the tree, is there? Or if so - it could just search 1 or 2 levels down.

As far as configuration - if someone does want to provide a path to the server for a particular project - they could run "mgnl setup" and we could add the config there.

WDYT? fgrilli rkowalski

Comment by Robert Kowalski [ 19/Jan/17 ]

Good points!

> it's common to have multiple projects running at the same time

oh, also like in having multiple dev-server installed? Makes sense then.

> search current directory and up to find the jumpstart-directory (a dir that contains "apache-tomcat")

i'm afraid walking the directory dir recursively up could become very resource intensive (imagine a search starting from /) as it will walk through all dirs upwards that it finds (O^N). Walking down is preferable as it is a lot less resource intensive.

Hmm when we store every created magnolia-jumpstart-dir somewhere we can list them for the user and the user can chose.

This way we avoid accidentally wrong started servers which exists for example in a directory right next to the another magnolia-jumpstart dir.

We also avoid that we don't find anything and the user has to find out where the server is (one step more for the user than directly finding out and not using the CLI at all)

Example:


$ mgnl start

Available environments:

[1] /Users/robert/magnolia/test
[2] /Users/robert/magnolia/example

To boot a light-dev-server run:

  $ mgnl start <environment>

Example:

 $ mgnl start 1
Comment by Christopher Zimmermann [ 19/Jan/17 ]

By walk "up", I mean walking towards the root. Sorry for the confusion.

Comment by Federico Grilli [ 19/Jan/17 ]

I'd second Topher's proposal. Btw, that's what we already do when resolving mgnl-cli.json and the prototypes folder https://git.magnolia-cms.com/projects/BUILD/repos/npm-cli/browse/lib/helper.js#21
Basically starting from the cwd, go up until you find a directory which contains apache-tomcat. This name should be enough to identify a CLI "generated" tomcat which usually has a name carrying its version too. An info message would then show the user the absolute path to the tomcat instance being started up/stopped.

Comment by Robert Kowalski [ 19/Jan/17 ]

i chatted with czimmermann and we agreed to use a relative path for now.

i investigated the "open new tab" feature a bit, it works but differs greatly from platform to platform. in the best case we find a good module which enables cross platform support for us, in the worst case we would have to write it on our own.

Comment by Federico Grilli [ 25/Jan/17 ]

I also did some research on the "open new tab" feature and the only module I found was this one https://github.com/miguelmota/terminal-tab for OS X only, which under the hood relies on Mac's Terminal app.
I also tried to spawn a child process in Node.js like below, in hopes that the shell:true option would open it in a new tab but, alas!, that doesn't do what I was hoping for

const spawn = require('child_process').spawn
const ls = spawn('ls', ['-lh', '/usr'], { shell: true})

So, apparently we need to write our own thing. Unless rkowalski is luckier than me and finds a module that already does this cross platform.

Comment by Federico Grilli [ 26/Jan/17 ]

Not much progress here. When I run mgnl start two background processes are created, one for tomcat, one for tail showing Tomcat's log (for the time being, I'm assuming tail is always present). The latter output is displayed but after startup is complete, in spite the process is a background one, nothing happens when trying to type something in console. CTRL+C stops the current running process, i.e. the node one and the tomcat and tail processes remain active in the background but no more output is displayed if, for instance, I try to run some mgnl command which should trigger definition reloading (should be displayed by tomcat).
I tried both child_process.spawn and child_process.execute with different options but not luck so far. Maybe I'm missing something obvious, no glue. Have some idea rkowalski?

PS Of course, there's always the possibility of using the start command without assuming that a user must be able to type anything when nothing is logged. Just a way to start Magnolia and nothing more.

Comment by Robert Kowalski [ 26/Jan/17 ]

regarding the "open new tab" feature

> So, apparently we need to write our own thing.
> Unless Robert Kowalski is luckier than me and finds a module that already does this cross platform.

After thinking about it a bit more I think it isn't trivial. On Linux there are countless options for terminals. Also more custom terminals are becoming widespread, a big thing right now is HyperTerm, a Termial based based on JS and CSS: https://hyper.is/ – even Windows has multiple options: some people use only Powershell, some the CMD thingy and some others Cygwin like environments.

Right now I don't think its feasible to implement.

I also looked at some other popular things developers use for developing spawn a server (MongoDB, CouchDB, MySQL, Postgres, `python -m "SimpleHTTPServer"`, `jekyll preview`). None of them open a seperate window for logging, at least on Linux/Windows. They all write to the current window. So mgnl would be a definitive outlier from popular tools in this case.

Comment by Robert Kowalski [ 26/Jan/17 ]

fgrilli lets chat tmr regarding the spawning as just discussed in HC

Generated at Mon Feb 12 04:46:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.